October: Randomly Getting Class Not Found Error After Updating

[abass]

I seem to always run into an error similar to this below after updating on the backend. It seems to happen randomly when adding a plugin or updating the build, etc. It never gives me problems on localhost no matter what I do so maybe it has to do with storage permissions?

Class 'Cms54ae080da267a_2516035414Class' not found
/app/themes/themename/layouts/default.htm line 157

The Stack Trace is always

Illuminate\Exception\Handler->handleShutdown()

I have no idea how to figure it out because the error code it gives is not very useful. Whenever it happens it's always the same error though the numbers and letters after Class 'Cms change.

Here's an image of the error, maybe it will help.

Any ideas will be greatly appreciated because I simply just can't figure it out.

[SASniper]

Hey there,

I too ran into this error, occurring whenever I would update a template then try to view the change etc. It was doing my head in as it only occurred on the production server and not my localhost development.

For me, disabling the PHP plugins APC and Memcache in favor of xcache resolved the issue. Maybe this will help you?

[abass]

Hi @SASniper,

Really appreciate the suggestion. I am not at all familiar with either of these plugins nor can I find them on the site. If you don't mind me asking, what is the process to do the above suggestion?

Thanks!

[SASniper]

Hey @flip4bytes

They are not part of OctoberCMS but rather for PHP itself. The correct term is extension, not plugin so sorry for any confusion!

I guess the first step here is to find out if you have APC enabled, you can do this by creating a PHP file on your website with <?php phpinfo(); ?> inside and then viewing that. Now if APC is listed you can then test by commenting out the line within the PHP.ini file similar to: extension=apc.so, effectively disabling the extension and then restarting apache for the config to take effect.

Depending on the access you have to your hosting you may or may not be able to change this. I have full SSH access so have no problems configuring to my hearts content. If your using a shared host environment or are not sure, you'll probably not have access to this level of config.

[abass]

@SASniper

Interesting. I have recently switched over to Heroku and absolutely loving it. My other sites are also on Heroku but running on just vanilla Laravel and I have never encountered errors like these.

