PHP Fatal error: Class ‘Ramsey\Uuid\Uuid’ not found

Hey, I’ve had report of this same error on GitHub https://github.com/joppuyo/acf-image-aspect-ratio-crop/issues/19 but I’m still trying to figure out what is causing this. My current hypothesis is that this issue might have existed for some users before this but it was not prominent because the code path that uses Composer dependencies was rarely used and now it’s used on all page loads. I’m planning on releasing a hot fix today use a built-in WordPress function for generating unique id’s instead of Composer library.

Could you tell me a few things to help me debug this issue?

* How did you install/update this plugin? WordPress plugins page / www.remarpro.com plugin zip / Composer / GitHub releases zip
* Do you use Composer in your WordPress theme
* Have you installed WordPress using Composer
* How do you deploy WordPress
* Does file wp-content/plugins/acf-image-aspect-ratio-crop/vendor/autoload.php exist on your server

Thank you and apologies for having to deal with this issue.

One more question: what environment is this happening in? what web hosting provider do you use?

Hi @joppuyo,

I will try to answer all your questions:

* How did you install/update this plugin? WordPress plugins page / www.remarpro.com plugin zip / Composer / GitHub releases zip
WordPress plugins page

* Do you use Composer in your WordPress theme
no

* Have you installed WordPress using Composer
no

* How do you deploy WordPress
we are deploying self developed plugins and the theme with rsync via GitLab CI but your plugin has been manually installed. Updates of third party plugins like yours are being remotely triggered by iThemes Sync.

* Does file wp-content/plugins/acf-image-aspect-ratio-crop/vendor/autoload.php exist on your server
yes

* One more question: what environment is this happening in? what web hosting provider do you use?

The problem occurs on a managed server by all-inkl, a german hosting company.
Can’t reproduce the problem on my local MAMP Pro environment with a similar setup.

Also can’t reproduce the problem on another installation which is running on a domainfactory shared hosting (with completely different mix of plugins and theme).

Hi @joppuyo. I’m also encountering the same error. It doesn’t display when I’m in the admin, but any page or post gets the fatal error.

1) Installed via wpackagist and composer.
2) WordPress is installed via an ansible playbook.
3) WordPress is deployed via CircleCI
4) autoload.php does exist
5) Site is self hosted on AWS

Good luck on your bug hunt. Looking forward to using this plugin again ??

Hey, I have released new version v3.1.11 which uses native wp_generate_uuid4() function instead of the ramsey/uuid composer library. I don’t know why I used a composer library for this in the first place, maybe out of habit?

Could everyone please test that the plugin is now working properly?

I have tried to debug this issue with little luck since it seems like it could be caused with a particular combination of PHP, composer and hosting environment and I have yet to determine what that combination is.

I will have to debug this later but now the most important thing is to release a version that doesn’t cause breakage for sites.

I’m really sorry for all the trouble this issue has caused by breaking people’s sites. Last 48 hours have been super stressful for me first because first I changed the deployment of the plugin from Travis to GitHub actions and due to an issue with the 10up/action-wordpress-plugin-deploy action, a broken version of the plugin was deployed into the www.remarpro.com repository.

After I fixed this, reports started coming in about this other issue Composer and ramsay/uuid dependency.

So please test out the latest v3.1.11 version and I will do my best that more of these issues will happen from now on.

Thank you!

• This reply was modified 5 years ago by joppuyo.

@joppuyo Thank you for the quick fix! Nothing seems to be breaking as far as I can tell. If I find anything I’ll let you know ASAP.

@joppuyo thanks a lot for fixing the problem so quickly! It seems like the new version is free of the bug and everything is looking good right now.

Don’t worry about any trouble this bug might have caused – it’s a free plugin and I really appreciate the great work you put into that.
I guess every sane developer will agree that it’s a great idea to test any update on a staging environment before rolling it out to production.

Never mind! Have a great day