Exavior

The JS file is /wp-content/uploads/fusion-scripts/cc3e432e4ddb090ffbea2b4850292edb.min.js?ver=3.11.10

It looks like the cache, that when purged addresses the issues, is part of “Nginx Helper” which was installed by the host. (Dreamhost). I’m wondering if we should just uninstall that. The UI made it seem like it was tied to Redis.

That plugin does have an internal setting to switch between “nginx Fastcgi cache” and “Redis cache” but the Redis option requires a hostname, port, and prefix, which we are not familiar with.

Thanks for your response!

I’ll reach out to them and see what I hear. Also, it’s not just a CSS issue, as since we switched CSS to be stored in the DB (to address this issue) we have a JS file that now randomly 404s. Seems to happen when site updates are made, but not all updates, so it’s hard to identify when/how it happens.

Either way, the temporary solution is to purge the cache, which leads to one big question I had. The “Redis Object Cache” plugin appears to have 2 levels of cache. One which is a general page cache, the other which is the object cache. The admin bar has links for “Purge Cache” and “Object Cache” management, but the settings page for the plugin (/wp-admin/options-general.php?page=redis-cache) has only a “Flush Cache” button, which seems to just flush the Object Cache, and does not fix this issue by purging the page chace. My question is why is there no “Purge Cache” option there as well? On mobile the admin tool bar does not display in normal portrait mode, so not having a readily accessible “Purge Cache” has been a bit of a hurdle.

I’m using Avada, but not WP Rocket. Seems like a lot of Avada users run into this issue with Redis caching, but I’ve never seen any solutions posted.

I changed the Avada setting for how CSS is stored, moving it into the DB rather than in files, and this partially fixed the issue, but now we randomly get a core Avada JS file that 404s, preventing images from displaying. This too is addressed by purging the Redis cache. (not the object cache)

I’m having the same issue. Any time we make changes to our site, Redis somehow deletes or disables our CSS so the pages load all jumbled. After a cache purge it’s fine, but it keeps happening causing us massive problems. We’re using Avada to handle our theme, which Redis should be compatible with, as it’s one of the larger page builders and is very common.

Having the same problem after updating the plugin. All permissions are set, the “clone” option is set to show in the admin bar as well as the posts list and edit screen. Right now it only shows up in the posts list, nowhere else.

I’ve disabled/enabled the plugin, removed and re-added all permissions, checked and unchecked just about everything… nothing works.

Also worth noting that after the plugin was updated nothing was checked in the “display” screen, which is not good.

Hoping in these last few months a solution has been found for this, even though nothing appears to have been posted here.

Edit: Looks like the “New Draft” option works now, but “Clone” never shows up anywhere. Guessing the two are basically the same anyway? (no info is given in the plugin, which would be nice)

Also worth noting the “New Draft” text is SUPER not helpful in some situations as that phrase does not have anything to do with copying or cloning. In the admin bar and post-edit mode the text shows as “Copy to a new draft” which is great, but in the post list it shows as “New Draft” which is bad UX.

• This reply was modified 3 years, 11 months ago by Exavior.

Any update on the new bug with “JavaScript Function on Slide” not working after updating to the latest plugin version?

I’m now seeing the following alert in the plugin settings page:

“You’re using <!–nextpage–> instead of <!–nextpart–> in 1 posts and/or pages. Do you want to implement the patch now? It will convert nextpage to nextpart and this plugin will work fine for these posts and pages as well.”

So you don’t have it working so the standard page splitting is properly supported? Again nextpart is NOT a valid option in WordPress as the visual editor supports ONE per article. Otherwise authors would need to edit their articles in code view, which is not practical.

New bug: in your latest update “JavaScript Function on Slide:” appears to no longer work. This is currently preventing us from launching our first project using your plugin. Issues with the “premium” plugin have already delayed us by around a month, so I’m hoping you can fix this ASAP.

I downloaded your automatic plugin installer since there is no other clear way to update the “premium” plugin without relying on old email links, which does not work for a company of our size. But there is a serious problem! The automatic update plugin appears to update the plugin without user interaction or approval. We need to test any and all plugin updates in our development branch before they are allowed into production, as any bug with a plugin could cost us thousands of dollars an hour if pages go down or it creates other conflicts. Please fix the updater so it can be manually triggered.

