-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updating via IWP temporarily broke sites #862
Comments
@MarioKnight Thank you very much for the report. I'm sorry that this created unnecessary stress and work for you. We'll need to add an update from IWP to our testing matrix during the RC period to catch potential issues like this before future releases. @jaswsinc Can you take a look at the above report and let me know if you see something we might have missed when adding the Mobile Mode feature? |
@MarioKnight Thank you for this report. Can you please confirm for me that you do not have Mobile Mode enabled right now? Or that you didn't have it enabled whenever you did the upgrade, correct? |
@MarioKnight Also, would it be accurate to assume that your sites have the OPcache extension enabled? My hunch is that this was not caused by a bug in Comet Cache itself, but by this ongoing problem with OPcache not being cleared by WordPress core during plugin upgrades. If your sites are running OPcache, that might help us confirm that suspicion and find a workaround. In other words, do you think it's possible that just logging into the sites wasn't the cure, but that it was fixing itself after a short period of time; i.e., once the OPcache was expired/flushed automatically? |
@raamdev I'm referencing this line in Comet Cache. If those new constants are not yet defined (e.g., the OPcache still has an old copy of |
@raamdev I'm seeing another potential cause as well. Based on the feedback above from @MarioKnight, it looks like remote updates can potentially bypass this check. |
@jaswsinc Currently I don't have Mobile Mode enabled on any site. There were a handful of sites that utilize the Dynamic Version Salt section (and still do, at some point I'll convert them over to the new Mobile Mode). None of the sites reported to me were those sites. It seems safe to assume that OPcache is enabled to some degree, going by that the Comet Cache Stats/ Charts page does have OPcache information under the charts. I don't believe it was possible that the issue was fixing itself over time. I had a few tabs open incognito mode of the broken sites, and in every case there was no change until after logging in to the dashboard. While we were going through the IWP list, other colleagues continued to report sites to us leading me to be confident that affected sites stayed as such until login. |
@MarioKnight Thank you very much for that feedback. @raamdev So it looks like in this case, the problem is this check is getting bypassed. |
@jaswsinc I was reviewing the InfiniteWP GitHub issue where we tested IWP with the new way the Pro updater integrates with the existing WordPress update mechanism, and I saw that we had issues during testing when @MarioKnight Can you confirm that |
That said, the PHP Fatal Error reported at the top of this issue is clearly not something that should be occurring, in any scenario. I'm just wondering if the problem we're seeing here is a combination of issues and not just a problem with the Comet Cache version check routine being bypassed. |
@raamdev It appears that none of them had |
…location` when upgrading to latest release. See [Issue #862](wpsharks/comet-cache#862). - **Bug Fix:** Enhancing compatibility with InfiniteWP, ManageWP, and other remote management tools for WordPress. See [Issue #862](wpsharks/comet-cache#862). - **Cleanup:** Removed an old API call that checked for a newer lite version. No longer necessary.
- **Bug Fix:** Resolves error `Unable to determine UA info directory location` when upgrading to latest release. See [Issue #862](#862). - **Bug Fix:** Enhancing compatibility with InfiniteWP, ManageWP, and other remote management tools for WordPress. See [Issue #862](#862). - **Bug Fix:** Incorrect time calculations whenever load average checks are enabled in Comet Cache configuration options. See [Issue #853](#853). - **Cleanup:** Removed an old API call that checked for a newer lite version. No longer necessary.
Fix Confirmed Working, see comments here |
_**Note:** This is a Comet Cache Pro maintenance release._ - **Bug Fix** (Pro): Resolves error `Unable to determine UA info directory location` when upgrading to latest release. See [Issue #862](#862). - **Bug Fix** (Pro): Enhancing compatibility with InfiniteWP, ManageWP, and other remote management tools for WordPress. See [Issue #862](#862). - **Bug Fix** (Pro): Incorrect time calculations whenever load average checks are enabled in Comet Cache configuration options. See [Issue #853](#853). - **Cleanup:** Removed an old API call that checked for a newer lite version. No longer necessary.
Comet Cache Pro v161226 has been released and includes changes from this GitHub Issue. See the v161226 announcement for further details. This issue will now be locked to further updates. If you have something to add related to this GitHub Issue, please open a new GitHub Issue and reference this one (#862). |
With yesterday's Comet Cache Pro update, I manually updated my personal sites via the WP dashboard with no issues. This morning, I updated ~250 sites for clients through InfiniteWP. Soon after, I received reports of sites yielding a 500 error. In the error logs for them, I saw the following:
I tried to go into the WP dashboard for a few of them, and was successful. Interestingly, sites started working afterwards. I eventually found that just by logging into the WP dashboard, sites would immediately load as if nothing happened. While this isn't an issue for me now, as a colleague and I went through the IWP listings to load up each dashboard as a precaution, I wanted to note this in case this is something that can be found and prevented in future updates. Please let me know if you need anything from my end to help troubleshoot.
The text was updated successfully, but these errors were encountered: