Various issues (htaccess, cache)

4. After clicking “Apply” on a bulk-delete of 17 comments, I got these messages on a blank page:

Warning: Missing argument 2 for WpSoL_SpeedOptimization::purge_post_on_comment_status_change() in /home/wwwcavou/public_html/wp-content/plugins/wp-speed-of-light/inc/wpsol-speed-optimization.php on line 131

Warning: Cannot modify header information - headers already sent by (output started at /home/wwwcavou/public_html/wp-content/plugins/wp-speed-of-light/inc/wpsol-speed-optimization.php:131) in /home/wwwcavou/public_html/wp-includes/pluggable.php on line 1174

Hi,

Thanks for your feedback, it’s really appreciated here.

1. Yes, because the major part of our users choose the plugin for that ?? Though we haven’t activated minification by default as it require testing. In your case indeed, this strategy is not smart, we maybe need to think about some more modulable activation process.

2. The Gzip compression activation doesn’t necessary require a new line to be added in your htaccess. We’re using a PHP function. You can check for it’s activation using your console like here: https://www.awesomescreenshot.com/image/1691651/56dd71004ba8491e65bffe4b8fa1ff68

3. Weird!, here’s what I got: https://www.awesomescreenshot.com/image/1691588/68fc9517360322e6ca84c835aa4f44be

What is your WP version, is it the 4.6? because they’ve change font recently, the new one is quite smaller. You can check this out live: https://addendio.com/try-plugin/?slug=wp-speed-of-light

4. OK I’ll ask the developer to check and fix that. If he can’t reproduce that, I’ll get in touch here shortly ??

Cheers!

Hi, thank you for your answer!

I appreciate your patience in going through my many points ??

It is not a major point, but I would suggest having the cache disabled by default. Doing otherwise might makes things easier for non-experts, but it could break things down when there is another caching system active. This might be the reason why two of the most popular caching plugins (WP Fastest Cache and WP Total Cache) have the cache disabled by default.

Concerning Gzip compression, I have activated it and run WebPageTest.org, but got an F for the “Compress transfer” test (see https://prntscr.com/cs0fe3); could it be that your PHP Gzip compression fails on our website? In any case, this is my console output: https://prntscr.com/cs0g0s. I do see the line “accept-encoding: gzip, deflate”, but please note that I see it also if I disable your plugin.

Concerning the UX problems, I am on 4.6.1; I can see with Addendio that 4.6 works fine. If I disable all plugins but WPSOL on my installation (cavour313.it), I can see that the buttons’ colors are fixed. The out-of-bounds menu name, though, stays the same. Weird!

Another small glitch: if I disable the cache, deactivate the plugin and reactivate the plugin, the cache is enabled again.

If you think it could help your developers, I am happy to give you the credentials of our admin area so that you can better debug these issues.

Thank you for your attention,
Guido

PS: I did not know of Addendio: great service, thanks!

Hey,

Yes, OK got it, on plugin activation the cache is automatically setup as active, as discussed. The button CSS style is definitively coming from another plugin that loads some CSS all over the admin side (it happens!).

About the Gzip, all our tests returns a green A grade. Could you create a free account on our website, referring to this post and use the support ticket? We need to test that deeply.

Addendio is a great service to find and test plugins. And it’s a friend that develop it, plus it’s all free ??

Cheers,

Yes, OK got it, on plugin activation the cache is automatically setup as active, as discussed.

Sorry if I wasn’t clear, but I am making a subtler point here, which is not specific to cache. The point is: when you de-activate and then re-activate a plugin, its settings should be preserved.

This is a default behaviour for all WordPress plugins, a standard on which webmasters rely all the time: re-activating a plugin should not change any setting in the plugin itself.

Many times during a webmaster’s activity the need arises to temporarily de-activate a plugin; it is not conceivable that re-activating it changes one of its settings, let alone the most important one.

About the Gzip, all our tests returns a green A grade. Could you create a free account on our website, referring to this post and use the support ticket? We need to test that deeply.

Ok thanks, I am going to transfer this issue on your ticket system.

In the meanwhile, a couple of more bugs:

1. The plugin adds a line to wp-config.php, which is perfectly fine, but it also messes up the whole file by doubling the end-of-line characters; see https://prntscr.com/cs3p6i.
2. De-activating the plugin should remove the line define( 'WP_CACHE', true ); in wp-config.php, rather than changing it to define( 'WP_CACHE', false );. Again this is a corollary of the theorem whereby installing and then removing a plugin should leave the website completely unchanged.

Thank you for your time,
Guido

OK thanks again, we will check that too.