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

[diazwatson]

After upgrade to Grav v1.1.5 and Admin v1.2.2 using command line everything seemed to be ok.
Once I push this changes the deployed to production this nasty message.

Class 'Grav\Plugin\Email\Email' not found
user/­plugins/­email/­email.php:35

Is this happening to anybody else?

[w00fz]

Have you tried clearing cache?

[diazwatson]

yeap

php -f bin/grav clear-cache

that was done

[w00fz]

Could you try reinstalling the email plugin manually? Although I can't see why this would be relevant, I've seen some people on Gitter mentioning this helped them solving some email issues.
Curious if this would be the case for you as well.

[diazwatson]

Done
The Email Class message is gone
But another one comes up :(

Call to undefined method Grav\Common\Session::getFlashObject()
…/­user/­plugins/­form/­form.php:213

[w00fz]

Ok I don't think your update went smoothly for some reason. Reinstall form and login plugin like you did with email.
That should helpfully fix the problem.

[diazwatson]

I am sorry to say that
Class 'Grav\Plugin\Email\Email' not found
message is back

I am going to restore everything back to how it was and try to reproduce the issue in my local to debug it over the week.

Many thanks for your help :)

[rhukster]

Call to undefined method Grav\Common\Session::getFlashObject()
…/­user/­plugins/­form/­form.php:213

This one means your Grav instance is out of date.

[diazwatson]

@rhukster indeed, I needed to clear cache but now the

Class 'Grav\Plugin\Email\Email' not found
user/­plugins/­email/­email.php:35

message remains, no matter if I install email plugin manually and/or clear cache

[rhukster]

Which version of Email and Forms plugin do you have?? Are they both up to date?

Forms latest is 2.0.5
Email latest is 2.5.0
Login latest is 2.1.1
Admin latest is 1.2.2

You should be able to find out what's out of date by simply typing:

bin/gpm update

[diazwatson]

bin/gpm update
GPM Releases Configuration: Stable
Nothing to update.

bin/gpm info email

GPM Releases Configuration: Stable
Found package 'email' under the 'Plugins' section
Email [email]
-------------
Enables the emailing system for Grav

Author      : Team Grav <[email protected]> <http://getgrav.org>
Version     : 2.5.0
Keywords    : plugin, email, sender
Last Update : Tue, 16 Sep 2014, 02:07:16, +02:00
Homepage    : https://github.com/getgrav/grav-plugin-email
Repository  : https://github.com/getgrav/grav-plugin-email
Bugs        : https://github.com/getgrav/grav-plugin-email/issues
Download    : https://github.com/getgrav/grav-plugin-email/zipball/2.5.0
License     : MIT

php bin/gpm info form

GPM Releases Configuration: Stable
Found package 'form' under the 'Plugins' section
Form [form]
-----------
Enables the forms handling

Author      : Team Grav <[email protected]> <http://getgrav.org>
Version     : 2.0.5
Keywords    : plugin, form
Last Update : Tue, 16 Sep 2014, 02:07:16, +02:00
Homepage    : https://github.com/getgrav/grav-plugin-form
Repository  : https://github.com/getgrav/grav-plugin-form
Bugs        : https://github.com/getgrav/grav-plugin-form/issues
Download    : https://github.com/getgrav/grav-plugin-form/zipball/2.0.5
License     : MIT

bin/gpm self-upgrade
GPM Releases Configuration: Stable
You are already running the latest version of Grav (v1.1.5) released on Sat Sep 10 00:29:44 2016

[w00fz]

You can just use this btw, faster and more to the point:

bin/gpm index -I -F admin -F login -F email -F form

[diazwatson]

Nice!, did not know thanks! :)

[w00fz]

Your versions look good, although you haven't posted about login and admin.
However, all the errors you are getting are clear indication that you have older versions, which is why we are so fixated with version of your plugins and all about updating.