This is massively concerning because the latest update required me to define new settings that did not exist in the previous version of the plugin, like the new “Default post navigation” checkbox. Until I updated those plugin settings our post navigation was broken. That means if the auto-updater executed without permission all posts using the plugin implementation would have been broken. Scale that problem up to us eventually having hundreds of posts on multiple sites, and you can see how that would be a serious issue.

For now I am going to have to deactivate the updater plugin and activate it when we wish to update things, to prevent it from updating our production environments without permission.

The plugin settings page still says to use “nextpart” to split pages, but the WordPress visual editor is designed to only allow 1 “nextpart” in an article. So I’m not sure why you rely on that, as it’s not something people can actually do. Not every company is going to have people editing articles via the code view to add page breaks, there’s a reason WordPress has a standardized visual editor.

That said, I updated our article to use the default page breaks and it appears to work.

Updating the plugin automatically also blew away our CSS changes. It would be ideal if the plugin did not make additional HTTP requests for CSS files and let us use our own styles. Now we have to overwrite your styles with our own, which doubles the CSS and we still have an extra HTTP call, which slows sites down.

You do have the setting “Use Stylesheet? If unchecked, no styles will be added.” but that does not apply to the pro themes selected from the top dropdown menu, and there is no option to not have a theme.

I appreciate your responses and efforts to update the plugin. I’m glad we could get things working, and hopefully it will continue to improve.

Thanks!

I’d like to upgrade, but don’t see a clear way to do that with the “premium” version. It has no link to download the plugin, just the 3rd party plugin manager. I need to get this updated and working ASAP.

Thanks

I used WordPress default page break when I first installed the plugin, but a message popped up saying that page break was not supported by the plugin and it asked me if I would like the plugin to automatically convert them for me, so it did, and it converted them to the code I showed in the previous post.

Has that changed since I set this up a month ago with the non “premium” version?

The example URL still shows your page number as query string and not as #2, #3, #4, etc. Why is that? Is that related to it being a newer version than last one you gave me?

The code, as created by your plugin when it translates WordPress’ standard page break is as follows:

<!-- wp:nextpage -->
<!--nextpart-->
<!-- /wp:nextpage -->

The above code also shows as invalid in the WordPress default visual editor, which is not good. It would be nice if it could function with a standard element like the normal WordPress page break.

I can update it, but since you’ve chosen to make the “premium” version so it can’t be updated locally from WordPress, doing these manual updates is quite a headache, and not something I look forward to doing often… and clicking the link for updating the “premium” version takes you to a page for installing some 3rd party update plugin with NO links to download the actual update…

To make matters worse the official plugin page is a 404 error… https://androidbubble.com/blog/wordpress/plugins/jquery-post-splitter

So how exactly am I expected to update this? I’m for sure not planning on installing some random 3rd party auto-updater for this.

I’m sure you can see how upsetting this all is. This plugin has potential, but so far all we are getting is headaches and disappointment.

• This reply was modified 4 years, 11 months ago by Exavior.
• This reply was modified 4 years, 11 months ago by Exavior.

As we talked about here on this very page, we are using premium.

Here are my settings on 2 screenshots.

https://snipboard.io/X5tcBs.jpg
https://snipboard.io/783l1X.jpg

Again, we’re using AJAX and your plugin uses #2, #3, #4, etc for the pages, your example did not.

Your query string is updating with new parameters. Are you sure you are not overwriting your method from AJAX to something else at the post level? I’m also seeing a loading animation and the whole page getting darker, which don’t appear to be standard features of your plugin. Are you testing with the same plugin people like me are using?

Either way, what you are showing does not match what I’m experiencing.

Why do I have site.com/article/#2 for page 2 and you do not? Your example has a query string parameter for the page, which suggests the page has been reloaded.

Step 1 for you should be to make sure you have the same experience I do, with the #, then try adding custom query string parameters and see how it breaks.

Your example functions differently than what I have. You have no /#2 at the end of the URL for your 2nd page.

I can’t post the URL here as it is for a campaign that is not yet live (due to this issue)

Your example has the page number as a query string parameter. Are you sure you are using AJAX for that? It looks to me like the entire page is reloading in your example, which is not AJAX.

It looks like your plugin breaks if the article URL has query string parameters. That is REALLY bad since that’s a requirement of almost all professional sites.

For example. https://www.somesite.com/article/?a=123&b=456

If there are query string parameters the article just loops back to page 1 if you try and navigate.

How soon do you think you could have that fixed?