Support » Plugin: StatComm (StatPress Community) Multisite Edition » Version 1.7.66 stops multisite from serving pages

Viewing 9 replies - 1 through 9 (of 9 total)
  • Plugin Author WPReady


    Hi mdunham,
    thanks for your comments.
    I’m checking what is happening.

    Plugin Author WPReady


    The only improvement made to multisite was an important fix discovered last week. This problem affected kept other multisite plugins from running properly.

    Before launching the plugin to the public, it is tested on multisite and single site environments. I’m confirming that multisite should worked smoothly. Otherwise it can’t be released.

    So my guesses are the problem would be related with the fix mentioned above or there is some issue when the plugin was reinstalled.

    I have confirmation from ten sites that single installation solved most of the problems from previous one.

    I’ll be in contact if I found anything.

    Just so you understand the background, I had the previous version running on my own multisite network – and it was running just fine. But, the same version running on the multisite for the corporate system where I work was periodically locking up individual sites and in the final problem, locking up the entire network. We pulled it off the corporate system and I agreed to watch for the update and see what happened on my personal network when it was installed.

    When I installed it this morning, I used the standard plugin update routine. The sites all went down as soon as the plugin was activated by the update routine. Everything came back after I went into FTP and deleted the plugin. I then reinstalled the previous version by FTP and everything is working normally again. My guess is there are conflicts with other plugin or theme combinations somewhere but I haven’t been able to pin it down to a specific situation.

    Under the circumstances, I can’t risk bringing all my sites down during peak hours again – but if I understand you correctly – it appears that if the plugin was first deactivated, then deleted and then a installed from scratch on the network again, it should work.

    I can try that during low traffic hours tonight, but because of the risk of having the entire network lock up again, I can’t do it any sooner.

    That said, it isn’t a good practice for updates to require full reinstall as an alternative to lockups because some people will certainly just push the button when they have a number of updates to run and not have a clue what went wrong.

    I’ll watch for additional updates in this thread or updates to be pushed through (even though I know that is unlikely because of testing) and I will try the cold update tonight unless I hear something different. thanks for continuing to look into this problem. I think what the plugin itself offers is unique, and i do want to see it work.

    Plugin Author WPReady


    I really appreciate all the details you’re providing to pinpoint the problem. You stated clear from the beginning. This information is very useful to lead me to the issue.

    I’m in the process of comparing what would be the cause and I’ll let you know asap. My sincere apologies for the problem.

    Plugin Author WPReady


    According to the changes I made I narrowed the problem to 4 suspects ‘suppossedly’ to be minor:

    1-A fix consisting a variable serialization/deserialization to avoid some problems with different PHP installations.

    2-A fix to make the plugin relocatable.

    3-A fix to call deactivate_plugins on older versions. this code is activated ONLY if we try to install the plugin in a WP version <3.3. I guess we can discard this case.

    4-An important side effect affecting multisite plugins. The fix is very simple and I still believe this is not causing the problem, but I can’t discard anything.

    So my guesses are options 1 and ‘maybe’ (?) 2 and maybe 4 (?).

    While I’m going to make a few round of tests, I have a risky proposition for you, so I understand if you decide to decline it.

    What I suggest to solve this riddle is to enable debug and see the error produced when you activate the plugin.

    To do that you should insert this line on wp-config.php:

    define(‘WP_DEBUG’, true);

    and after that try to activate the plugin. That will bring down your site and will display the error. Write it down asap and rename the statcomm plugin folder to reactivate the site (You need FTP access to recover from the problem). That would deactivate the plugin at once and you’ll recover from the error in no time.

    It is a wacky proposition , I know.

    Plugin Author WPReady


    I confirm that serialization/deserialization has a problem that should be fixed before proceed.

    If I fix this problem would you volunteer to test it? I would appreciate very much but you should consider the risk involved.

    Thank you for your feedback.

    Plugin Author WPReady


    Current version 1.7.67 adrressed the problem you mentioned. Give it a try.

    It does work! Thank you. Sorry I couldn’t get to test it before it went out.

    But it works!

    Plugin Author WPReady


    Your feedback was relevant to catch the problem 🙂
    Noticed I added to the plugin credits thanks to that.

    Best regards

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘Version 1.7.66 stops multisite from serving pages’ is closed to new replies.