Is your server perhaps running some system cache? That would explain why it looks like old versions but then sometimes it works.
Have you tried copying the site to a different server (or area of the same server) to see if the error continues?

[diazwatson]

Hi @w00fz
Thank for the support guys!

I'm still looking in my free time for what can cause this issue.
I will post anything as soon as I discover it :)

Thanks again

[rhukster]

I'll leave this open with a note about more info, as we really appears to be a PHP level caching of files beyond the norm. I suspect it's something installed on your hosting provider that is doing this.

[smz]

I suspect it's something installed on your hosting provider that is doing this.

In other contexts I had very similar issues when using Plesk as my hosting solution. If this is your case too, try disabling Plesk's "Smart static files processing" (in your subscription's "Apache & nginx settings").

[diazwatson]

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.

[w00fz]

That cache set to be shared between released sounds like could be a problem. Could you try disabling that, at least for testing if that's the culprit?

Definitely sounds like a problem with the way it gets deployed though.

[diazwatson]

I have unlinked the cache folder, deleted it, recreated it via php bin/grav clear-cache and still the same

[w00fz]

Ok this is a long shot but could you try clearing all the cache and then touching all the files on the server to see if that helps?

$ cd /where/your/root/grav/is
$ find . -exec touch {} \;

[diazwatson]

Same :(

[diazwatson]

At the same time, if I do

php ./bin/gpm index -I -F email

I get

GPM Releases Configuration: Stable

PLUGINS [ 1 ]
------------------------------------------------
| Count | Name   | Slug  | Version | Installed |
================================================
| 1     | Email  | email | v2.5.0  | installed |
------------------------------------------------

[pageworthy]

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.

[diazwatson]

That is exactly what is happening to me.

[diazwatson]

I think that the issue comes from .gitignore files.

[flaviocopes]

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.

[flaviocopes]

Fix included in https://github.com/getgrav/grav/commit/70a38d1d3a0e38674bb85226d633dcc9ee52a4f6

[diazwatson]

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.

[diazwatson]

It breaks again after deploy and with the same plugin.
how come? :'(

[rhukster]

This was fixed quite some time ago. The only explanation I have is that you are somehow still running with out of date plugins?

[saxinte]

I'm having the same issue - works in dev, not in prod.

[aalyokhin]

Absolutely the same issue for me. After deployment to production this error has appeared, on local server it works perfectly. All plugins and Grav are up to date.

[rhukster]

Are you all pushing to production via Git? I think the .gitignore is ignoring the vendor folder that is contained in the email plugin. Can you check if you have a user/plugins/email/vendor/autoload.php file??

[rhukster]

https://github.com/getgrav/grav/commit/70a38d1d3a0e38674bb85226d633dcc9ee52a4f6

Contains a fix to the default .gitignore of Grav to not ignore vendors libs other than Grav's root one.

[aalyokhin]

As for me, this file is in place. Was pushing to production via FTP.

[saxinte]

@rhukster Yes. We are working in team with different staging environments and made the choice to have dev === prod. Vendors are pushed as well and not inside .gitignore.
So we don't have a single installation per environment, they are all the same. Because of that we avoid issues to have different versions/installations on dev and staging.

We use mac apache in dev. Then we push to git, and use Capistrano that will create a new instance of the git hash commit with an empty folder with the entire Grav repo. We don't perform any install, just push.

It was working fine since this issue. :) Thanks to the Grav team, you all do a really good job, we enjoy the product.

[flaviocopes]

@aalyokhin @saxinte @diazwatson can you check the user/plugins/email/vendor folder exists on the broken site and contains the actual vendor folders https://github.com/getgrav/grav-plugin-email/tree/develop/vendor?

[aalyokhin]

@flaviocopes Unfortunately the answer is yes, everything is in place, screenshot http://take.ms/PNZm8. May the cause of an issue be related to some incorrect rights?

[flaviocopes]

