Forum Replies Created

Viewing 15 replies - 1 through 15 (of 38 total)
  • @massimod

    I realize that OPcahce only caches PHP code. My comment that “time-to-first-byte increased about 20-percent on average compared to using only PHP oPcache” was intended to express that using Gator Cache’s new Object Cache in combination with OPcache increased time-to-first-byte compared to using only OPcache.

    However, that was measured from various U.S. locations using http://www.webpagetest.org/ with a 1gbps up and down dedicated commercial fiber internet connection on my end. Most WordPress servers don’t have 1gbps internet connections and increased latencies resulting from lower bandwidths would reduce the percentage of degradation with, compared to without, Gator Cache’s new Object Cache.

    Unchecking that box didn’t fix what checking it had caused. However, as explained above, I already fixed that myself a couple days ago.

    The malfunction was that it was impossible to activate, deactivate or install new plugins on 16 servers until I eventually discovered after considerable troubleshooting that Gator Cache was causing the problem.

    My intent was merely to give you the benefit of one user’s reaction to a change you made to the plugin. I have been very pleased with the simplicity, efficiency, and speed performance of Gator Cache compared to other caching plugins. You provide it free, so users have no basis to complain if you make changes they don’t like. If you think my reaction has basis then consider whether you should do anything different. If you don’t ignore it. I will continue to use Gator Cache so long as it meets my needs better than alternatives. I will just be a little less trusting and will carefully test new versions off-line before installation, which is something I normally do with new versions of plugins anyway.

    Thanks for all the time you obviously have spent developing Gator Cache. It has worked very well until the issue we have been discussing.

    That probably is because you hadn’t enabled the option on multiple servers like I had. I had 16 servers malfunctioning and a total of 32,000 files scattered through a bunch of new directories to delete after troubleshooting to find the problem. Deleting the files was of course not a terribly big deal, but it would have been nice to know selecting an “innocent-looking” option on each server would result in all that.

    Of course, it might not have been necessary to delete them, depending on the nature of the caching bug or bugs that caused the malfunctions, and whether I had wanted to use the caching. At this point I don’t want to use it, because time-to-first-byte increased about 20-percent on average compared to using only PHP oPcache, which of course caches in memory.

    This issue is marked as resolved, but it is anything but resolved. The “Enable Object Cache” option is marked “beta,” which provides warning that there might be unknown bugs. However, the issue here goes way beyond unknown bugs. You knew the selection would result in automatic creation of thousands files distributed through multiple sub-directories. It is ridiculous to put an option like that in production software without a clear and obvious warning about such radical consequences.

    In my case that selection caused several serious malfunctions hours after the selection was made that took hours of troubleshooting to resolve. I only have myself to blame for being willing to test a new option for bugs. However, it is disappointing to find that you knowingly provided an option that created thousands of files in many new directories without warning.

    I am not using discount hosting. I run my own state-of-the-art servers. Storage space is not an issue, but creating a huge mess on multiple servers is an issue. A selection that radical should not be released in a plugin used in production applications without a clear and obvious strong warning and explanation of known consequences. In fact, I don’t think it should be included in such a plugin at all. If you want to beta-test an option with such an extreme result, release a beta-test version of the plugin.

    That was quick!

    Thanks.

    The new Version 2.0.4 works fine at multiple websites with no error messages.

    Thanks. I will give it a try and let you know whether that change fixed the error message.

    Further testing suggests this problem may occur only with sites running in subdomains. It occurs repeatedly each time TML 6.4.2 is activated at a development site running in a subdomain, but does not occur at an identical http://www.domain.com site.

    The result could be serious if someone isn’t able to use mysqlcheck -r and hasn’t backed-up their database before activating 6.4.2, because removing TML from the plugin directory does not restore login access.

    Sorry, the problem was on my end. Please ignore.

    I just installed the plugin after a fresh WordPress 4.3.1 installation and the same errors are being logged, even though the plugin seems to otherwise work fine.

    Yes, the VERSION constant is defined on line 24 of theme-my-login/includes/class-theme-my-login.php in the downloaded source file. As you said, that file must not have copied over to the server. Maybe the file date was newer on the server for some reason. I can’t tell now, because I had reverted to TML 6.4 which changed the server file times. Regardless of what happened, deleting and replacing all TML files on the server with TML 2.4.1 files fixed the problem.

    Thanks for your help.

    In addition to line 99, the same undefined constant is in lines 118, 258, and 353. Changing “VERSION’ to ‘version’ in each of those lines seems to correct the problem.

    Removing the Red Herring plugin seemed to resolve the problem, but it occurred again when I tried to upgrade TML at another website. Now I know why.

    Line 99 of ‘\admin\class-theme-my-login-admin.php’ contains the following code:

    if ( version_compare( $this->get_option( 'version', 0 ), Theme_My_Login::VERSION, '<' ) )

    ‘VERSION’ is an undefined constant, which causes a fatal PHP error if the plugin needs to be upgraded, but not if it already has been upgraded.

    That problem was found to be due to a conflict with the Red Herring plugin, which contains a warning that it breaks some themes. It also apparently breaks some plugins. TML Version 6.4.1 works fine without the Red Herring plugin.

    That fixed the fatal error.

Viewing 15 replies - 1 through 15 (of 38 total)