Updating via IWP temporarily broke sites

[MarioKnight]

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]

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

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

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

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

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

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

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

@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 https://github.com/websharks/comet-cache/issues/394#issuecomment-245799322. 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]

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]

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

[renzms]

Fix Confirmed Working, see comments here

[raamdev]

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