Eric McNiece

Yes, this is the third step of [adverts_add]. Thank you for this explanation – I didn’t see that the zip/postal field changes based on the origin country parsed in the card number! I was entering Stripe’s test card number (4242424242424242), seeing the form reveal the zip field, and then became worried when I couldn’t enter letters for postal codes into it.

Awesome!

If anyone is curious, my stack is here: https://github.com/emcniece/docker-wordpress

I just fought through this and discovered that my PHP define('WP_REDIS_HOST', 'redis'); was being added at the wrong time.

I was using a custom plugin (generated on container creation) to add a few defines. It turns out that this is too late – the defines needed to be in wp-config.php.

A quick custom PHP file with $r = new Redis(); $r->connect(...) was successful, even though the plugin itself was failing.

The timing issue was discovered by enabling WP_DEBUG and seeing that the PHP-Redis connection was failing (PHP warning message) on line 418 of wp-content/object-cache.php. After a var_dump($parameters); it became clear that my define()s were not being included early enough as the $parameters object didn’t have my own credentials. This makes sense – as an opcache, plugin behaviour should be included in caching, so the cache needs to be initialized before plugins.

During this process I disabled the password on the Redis container. Haven’t turned it back on yet, but it should work now…

This is still a problem. It would be a good idea for the maintainer to comment this until the feature is ready!

@peerpartners – take a look at the source HTML of your page and search for sb_instagram_at. This should be your API key, is it the new key you entered or the old one? (Check the plugin settings page for reference)

@metil if the feeds are all separate, you can add them as per these instructions. If you have any further questions about this, please open your own support ticket.

@ennfrancosaysblog great troubleshooting, thank you! The Javascript error is indeed gone, but I don’t see the usual network requests out to Instagram for this plugin. @smashballoon may have some input, but your site may need deeper investigation.

@metil you can display multiple feeds (see the description) but I would guess that multi-user single feeds won’t work.

Hey @ennfrancosaysblog – looks like you might have a different plugin giving you issues.

Problem script: AJAX request to lookbuck.com. https://imgur.com/iIdpLkX

@cortexvisual you should be able to update the plugin right now!

Don’t apologize – this is some of the fastest support response I’ve ever seen, awesome work!

@smashballoon – I’m still seeing that the old API key is stuck, despite a new key being populated in the plugin settings. Should we open a new thread?

edit: check that, it updated. Advanced caching, etc. Looking good!

Aw sweet, @smashballoon is here!

Might I propose an existence check on the data.data and data.data.username properties to avoid a blocking JS error?

Hey @ed, I’m not the plugin author, but I’m currently hunting a similar problem. I took a look at your site, and I can see that there’s a Javascript error preventing you from getting your feed:

/**/ jQuery112307114415710792243_1464806929804({meta: {error_type: "OAuthAccessTokenException", code: 400,…}})
meta: {error_type: "OAuthAccessTokenException", code: 400,…}
code:400
error_message:"The access_token provided does not match an approved application."
error_type:"OAuthAccessTokenException"

Looks like your access token is invalid – try getting a new one through the “big blue button” at https://www.munamommy.com/wp-admin/admin.php?page=sb-instagram-feed&tab=configure

If this doesn’t work, then you might be in my boat – I updated my token, but it is still set to the old token in the HTML source, and I haven’t figured out why it won’t change.

To see if your token has changed in your HTML, “View source” of your home page and look for this text: (line 1256)

<script type='text/javascript'>
/* <![CDATA[ */
var sb_instagram_js_options = {"sb_instagram_at":"1205343594.97584da.f2687fa9fd8f4c1ea891a28f9544be7b"};
/* ]]> */
</script>

If the token update worked properly, you should see this line change.

Why is this code even here? Yeah, creating the file will solve the issue… but this is still useless code. Half-baked feature maybe?

Couple of hours of hunting here… it’s the mod_authz_core.c module in the /wp-includes/.htaccess file. My dev server (Site5) doesn’t have this module, and the production GoDaddy box does, and it causes wp-tinymce.php and its compiled scripts to be denied.

<IfModule mod_authz_core.c>
    Require all denied
</IfModule>

How I figured this out:

I created a test file at webroot (same directory as wp-config.php) named test.php and populated it with this:

<?php print_r($_REQUEST); ?>

Then I edited the webroot .htaccess file and added this to the very top:

<IfModule mod_authz_core.c>
  RewriteCond %{REQUEST_URI} test.php
  RewriteRule .* test.php?authz=getbent [L]
</IfModule>

So if the server does have mod_authz_core.c installed, visiting /test.php will dump out an extra GET variable. The dev box that doesn’t have this module prints the following (shortened up a bit):

Array ( [_ga] => GA1.2.1458764591.1437866529 [wordpress_test_cookie] => WP Cookie check [wordpress_logged_in_d5eb8073a5244643c7eb647ae837bc24] => user|1234567890|j39f203j9j|2j03f [wp-settings-1] => editor=html&libraryContent=browse&hidetb=1&wplink=0 [wp-settings-time-1] => 1446786369 [PHPSESSID] => f3j829 )

… and the same setup on the GoDaddy server prints this:

Array ( [authz] => getbent [PHPSESSID] => mnalfnli [_ga] => GA123fj3f9.232f.f [wordpress_test_cookie] => WP Cookie check [wordpress_logged_in_ab293761296bd4] => user|1234567890|j390f2j39|fa3m9j3j9pa [wp-settings-1] => editor=html&libraryContent=browse&hidetb=1&wplink=0 [wp-settings-time-1] => 1446790629 )

You can confirm this yourself by simply modifying the /wp-includes/.htaccess file and commenting the module lines:

<FilesMatch "\.(?i:php)$">
  <IfModule !mod_authz_core.c>
    Order allow,deny
    Deny from all
  </IfModule>
  # <IfModule mod_authz_core.c>
  #  Require all denied
  # </IfModule>
</FilesMatch>
<Files wp-tinymce.php>
  Allow from all
</Files>
<Files ms-files.php>
  Allow from all
</Files>

Commenting these lines will permit the tinyMCE scripts. A potential solution would be to remove the mod_authz_core.c test and just stick with the good ol’ Order allow,deny directive, like so:

<FilesMatch "\.(?i:php)$">
  Order allow,deny
  Deny from all
</FilesMatch>
<Files wp-tinymce.php>
  Allow from all
</Files>
<Files ms-files.php>
  Allow from all
</Files>

… but since this is a plugin-inserted file, we don’t have much control over what is generated. The only lasting solution I have right now is to disable the wp-includes protection. This is probably a good issue for investigation by Sucuri.

Thanks man! Much appreciated ??