Restarting the dyno actually seemed to fix the bug when it comes up oddly enough. Though the error comes up whenever I make certain changes to the site using the backend though. For example I just changed one line of code (like just html code within my CMS>Pages) through the CMS backend and upon saving it, the site gets that error message until I restart the dyno (if you aren't familiar with heroku, restarting the dyno is just like restarting the computer that the site is being hosted on).

I'm still fairly new with Heroku and it's all command line so I'm going to have to dig a bit to see if extension=apc.so is commented out or not in the PHP.ini file on Heroku.

Appreciate the responses, it sure seems like it's a cache/storage thing on the server that's causing all of this to happen. That would be a problem with the framework and not really the hosting though, right? I mean Heroku for example is a HUGE option being used for web apps now-a-days. It's not just some junk shared hosting service like hostgator or something. I'd assume it would be optimized for PHP apps properly?

Cheers!

[abass]

I have been able to figure out what the problem is and it really needs to be fixed.

This error is happening on local and production for me which makes it nearly unusable. It is definitely a caching problem the more I look into it when it happens.

The error happens when the cache in the storage directory tries to create a file that is already there. For example, it was trying to create the directories 50/35 with the file 5035b0c1e1f82379067d38f8383c7b5d inside. The only way to get rid of the error and allow for the cache to write was by deleting the already exising file in that directory. It simply wouldn't force an overwrite and just crashes the site instead.

Now deleting the entire contents of the storage/cache directory whenever this error comes up is possible, though it's quite annoying as it happens multiple times throughout development. Even worse, on a production server, you must force a server restart to clear that cache directory. This means the client can hop on to the backend of their site and make a simple change which would result in the site crashing and requiring a server restart to clear the cache and fix it.

I have never encountered storage caching problems with Laravel on either local or production so is OctoberCMS using storage cache differently @daftspunk ? If so, could this be remedied in any way?

[SaifurRahmanMohsin]

+1
Update solved it but I still don't understand why I got this error. It was stable when I last left it but suddenly it stopped working. Weird!

Update: The issue persists. The reason update solved it is because the cache cleared when I updated the cms. It probably made a call to Cache::flush();

Anyway, a quick fix for this would be to add php artisan cache:clear to your cron job

[abass]

@SaifurRahmanMohsin I'll look into the quick fix for the short-term and see if I can temporarily stop this from happening. Will it clear:cache everytime a change is made on the /backend of the site though? or only when files are pushed to the server? Also curious, are you too using Heroku/AWS for hosting aswell?

@daftspunk is caching done differently with Laravel 5 so this critical bug could be fixed? It's a pretty big deal because I currently can't allow clients to make any changes to the site on their own from the online /backend. Even basic content changes cause the site to randomly get this caching error and completely stop working. I have to immediately restart the Heroku hosting dyno for the app in order to clear the cache and remove the error.

I mean is it really really necessary to bring the site to it's knees when a caching issue happens, or do you have no control over that?

I have about 3 client projects coming up this month and I am planning on using OctoberCMS but can't if this isn't fixed because my client's won't be able to make changes to the site without it blowing up.

Thanks so much!

[SaifurRahmanMohsin]

I use OctoberCMS mostly on AWS and GoDaddy shared hosting. I did run it on Heroku this week and it worked perfectly fine. Took me hardly 10 minutes to get it up and running.

As for the caching issue, the cron job does a wonderful task. I've set it to run every hour and added all my October sites to a single .sh script as

echo Clearing XYZ project cache
php /october/site1/artisan cache:clear > /dev/null
echo Clearing my blog cache
php /october/site2/artisan cache:clear > /dev/null
echo Cleanup complete... Exiting!
date > lastrun.txt

I think you could also do a Cache::flush() on the layout's onEnd but I wouldn't recommend it as it might slow down the website. Besides, I haven't really tried that and it's entirely theoretical that it will solve the caching problem. It might cause a performance problem thou, which is rather a problem on it's own. Do let me know if you try it and it works.

[daftspunk]

Fixed in e487f075c4ec8ea6121af9414ec666fe30eea314 (Build 210)

[abass]

Ahh yes!! Thank you so much @daftspunk couldn't have asked for a better birthday present! This caching issue was the only thing keeping me from using it on client projects moving forward. Can't wait to finally give OctoberCMS a run for it's money in places other than just personal projects now. Thank you so much!!

[SaifurRahmanMohsin]

Excellent. Can get rid of my cron jobs. Great work

[khoatran]

Hi,
Actually, I've faced to the same problem. However, I found another solution.
Firstly, let's analyse the root cause.

In my case, this issue happens on a server which I installed opcache and use its default setting. By using opcache, the PHP code is stored in its optcode caching. So, if any PHP code changes - I need to restart the php-fpm (as I use apache integrated to php-fpm) to make the opcache build with the latest code.

OctoberCMS generates some dynamic classes every time we add new pages or when you click to the clear cache button in the dashboard. So, every time these generated classes created and opcache are not updated, it will cause the issue.

To fix this issue, I suggest you read carefully this article: https://www.scalingphpbook.com/blog/2014/02/14/best-zend-opcache-settings.html

The default settings of opcache set validate_timestamps = 0, so you need to do manual cache reset by resetting apache/ php-fpm. However, if you switch this setting to 1 and set the right revalidate_freq - you will get the opcache build with the latest code => this issue is disappeared :)

I hope this really helps

[daftspunk]

Thanks @khoatran! #2385 has been created to address this.

[ab192130]

This issue remains in my current build (382:latest).

Class 'Cms585bebafb81d1822363345_466380942Class' not found
/app/themes/rainlab-vanilla/layouts/default.htm line 180

Stack trace:

`#47 - Cms\Classes\CodeParser->source(…) -
~/modules/cms/classes/Controller.php - 532`

[jmondragon]

I was also getting this on the latest release when deploying to dokku. I created a .user.ini file with the opcache settings from the link provided by @khoatran and it fixed this. For reference here is my .user.ini:

opcache.revalidate_freq=0
opcache.validate_timestamps=0
opcache.max_accelerated_files=7963
opcache.memory_consumption=192
opcache.interned_strings_buffer=16
opcache.fast_shutdown=1

[Eoler]

There's another mitigation for OpCache thrashing - by blacklisting Twig/CMS cached files:

php.ini

opcache.blacklist_filename = <path_to_php_ini_folder>opcache-blacklist.ini

opcache-blacklist.ini

; OctoberCMS production caches
/home/**/storage/cms/**/*.php

[daftspunk]

This should be sorted internally now as part of 22bc5fce68224733f39b24651fc3ac64dedffbc5

Available in Build 393+