Alexander Celeste

@d3395 The bug itself is fixed, but now the main page on my site that uses that shortcode a lot is noticeably slower to load with 4.0.2 than it is on 3.5.2. I feel like there is some sort of significantly slower performance with the newer encryption scheme than the compatible one. The fix is to switch schemes, but it may be worth clarifying somewhere the possible performance gap if CryptX would be used on a page, like where my shortcode gets used, that contains dozens of email addresses.

@d3395 The shortcode is fairly complex and interlaced as part of our custom add-on for the Paid Memberships Pro plugin and the Users Insights plugin. The site uses a custom child of the Astra theme. I’ve extracted the shortcode function and its direct dependencies to a Gist that you can look over:

https://gist.github.com/alexclst/0830ea821dc8b9b00ad126c4e80cdbb2

That also includes the content of the page with the shortcode. I know this may be more than you were bargaining for, but it gives you all the gory details to try and reproduce. For the moment I am just not updating the live website to CryptX 4.0.0 or above, but do have that update on my local copy of the website to be able to see the problem.

• This reply was modified 11 months, 2 weeks ago by Alexander Celeste.

I’ll post a support request there, but I want to emphasize that this only started with this free plugin’s update, and so should be something this free and public support forum can help figure out. So at minimum it was good to post here so others who may have similar issues see it.

Oh great… Well, at least we know it is a safe enough update. But still… Speaking as a plugin dev myself, folks can update the tested up to without bumping plugin version numbers. I do it all the time. Like, literally, never have I had to update a plugin for feature changes or bugfixes alongside bumping the tested up to number. So, nice to know, but an annoying habit of this developer.

There weren’t any javascript or PHP errors appearing in logs that I could find. This makes me wonder exactly what javascript could get in the way, when the javascript console showed no errors.

I tried on a blank WP install, and as you expected, that did work. The interesting thing is that I could then copy the photonic_options row from the blank WP’s options table to the live one, and all stayed in place, including doing the authentication step on the live site and the plugin could then save the refresh token for itself.

So perhaps something is awry with your plugin’s compatibility with something else on my site, but at least I could use a blank Local WP install as a workaround to get it to work.