pjv

Answers to your questions:

There are no shortcodes in the post.

I can’t deactivate other plugins because this is a busy, active, multi-author site.

The browser console shows the following errors:

Uncaught TypeError: Cannot read property 'coerce' of undefined editor-view.js:17
Uncaught TypeError: Cannot read property 'unbind' of undefined plugin.min.js?wp-mce-4310-20160418:1

i personally use a plugin called Nginx helper to do this, it works for Nginx fast cache or Redis cache, I don’t know if it works if you don’t use Nginx, but you can check it out here:

Nginx helper is for managing PAGE caching (either via files with nginx fastcgi cache, or in memory with Redis). This plugin is for doing OBJECT caching with Redis.

Object caching is a totally different thing from page caching and nginx helper has no effect whatever on object caching.

FWIW, I solved this on my site by using the plugin: WordPress HTTPS and adding the string /affiliate-home/ in the URL Filters box and checking the Force SSL Exclusively option.

Using WooCommerce, I also had to turn OFF the option Force HTTP when leaving the checkout in WooCommerce->Settings->Checkout->Checkout Options.

This causes all the affiliate related pages to be SSL (which seems like a good thing in any case) and the affiliate login page no longer redirects to the WP login page.

In my case, this was/is happening because the protocol on the action URL on the affiliate login form is ‘//’. My site requires secure access to the wp login url (https://) so when the form tries to submit from the insecure affiliate login page with the protocol neutral URL, the request is http and wordpress then redirects to the WP login page secure url.

Would actually be nice, I think, given the nature of all the pages under affiliate-home if there was an option to force SSL for the plugin as a whole.

really. no releases without changelogs!

i diffed the repository from 1.3.18 to 1.3.19 and the changes are:

1. remove an X-CF-Powered-By header
2. change 4 URLS that are pointing to stuff at cloudflare whose path appears to have changed.

5 days later, 2.6.17 still latest shipping version of the plugin, still critically broken.

This issue is not resolved.

2.6.17 which is critically broken is still being made available for updates and new installs. No fixed update has been made available.

Honestly, as a fellow producer of paid WordPress plugins and as a paid customer of MailPoet, this is pretty disgraceful.

I’d say that after sending emails at all, the second most important thing for mailpoet to do is let the recipients of those emails click links in them to get to content on the WordPress site that sent the email.

That an update including a bug in this functionality was pushed to everyone does seem like pretty poor testing, though as a developer I understand that bugs happen. But that a fixed release was not pushed within hours of reports of this fairly giant problem seems kind of… I don’t know… unconscionable.

That this issue is sitting here unresolved three days later seems like some kind of communication from mailpoet developers to mailpoet users / customers (yes, I own mailpoet premium).

I hope you can find a general issue by examining the apparent conflict with Ultimate Member, because I am also unable to activate Easy Facebook Like > v. 4.x and I am not running Ultimate Member, so the conflict must happen with other plugins as well..

Already did and yes it does fix all the meta descriptions for both the WooCommerce product category pages as well as the standard category pages for the og:description and twitter:description.

Awesome support as always.

Thanks George.

The fix is the following.

1. Edit metadata/amt_opengraph.php and replace line 284 with the following:

$description_content = sanitize_text_field( amt_sanitize_description( term_description( $tax_term_object->term_id, $tax_term_object->taxonomy ) ) );

Thanks for the fix. That seems to work for the og:description, but there must be several other places where a similar tweak to the function call parameters are needed for the meta description and the twitter description, right?

Are you talking about the <p> tag where the description is displayed on the page that I linked to, or somewhere else?

I’m trying to determine whether that tag is coming from WC or from the theme. In doing so, I took a look at a non-WC category archive page on the same site (https://breadtopia.com/category/recipes/) and noted that in the AMT generated meta tags, the meta description correctly uses the description that is entered for the category, but the og:description and the twitter:description display the generic description instead of the entered one.

I also notice that the theme is not displaying the entered description on that archive page as on the WC product category archive page, so I am still not sure whether it is WC or the theme that is wrapping the description.

Is this something you can work around in AMT or does it require a patch to WooCommerce? (I have contributed WC patches in the past).

I can’t say if it’s new or not – I just discovered the issue this morning and hadn’t been monitoring the meta descriptions on these product category pages before.