Issue Deploying Updated Plugins Due to Acorn Cache

acorn
,
1

Hey team,

I have 3-year-old site that I am updating some premium plugins on. The site is using Trellis, Bedrock, and Sage 10, which have not been upgraded since the site was launched due to budget constraints. As such, Acorn 2 is being used.

When I attempt to deploy to my staging site after updating one of the plugins, which are not managed via composer since they are premium plugins that don’t provide a path for doing so, wp acorn optimize fails because a Class(es) that was removed in the updated version of the plugin cannot be found.

TASK [deploy : Run Acorn optimize] *********************************************
System info:
  Ansible 2.10.16; Darwin
  Trellis version (per changelog): "Create mysql my.cnf credentials file earlier"
---------------------------------------------------
non-zero return code
Fatal error: Uncaught Error: Class
"ElementorPro\Core\Compatibility\Compatibility" not found in ...

I imagine it could be related to this issue, which was apparently resolved on newer versions of Acorn: Removing a provider breaks Acorn until removing the packages cache · Issue #270 · roots/acorn · GitHub

I attempted upgrading Acorn straight to 4.0, which ran into a bucket of issues. I then tried upgrading to 3.0, which caused what seemed to be a PHP version issue like this thread (Same error, except for roots/sage instead of roots/bedrock): https://discourse.roots.io/t/composer-could-not-detect-the-root-package-roots-bedrock-version/26895

That struck me as odd given that I am running PHP 8.1, so maybe I’m missing something there.

Obviously I am down the rabbit hole here and getting a bit lost. Again, I am working with a tight budget, so upgrading the full stack is not really an option right now (hopefully it will be possible in the future). So, I’m looking for a workaround for now, or even just an explanation of how and why the Acorn cache might be causing this issue in order to point me in the right direction.

Any help would be greatly appreciated!

Edit: I also tried removing the cache manually before deploying to no success.

2

Any chance of getting some insights here? I haven’t been able to figure this one out, so I’ve put it on the back-burner. I know the “right” answer is to upgrade Acorn and the stack, but again, I’m working with a fairly complex site infrastructure on a tight budget.

3

Judging by the CLI error, it doesn’t really appear to be related to Acorn. Perhaps some manual call to Elementor Pro somewhere? Did you previously install it with Composer and now you no longer do? I don’t think it’d be related to the Provider issue linked. Elementor doesn’t have a Provider.

1 Like
4

Agreed, doing a basic Google of that error, a bunch of other sites show the exame same error. Unless they by chance were running roots and acorn etc then it shows others are having that generic error too. Plugin specific.

You cleared the acorn cache though too right? wp acorn optimize:clear

image
image1041×931 98.4 KB

1 Like
5

Hey @Log1x and @JordanC26! Thanks for the replies. The issue occurred with two or three plugins that had not previously been installed via Composer, which is why I thought this was related to the Acorn cache. it just so happens Elementor Pro is the only one of those plugins I still need in this case, so I removed the others and didn’t dig any deeper with those ones. I remember that the error output was the same, though. It could be a coincidence, but you can see why I would have seen an outdated Acorn as the common denominator. :slight_smile:

Based on your comments, however, I tracked down a compatibility check in a different plugin (WooCommerce Product Bundles), which I commented out and thereafter successfully deployed on my staging site. I then uncommented the compatibility check and deployed again successfully, so it seems like the issue is resolved.

I’m adding the caveat that I hadn’t tried deploying in two months with the same conditions in which I encountered the error, so I can’t say whether it resolved itself independently of the temporary plugin adjustment I made. I do find it odd that the compatibility check works fine on the second deployment. I’ll run some further tests later to see if it was indeed the compatibility check that was causing the issue initially, but the roadblock has been removed. Thanks, guys!

1 Like