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

Closed
MarioKnight opened this Issue Dec 22, 2016 · 12 comments

Comments

Projects
None yet
4 participants
@MarioKnight

MarioKnight commented Dec 22, 2016

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:

[22-Dec-2016 14:09:24 UTC] PHP Fatal error:  Uncaught exception 'Exception' with message 'Unable to determine UA info directory location.' in /home/xxxxxx/public_html/wp-content/plugins/comet-cache-pro/src/includes/traits/Shared/UaUtils.php:36
Stack trace:
#0 /home/xxxxxx/public_html/wp-content/plugins/comet-cache-pro/src/includes/traits/Shared/UaUtils.php(79): WebSharks\CometCache\Pro\Classes\AbsBaseAp->uaInfoDir('/browscap')
#1 /home/xxxxxx/public_html/wp-content/plugins/comet-cache-pro/src/includes/traits/Shared/UaUtils.php(122): WebSharks\CometCache\Pro\Classes\AbsBaseAp->getUaInfo(NULL, false)
#2 /home/xxxxxx/public_html/wp-content/plugins/comet-cache-pro/src/includes/traits/Ac/ObUtils.php(207): WebSharks\CometCache\Pro\Classes\AbsBaseAp->uaIsMobile()
#3 /home/xxxxxx/public_html/wp-content/plugins/comet-cache-pro/src/includes/classes/AdvancedCache.php(67): WebSharks\CometCache\Pro\Classes\AdvancedCache->maybeStartOutputBuffering()
#4 /home/xxxxxx/public_html/wp-content/advanced-cache.php(454): WebSharks\CometCache\Pro\Classes\AdvancedCa in /home/db5hh3rn/public_html/wp-content/plugins/comet-cache-pro/src/includes/traits/Shared/UaUtils.php on line 36

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.

@raamdev

This comment has been minimized.

Contributor

raamdev commented Dec 22, 2016

@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?

@jaswrks

This comment has been minimized.

Member

jaswrks commented Dec 22, 2016

@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?

@jaswrks

This comment has been minimized.

Member

jaswrks commented Dec 22, 2016

@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?

@jaswrks

This comment has been minimized.

Member

jaswrks commented Dec 22, 2016

@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 advanced-cache.php), then this line will not behave as intended in the latest release, which would result in that error.

@jaswrks

This comment has been minimized.

Member

jaswrks commented Dec 22, 2016

@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.

@MarioKnight

This comment has been minimized.

MarioKnight commented Dec 22, 2016

@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.

@jaswrks

This comment has been minimized.

Member

jaswrks commented Dec 22, 2016

@MarioKnight Thank you very much for that feedback.

@raamdev So it looks like in this case, the problem is this check is getting bypassed.

@raamdev raamdev modified the milestones: Next Release, Maintenance Release Dec 22, 2016

@raamdev

This comment has been minimized.

Contributor

raamdev commented Dec 22, 2016

@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 WP_DEBUG was set to true, issues that we determined were a problem with IWP failing whenever output happened to contain something like a PHP Notice as the result of WP_DEBUG being enabled; see #394 (comment). I'm wondering if we're seeing something similar here?

@MarioKnight Can you confirm that WP_DEBUG is enabled on the sites where you had this issue? And if so, were you logging errors to a log file or displaying them? See also: https://codex.wordpress.org/Debugging_in_WordPress

@raamdev

This comment has been minimized.

Contributor

raamdev commented Dec 22, 2016

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.

@MarioKnight

This comment has been minimized.

MarioKnight commented Dec 23, 2016

@raamdev It appears that none of them had WP_DEBUG enabled, so unfortunately there are no additional logs to help.

jaswrks pushed a commit to websharks/comet-cache-pro that referenced this issue Dec 23, 2016

jaswsinc
- **Bug Fix:** Resolves error `Unable to determine UA info directory …
…location` when upgrading to latest release. See [Issue #862](websharks/comet-cache#862).

- **Bug Fix:** Enhancing compatibility with InfiniteWP, ManageWP, and other remote management tools for WordPress. See [Issue #862](websharks/comet-cache#862).
- **Cleanup:** Removed an old API call that checked for a newer lite version. No longer necessary.

@raamdev raamdev removed the needs testing label Dec 23, 2016

raamdev added a commit that referenced this issue Dec 23, 2016

Phing release of v161223-RC with the following changes:
- **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.
@renzms

This comment has been minimized.

renzms commented Dec 25, 2016

Fix Confirmed Working, see comments here

raamdev added a commit that referenced this issue Dec 26, 2016

Phing release of v161226 with the following changes:
_**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.
@raamdev

This comment has been minimized.

Contributor

raamdev commented Dec 26, 2016

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).

@raamdev raamdev closed this Dec 26, 2016

@websharks websharks locked and limited conversation to collaborators Dec 26, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.