grav: Class 'Grav\Plugin\Email\Email' not found

I think the error only happens when pushing to GitHub (or BitBucket, as I’ve experienced).

The default Mac filesystem is case preserving, but not case sensitive, as in form.php is considered to be the same file as Form.php. So, things work fine locally after plugin updates and all filenames are correct on the hard drive, but as Git is looking for changes to push to the online repository, the filename change form.php to Form.php doesn’t get registered. End result is that everything else on GitHub is up to date — apart from any case changes in otherwise unchanged filenames.

In other words, you couldn’t really call it a Grav issue per se, unless the devs develop a particular fondness for routinely switching filename case 😄

[Edit]: I tried creating a case sensitive volume, and can confirm that solves the issue.

I came across this issue after facing a similar situation related to the Form plugin. Like others have reported here, this happened on production after updating plugins locally on my development computer.

Whoops \ Exception \ ErrorException (E_ERROR)
Class 'Grav\Plugin\Form\Form' not found

Resolved it by uninstalling and reinstalling the Form plugin on the production server:

bin/gpm uninstall Form
bin/gpm install Form

This seems to happen at least on Mac and on non-case-sensitive volumes. On the new APFS volumes (for SSD drives) it’s really easy to create a new case-sensitive volume on the same drive, which will take up the space it needs but without claiming any space when creating (you can optionally set a minimum size & maximum quota, however), and place your local repositories there to avoid case issues.

btw, you can’t just rename it, there’s a change in namespace, see here: https://github.com/getgrav/grav-plugin-email/blob/develop/classes/Email.php

Yes, as @flaviocopes explains, this seems to be the issue. I have also applied this change in my project and deployed as usual and now everything seems to work just fine.

I am going to carry on testing and report anything I found.

It would be nice to know if this also works for @pageworthy issue.

That could simply be a .gitignore issue, as @diazwatson mentions in the last comment, as .gitignore ignores the vendor folder in the root, which ignores the core vendor folder, but as a side effect also ignores all the vendor folders contained in any subfolder.

I’ve seen this multiple times, we need to get a fix in the core.

vendor/*
!*/vendor/*

should do it, by ignoring the vendor/ folder content, but including any vendor folder contained under user/ or anywhere else.

I’ve just been hit by the same thing. Hosting on AWS. In the end I had to update on production and commit from there. When I pulled the updates to my local dev it worked great. But when I update on local first and then deploy to production it breaks. Using MAMP locally. Updating locally (and deploying) has worked for me on the past couple of updates.

Actually there is no Plesk, Cpanel or panel at all. It is a virtual host with ubuntu, php, nginx.

I use Capistrano as a deployment tool and have configured cache and logs folder to be shared between releases.

As mentioned before, if I upgrade from admin or tool it works perfectly. But if I do the same in my local, then push the changes to the repo and finally deploy them to the server it shows the error.

I have compared deployed files in server with the ones in my local and there are no changes.

Also if I check the version of grav and plugin in the server using cli tool the show to be up to date.