@aalyokhin check under user/plugins/email/classes. Is there a lowercase email.php file? In addition to Email.php? If this is the case, remove the lowercase file and check again.

[saxinte]

@flaviocopes yes everything is here. I tried to reinstall the Email plugin via the gpm command on the server and it's working. But we can't rely on this solution as we have multiple staging envs.

[saxinte]

@flaviocopes

root@homepage-dev:/srv/homepage/current/grav/user/plugins/email/classes# ls
email.php  Utils.php

:/

[rhukster]

It should be Email.php. I think your sync is causing the issue and not picking up the change in capitalization. If you remove and reinstall the plugin it should only have the Email.php version.

[rhukster]

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

[aalyokhin]

@rhukster Thanks so much, Andy! There was only email.php file in classes folder, and no Email.php one. I have deleted it, put Email.php there and problem solved. Thanks again.

[pageworthy]

The .gitignore fix above fixed this issue for me. Thanks for all the great work on Grav!

[flaviocopes]

The problem originates from the fact we renamed email.php to Email.php - depending on the filesystem, it could not recognize a change in the name, OR Email.php will be added alongside email.php, and Composer could pick up the lowercase version by mistake.

If the issue is only on the remote server synced, then it could be some problem introduced by the sync procedure, not recognizing the file name change for some reason.

[saxinte]

@flaviocopes I've renamed email.php to Email.php and it's working.

But you said I can't rename it. I tried to use the version you provided https://github.com/getgrav/grav-plugin-email/blob/develop/classes/Email.php but when I'm using it, I have this error: Fatal error: Uncaught RuntimeException: Plugin 'email' class not found! Try reinstalling this plugin.

I guess I can just use the renamed version? Thanks

[flaviocopes]

Are you sure you have the latest version of the email plugin?

[saxinte]

I have 2.5.0 but I just seen that you release 2.5.1 and Grav 1.1.6. Is it related?

[flaviocopes]

2.5.1 should help solve the problem.

[saxinte]

@flaviocopes Unfortunately no, I just updated the entire Grav app, Grav core to 1.1.6 and all the plugins, including Email 2.5.1. The error is lightly different now but it's still the same issue:

E_WARNING - include(/srv/homepage/releases/20161020140553/grav/user/plugins/email/vendor/composer/../../classes/Email.php): failed to open stream: No such file or directory

I've deployed again after a simple file rename (email.php to Email.php) and it's working.

Thanks

[flaviocopes]

@saxinte did you already try previously removing the Email plugin and installing it again?

[rhukster]

If you uninstalled the email plugin on your remote server, and then reinstalled. You wouldn't have email.php only Email.php. That lower case even in the plugin anymore. I think your problems stem from simply copying over the plugin on your remote server, which is why you still have lowercase email.php there, which is the cause of the problem.

[saxinte]

@flaviocopes Yes, I tried in local to bin/gpm uninstall email and bin/gpm install email and I still have the lowercase email.php. If I run this on the server, it fixes the problem as well.

But we shouldn't run this on the server. I mean even if I know now how to fix this issue, a new bin/gpm install email should install the plugin with the right version of Email.php, this will fix both issues, local and server side.

Thanks

[drgomesp]

I'm also having this issue, even after trying all possible solutions discussed on this thread. Any ideas?

[rhukster]

It's related to an old version of the plugin contaminating your plugin folder with an upper and lower case version of the class. Quick fix is to just delete the user/plugins/email folder and reinstall email plugin via GPM.

[phivk]

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

[jlehtinen]

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.

[mahagr]

@jlehtinen Thank you for pointing out the cause of this issue. The reason why this issue happens is likely related to the renaming of classes/form.php file into classes/Form.php which is required by PSR-4.

I'm not sure why this should cause any issues in non-case-sensitive filesystems as plugin installation should replace the existing folder, not copy the files over.

@rhukster FYI

[jlehtinen]

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 😄