robertservebolt

Hello! No, we’re still dependent on jQuery, and as long as our plugin is active and the WP Admin bar is present then jQuery will be loaded (unless you add the snippet I sent you earlier). I do not have any timeframe on when we will transition away from jQuery unfortunately.

Kind regards
Robert S?ther
Servebolt AS

Hello!
I’m sorry, but this is not a feature we will add to our plugin as of now. The current feature is ment to help slow queries mainly in relations to WooCommerce (due to the sometimes heavy meta queries). I guess adding these indices manually to meet your need will be the best option as of now.

Kind regards
Robert S?ther
Servebolt AS

Hello! Sorry for the long wait. Yes it should be fixed. Please let us know if you are still experiencing issues regarding Redis and the menu cache feature.

Kind regards
Robert S?ther
Servebolt AS

Hello Sam!
Thanks for reporting this. I was able to replicate the error (using open_basedir restrictions) locally. The fix will be part of the next release.
Kind regards
Robert S?ther.

Hello!

We’ve now released v3.5.3 which should resolve the issue with the transients. Future transients are set with expiry (and will thus no longer be autoloaded) and existing legacy transients will be cleaned up via a database migration. In terms of “cache purging” of the menu we do that in some cases:
– When you change the “page on front” in the WP reading settings
– When you change menu items in a menu
– When you change the theme position for a menu

You can also purge all menu cache by going to WP Admin -> Performance Optimizer -> Menu Optimizer and click “Purge all menu cache”.

Please let us know if this did not solve your issue and we can investigate further.

Kind regards
Robert S?ther
Servebolt AS

Hello Rookie!

Thanks for the feedback. I added this as a feature-request in our internal issue tracking system. I cannot promise anything, but I really do like the suggestion. You will hear from us if/when we decide to implement this.

Kind regards
Robert S?ther
Servebolt

Hello!
Thanks for raising this issue. We are aware that our plugin is dependent on jQuery, and we are currently using the jQuery-version that WordPress supplies. We have slowly started the transition to vanilla JavaScript, but we are not quite there yet.

Only loading the file “cache-purge-trigger.js” whenever the cache feature is active is definitely a good idea, but this is not something we’re planning to change anytime soon.

You could disable output from the plugin to the admin bar by adding the following code:
add_filter('sb_optimizer_display_admin_bar_menu', '__return_true');
if (!is_admin()) { add_filter('sb_optimizer_should_load_common_assets', '__return_false'); }

This will remove the admin bar output as well as preventing the script/style files from being loaded when viewing the front-end of your site. I understand that this is not an ideal solution, but it should at least solve the jQuery-conflict that you are experiencing.

I hope this answered your question. Feel free to reply if something is still unclear.

Kind regards
Robert S?ther
Servebolt

Hello again!

Menu cache feature
Sorry to hear that the menu cache-feature is still not working as expected. I suspect that our feature is unfortunately incompatible with your theme. As mentioned earlier I do think that our upcoming release will fix this.

In regards to the timeline of release – my guesstimate is that the release will happen some time in late January next year, or early/mid February. But again, I cannot make any promises.

MO-file cache feature
Regarding the MO-file cache feature – I’ve added a prefix to the transient name, so that one can more easily debug whether the MO-file is cached or not. The prefix is “sb-optimizer-text-domain-loader-“.

The feature is quite simple from a code perspective, and as long as there are no conflicts in regards to the “override_load_textdomain”-filter it should work as expected.

The transient expiration happens whenever the file is updated, since we’re using the file modification time. So – as long as the MO-file is not updated on the disk then the cached version will persist in the database. If the file is updated, then the cache will be updated. So this should sort itself out.

In regards to Redis – our feature is built on top of WordPress-functions, so if the Redis configuration work with WordPress then it should work with our feature as well. I do know that one can exclude transients from Redis, so you would need to ensure that this is not the case for you.

I hope this answered your questions. Feel free to elaborate/reach back if something is still unclear.

Kind regards
Robert S?ther
Servebolt

Hello Sam!
Sorry to hear about your troubles adding indices. In our plugin you can run database optimization both from the GUI (WP Admin) or via WP CLI.

How to trigger from WP Admin:
1. Go to WP Admin -> Servebolt -> Performance Optimizer
2. Go to the Database-tab
3. Inspect the tables in the section “Database Indexes”. Here you can add indexes for each table, one at a time by clicking “Create index”.

In the section below there is also a feature to convert any tables that uses the MyISAM storage engine and convert them to InnoDB instead. This removes the known issue with MyISAM that causes database locking.

You can also click the “Optimize!”-button at the bottom of the page. This will trigger both the addition of the indices as well as the MyISAM/InnoDB storage engine fix.

How to trigger from WP CLI:
wp servebolt db optimize
This will trigger both the addition of the indices as well as the MyISAM/InnoDB storage engine fix. There is no way of triggering the index addition process using WP CLI. This is currently only possible from the GUI.

Note that our plugin runs database optimization by running MySQL queries (without any concurrency). As long as the query finishes without any errors or interruptions then the operation should work as expected. In terms of timeout it might be smart to use the WP CLI-option as there is usually no timeout policy.

I hope this answered your questions. If not then please do not hesitate to ask!

Kind regards
Robert S?ther
Servebolt

Marking this as resolved. Please contact us if you are still experiencing any issues.

Marking this as resolved. Please contact us if you issue still persist.

• This reply was modified 3 years, 6 months ago by robertservebolt.

Marking as resolved.

Hello!
No, the database optimization is a one time action that makes certain changes to your database. After the optimization are ran you do not need to keep the plugin active. But – we just released v3.2 which has some neat features in regards to optimizations for WordPress, but they require the plugin to be active tho. I recommend you to check them out!

Have a great day!

Kind regards
Robert
Servebolt

Hello! This is unfortunately a long standing bug in our plugin and it is related to PHP buffer size and usually caused by plugins sending output too early in the loading process. Some websites experience this and others don’t – it all boils down to the complex setup of a website. Let my try to explain:

We set the cache headers pretty late in the WP load cycle, and this is because we need to resolve for example the current post to see if we should actually cache it or not. Unfortunately some plugins/themes output data very early in the loading process – this can be anything from whitespace, markup, or error messages. This output will in many cases exceed the PHP buffer size, and this again causes the headers to be sent early since the headers will be the first part of the HTTP response. This again causes us to act too late and we’re then not able to set the correct cache headers.

This is unfortunately a bit tricky to debug. One solution is to increase the PHP buffer size, but the best solution is to find out what causes this output before WP starts to print the actual template markup. One way of doing this is deactivating plugins one by one and see when the “headers already sent” message disappears. If the error still persists after plugins are deactivated then I would check elsewhere, perhaps in the themes, in mu-plugins, perhaps even trying to reinstall WordPress. I hope this helps, and I sincerely wish we had a better solution to this, but the way WordPress is structured makes it a bit hard.

Kind regards
Robert from Servebolt

Hello! We have now released v3 (currently at v3.0.1) of this plugin. This should resolve the issues that you referenced in your post.

1. We’ve added autocomplete=”off” to all input-fields containing credentials etc. Previously we had this only on the form-element, but it seems that this is not always respected by all browsers unfortunately.

2. If I understand correctly you are using Cloudflare APO. There has been done some changes to the cache header logic in v3, so I would recommend you to try again and see if the error still persist. If so then please let us know.

3. The undefined constant “SERVEBOLT_PATH”-issue has been resolved in v3.

4. If I understand correctly you get an error whenever you delete the plugin. This issue is also resolved in v3.

Thanks for the bug report, have a great day!
Kind regards
Robert from Servebolt