codifex

This plugin relies on jQuery. I wished this was not the case, but it’s a great plugin anyway.

I am pretty familiar with Cache Enabler and there is nothing their support could do to change the situation. Cache Enabler supports two modes of operation:

• PHP mode: Every request to a page is directed to a PHP script that serves the page from the cache. If cache expiration is enabled, this script checks if the cached version is recent enough and refreshes the cache in case it’s too old.
• Advanced mode (faster, the configuration I am using): PHP is bypassed completely, pages from the cache are served directly by Apache (configured via .htaccess). No expiration check can be done in this mode of operation. The cache can be cleared via a cronjob, but as I described this is not a viable option.

I chose CF7 because it was compatible with the (fast) advanced mode and it would be great if it were compatible with this mode of operation in future too.

The call to admin-ajax.php is used as the nonce endpoint (nonceEndpoint) and is only emitted if CF 5.4 is active, see the snippet from the page’s HTML in my post #post-14130462 above.

Is it safe that multiple visitors use the same nonce because the same cached version of the page is served to them by the server?

Having to set a cache refreshing interval poses a huge problem:

We use Cache Enabler’s advanced configuration. This bypassses PHP completely, therefore also bypassing checks for expiry of a certain cached version of a page. It might work by clearing the entire cache via a cronjob, but unfortunately this feature is not available on all of our servers (shared hosting). More information on Cache Enabler’s advanced configuration: https://www.keycdn.com/support/wordpress-cache-enabler-plugin#will-cached-page-expiration-still-work-if-the-advanced-configuration-is-used

In addition, most of our sites are low-traffic sites which generate the cached version when a user visits the page and it’s not yet in the cache. In other words, the page cache gets filled over time. Therefore the speed benefit of serving a cached version to subsequent users would be lost for most users if the cache is cleared every X hours.

• This reply was modified 3 years, 8 months ago by codifex.

There is only one contact form in the page footer, direcly on the start page.

I assume that the code below (taken from the cached page’s HTML code) is generated by the plugin, as it is not generated when using CF7 prior to version 5.4 (I replaced the nonce with “NONCE” and the domain name with “…”:

<script type='text/javascript' id='wp-api-fetch-js-after'>wp.apiFetch.use( wp.apiFetch.createRootURLMiddleware( ".../wp-json/" ) );
wp.apiFetch.nonceMiddleware = wp.apiFetch.createNonceMiddleware( "NONCE" );
wp.apiFetch.use( wp.apiFetch.nonceMiddleware );
wp.apiFetch.use( wp.apiFetch.mediaUploadMiddleware );
wp.apiFetch.nonceEndpoint = ".../wp-admin/admin-ajax.php?action=rest-nonce";</script> <script type='text/javascript' id='contact-form-7-js-extra'>var wpcf7 = {"cached":"1"};</script>

Submission of the contact form fails some time after the cached version of the page was generated. The console shows these errors when the page is loaded and when the form is submitted:

Error HTTP 403 for .../wp-json/contact-form-7/v1/contact-forms/199/refill?_locale=user, the JSON response says rest_cookie_invalid_nonce.

Error HTTP 404 for .../wp-admin/admin-ajax.php?action=rest-nonce, supposedly due to the invalid nonce.

The REST API is enabled. This can be checked by appending ?rest_route=/ to the website address.

When clearing the cache or bypassing the cache by appending a query string such as ?test123 to the address, contact form submission is successful for some time. After some time submission fails (nothing happens, errors in the console).

I guess that the problem might be caused by the nonce that is emitted by the CF7 plugin to the page’s HTML code. Possibly submission fails after the nonce has expired.

Sure, just one example: https://mieterbefreiung.org/ (contact form in the footer). The website uses the Cache Enabler plugin for the page cache in combination with Autoptimize (configured to exclude wp-includes/js/dist). If you bypass the cache by appending a query string to the URI, the contact form works fine, if the cached page is served it does not work (errors in the console, no submission).

/wp-admin/admin.php?page=nextcellent-gallery-nextgen-legacy shows the following warning when using the plugin witz PHP 7.2:

Warning: Use of undefined constant BLOGUPLOADDIR - assumed 'BLOGUPLOADDIR' (this will throw an Error in a future version of PHP) in [...]/wp-content/plugins/nextcellent-gallery-nextgen-legacy/admin/class-ngg-overview.php on line 84

The warning is shown next to the “Add new pictures” button.

I believe that all the compatibility warnings can be fixed by minimal changes to the code. A fixed version of the plugin would be highly appreciated!

• This reply was modified 6 years, 10 months ago by codifex.

It seems that enclosing the script in <!--noptimize--> ... <!--/noptimize--> fixes the problem.

It seems that the ‘wpseo-dismiss-about’ entry with value ‘seen’ is missing in WP’s usermeta table. I was able to fix the problem by adding such an entry.

Same problem here. The message was already hidden and I clicked the unhide button. Unfortunately it cannot be hidden any more.

Problem solved (share count 0 shown correctly for pages not yet known to Facebook, no error shown in the status tab). Thank you very much for the fix.

I think I have tracked down the problem:

When performing the check

https://graph.facebook.com/?id=https://www.example.org

for my domain, the resulting JSON document is just

{
   "id": "https://www.example.org"
}

Then I checked the page using Facebook’s Sharing Debugger. It reported that the page has not yet been shared on Facebook. Then I fetched the scraping information.

After doing that the returned JSON looks similiar to the sample you posted above and the share button for this specific page shows 0. In addition, the error in the plugin’s “Status” page disappears if this has been done for the WordPress site’s site URL.

However, the problem persists for any page which has not yet been shared on Facebook. Facebook’s Graph API returns the ID only and the plugin seems to treat this as an error and consequently does not show the count.

I am not sure if Facebook’s behavior is “by design” or if it has been changed recently.

By the way, I am using WordPress 4.6 with version 4.2.1 of the plugin.

Thank you for your effort!

Here is some more information (domain replaced by example.org, timestamp replaced by #):

Call: https://example.org/de/wp-json/shariff/v1/share_counts?url=https%3A%2F%2Fexample.org%2Fde%2F&services=facebook%7Cgoogleplus&timestamp=#

Content of the resulting JSON file:

{"googleplus":0,"timestamp":#,"url":"https:\/\/example.org\/de\/","updated":"1"}

Facebook is missing, although it has been requested.

Kindly let me know if you need any further information. Thank you in advance for any advice.

The problem occurs in both multi-site installs and single-site installs of WordPress.

• This reply was modified 8 years, 2 months ago by codifex.

It seems that replacing all calls to split in wp_minify.php with calls to explode solve the problem (not yet tested heavily).

Thank you for the quick helpful reply, worked like a charm.