Endymion00
Forum Replies Created
-
Forum: Plugins
In reply to: [W3 Total Cache] Issue after updating W3 Total Cache to version 2.9.3In my experience this bug broke the Rollback plugin as well so I had to download the “w3-total-cache.2.9.2.zip” and just use the upload plugin / replace method.
It also had broken the Elementor Editor and running Yoast’s Start SEO data optimization tool.
See the same thing, at least with Elementor Forms so far. Worked fine before latest version.
I just figure that since a private variable products works, that there just may be a bug with the simple product doing the same. Otherwise it works fine and no problem with the theme. It’s not a big deal, but probably something to look at per the difference between the standard product types functioning differently for some reason when both are private. It would ease confusion for end clients who don’t necessarily understand the ins and outs of these things when they’re working on their own.
Looks like you have much more going on than we’re discussing. Make sure your Elementor plugins are up-to-date and you’re running a recent version of PHP.
In the interim try adding these to your wp-config.php file.
// Disable display of errors and warnings
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );The7 support left a comment on ThemeForest stating this will be fixed in version 12.1.1
Even though it’s a 404, it’s actually related to a ModSecurity block. It’s not just WordfenceOptions that gets blocked, but other similar Wordfence pages. This is the exception I went with in my modesec2.user.conf file that keeps the focus narrow so the rule still applies elsewhere. 90520 is a custom id, so you can use your own preferred ID if you have a conflict.
# Wordfence Options SecRule REQUEST_URI "/wp-admin/admin.php\?page=Wordfence" \ "id:'90520', \ phase:2, \ t:none, \ nolog, \ pass, \ ctl:ruleRemoveById=390149"I ran across the same issue, but existing sites load fine, it was only a new install that wouldn’t let me load the pages and since it’s not just WordfenceOptions that gets block, but other similar Wordfence pages, this is the exception I went with in my modesec2.user.conf file that keeps the focus narrow so the rule still applies elsewhere. 90520 is a custom id, so you can use your own preferred ID if you have a conflict.
# Wordfence Options SecRule REQUEST_URI "/wp-admin/admin.php\?page=Wordfence" \ "id:'90520', \ phase:2, \ t:none, \ nolog, \ pass, \ ctl:ruleRemoveById=390149"We successfully fixed this issue and an update should be coming soon.
I’ve replied to the support email with some remaining issue, so the details are in that email.
Sent contact form.
If you want, I can take a look on a site or if you’re close to releasing the next version I can wait for that one as well.
And one last thing to confirm that it is the missing customize_presets_settings that’s the issue.
If I add the following to the wp_options table in the database before updating, the plugin then keeps it set to default as one would expect when updated.
option_name = customize_presets_settings
option_value = default1Anyone missing this (installs with the free version with no prior loginpress data in the database or no other selectable theme options) will get switched to Minimalist on update and won’t generate the customize_presets_settings options until Default is selected and saved.
Pro users already having selected another theme should also not have an issue I would expect.
I’ve provided more than enough specific detail for a developer to easily check and fix. I’m done.
If it’s not related to “customize_presets_settings” then there must be some other setting doing it, some other option that’s making it think it’s a new install on update, since regardless of your video of which I don’t know if the database is clean of all loginpress data before installing. This would likely be an essential part of the test.
It also may be that installing 1.8 first sets things up differently than the older versions (whatever I started with) did and wasn’t corrected over updates getting me to 1.8
I just know that 3.0.2 does not set it correctly for me. I reviewed any databse option containing loginpress and didn’t see anything assigning the default theme. I expect that it only appears in Pro when another is selected. I don’t see “customize_presets_settings” and it looks like that is not immediately created on updating to 3.0.2 either. It only appears after I fix the theme back to Default. Since this is the first time there’s 2 choices in the free version, it’s the first time “customize_presets_settings” is being created when the theme is changed. Again the lack of this setting may still be what causes it to default to Minimalist since it is your new “default” on new installs and with no existing “customize_presets_settings”, it switches it to Minimalist.
With all this information should be able to add the case of updating from a pre-3.0 version, checking for the existence of “customize_presets_settings” and if not found, set it to the Default theme rather than Minimalist, because if it does exist, then that would mean they’re running Pro and are using a different theme than the defaults already and should be carried over accordingly.
Otherwise I’ll just have to manually fix each site’s theme selection on updating which is around 140 sites, which is why I’ve been pushing to resolve this.
So, 3.0.3 will fix this?