Cms: Class 'craft\behaviors\ContentBehavior' not found in runtime/compiled_classes/ElementQueryBehavior.php:96

[proposifymax]

Description

The following error shows up in the craft web.log

yii\base\ErrorException: Class 'craft\behaviors\ContentBehavior' not found in /efs/runtime/compiled_classes/ElementQueryBehavior.php:96

which coincides with a 500 error being logged in the apache access_log. It happens randomly on both the /admin backend as well as random site pages. It is not a permanent situation as the same request (GET or POST) to the previously 500ed URL will usually perform as expected on retry. However it is not always fine on retry. Just last night the entire site stayed down. New Relic shows > 4000 instances of this error in a 3 hour timeframe (at which point the site stayed down completely). Deleting the runtime/compiled_classes folder did bring the site back up but we're still seeing this error ~ 1-2 x / minute.

Steps to reproduce

1. Unknown. Random requests, either GET or POST by various devices. user-agents, or cURLs, retrying the request tends to serve the requested resource correctly.

Additional info

• Craft version: 3.0.31
• PHP version: 7.1.23
• Database driver & version: MySQL 5.6.40
• Plugins & versions:
  -- Amazon S3 | 1.0.8
  -- AsyncQueue | 1.3.3
  -- New Relic | 3.0.3
  -- Redactor | 2.1.6
  -- SEOmatic | 3.1.30

[proposifymax]

phperrors.log

This is actually flooding the craft generated phperrors.log now

[brandonkelly]

Guessing you’re running Craft in a load-balanced environment? Try SSHing into each of the boxes and check storage/runtime/compiled_classes, and see if one of them is missing a ContentBehavior.php file, or has one but with different permissions than ElementQueryBehavior.php.

[timeverts]

I just had this issue too after a recent deployment, and yes, on a load balanced environment.

While the site was in an error state, the permissions of the files across both servers were like this:

-rw-r--r--  1 www-data myuser  24K Jul  5 08:02 ContentBehavior.php
-rw-r--r--  1 www-data myuser  13K Jul  5 08:02 ElementQueryBehavior.php

I couldn't for the life of me work out what was wrong, so in the end i just deleted the files manually and had Craft regenerate them. And that fixed the problem.

Upon regenerating, the only difference was that the group changed from myuser to www-data:

-rw-r--r--  1 www-data www-data  24K Jul  5 08:03 ContentBehavior.php
-rw-r--r--  1 www-data www-data  13K Jul  5 08:03 ElementQueryBehavior.php

So thinking this was the problem, I changed the group back again to myuser but this time the site still worked! So surely that couldn't have been the problem.

So I'm really not sure what the issue was!

[timeverts]

I should add that during our deployment the permissions of storage are changed using chown -R www-data:myuser. Don't know whether that might be affecting things.

[angrybrad]

@timeverts maybe some weird OpCache settings coming into play? Is that extension enabled on the servers?

[jeffaglenn]

Glad I found this. Just ran into the same issue. The site has been working great for months then got:

2019-07-24 12:44:11 [-][-][-][error][Error] Error: Class 'craft\behaviors\ContentBehavior' not found in /home/xxxxx/webapps/xxxxx/storage/runtime/compiled_classes/ElementQueryBehavior.php:116

Both ContentBehavior.php & ElementQueryBehavior.php were present with the correct permissions. Took the advise above and manually deleted the files and had Craft recreate them. All seems to be working fine. Didn't notice any difference in ownership/permissions in the created files vs deleted files

Versions

• Craft version: 3.1.32.1
• PHP version: 7.3.4
• Database driver & version: MySQL 5.5.5

[proposifymax]

It is definitely a tricky proposition to run craft in a load-balanced environment, besides the above issue there are other considerations like craft sessions that need to be stored correctly. Any issues with these things will cause craft to malfunction.
That being said we ended up using network attached storage attached to all load balanced instances of the same environment. The craft storage folder is placed on this external storage and symlinked. This makes sure that whatever node is hit relevant craft information can be accessed correctly and errors like the above one can be avoided.

Full disclosure, we also added a memcached instance for craft that is used for things like the admin panel sessions, etc. by craft.

[jeffaglenn]

For got to mention, I'm not running a load-balanced environment.

[timeverts]

@angrybrad , just answering your query. Yes, OpCache is installed on the server. Here are the settings from php.ini:

opcache.blacklist_filename => no value => no value
opcache.consistency_checks => 0 => 0
opcache.dups_fix => Off => Off
opcache.enable => On => On
opcache.enable_cli => Off => Off
opcache.enable_file_override => Off => Off
opcache.error_log => no value => no value
opcache.fast_shutdown => 0 => 0
opcache.file_cache => no value => no value
opcache.file_cache_consistency_checks => 1 => 1
opcache.file_cache_only => 0 => 0
opcache.file_update_protection => 2 => 2
opcache.force_restart_timeout => 180 => 180
opcache.huge_code_pages => Off => Off
opcache.inherited_hack => On => On
opcache.interned_strings_buffer => 8 => 8
opcache.lockfile_path => /tmp => /tmp
opcache.log_verbosity_level => 1 => 1
opcache.max_accelerated_files => 10000 => 10000
opcache.max_file_size => 0 => 0
opcache.max_wasted_percentage => 5 => 5
opcache.memory_consumption => 128 => 128
opcache.opt_debug_level => 0 => 0
opcache.optimization_level => 0x7FFFBFFF => 0x7FFFBFFF
opcache.preferred_memory_model => no value => no value
opcache.protect_memory => 0 => 0
opcache.restrict_api => no value => no value
opcache.revalidate_freq => 2 => 2
opcache.revalidate_path => Off => Off
opcache.save_comments => 1 => 1
opcache.use_cwd => On => On
opcache.validate_permission => Off => Off
opcache.validate_root => Off => Off
opcache.validate_timestamps => On => On

We've done a few deployments since and haven't hit this issue again, but will continue to monitor the situtation.

[angrybrad]

@timeverts would be curious if you run into it again if disabling opcache resovles it.

[mtwalsh]

Just hit this issue after sharing the storage folder across two load-balanced instances via EFS. Deleting the storage/runtime/compiled_classes folder resolved it. The permissions on the files were correct so I'm not sure why it was causing the error:

Class 'craft\behaviors\ContentBehavior' not found

After the files were regenerated (ContentBehaviour.php and ElementQueryBehaviour.php) by Craft, which resolved the issue, I couldn't spot any changes in terms of permissions or even file size.

[jeffaglenn]

This just happened to me again. Same site, no load-balanced environment. Very strange. I diffed the files from when the site was down and what Craft automatically generated and they were the same. Permissions haven't changed either. Regenerating the files fixes everything though.

[brandonkelly]

@jeffaglenn Did you check if the file owner changed?

[jeffaglenn]

Unfortunately I didn't. I'll make a note and if it happens again I will check.

[rtrudel]

Got this problem twice this week. I simply deleted the files and it get back running.

storage/runtime/compiled_classes/ElementQueryBehavior.php
storage/runtime/compiled_classes/ContentBehavior.php

Why this happens, and how to permanently fix this issue for the future?

[angrybrad]

Re-opening this, but I'm not sure I've got any new ideas. Is everyone that is running into this putting the storage folder on an EFS mount?

[rtrudel]

My storage folder is local on my cPanel.

Idea: is it possible to trigger something on this error, such as regenerating files on the fly?

[brandonkelly]

The files do get regenerated on the fly whenever they don’t exist or are invalidated due to a field getting saved.

[rtrudel]

Ok. Strange then. The files were there but the "class not found" error was occuring. This occured out of nowehere also, nobody saved any field on this site this week as far as I know.

[angrybrad]

I realize it can be a stressful situation when it occurs, but if it happens again for anyone, if you could zip up the storage folder and the composer.json and lock files and send those with a database dump over to [email protected], we can take a look. Or even better, if it's on a publicly accessible server when it happens, some SSH credentials.

[ohbiko]

FYI: This just happened to me suddenly while developing on my local env (Mac Os High Sierra). Luckily it fixed itself while I was reading this thread. The storage output must be glitchy somewhere.

Will zip up the storage folder and db if this happens over.

[chrisrowe]

Also seeing this locally after updating to 3.3.15, using Valet, PHP 7.3 on Catalina.

If I see there error, delete the files and refresh and the files get recreated

-rw-r--r--  1 chrisrowe  staff  27015 18 Nov 16:26 ContentBehavior.php
-rw-r--r--  1 chrisrowe  staff  13146 18 Nov 16:26 ElementQueryBehavior.php

and the login page reappears, refresh again and I get the error, it happens on every other refresh, but the files don't change owner or permissions.

Storage folder and composer files zipped at http://up.chri.sr/Archive-NOiqB5.zip if that helps.

[angrybrad]

I believe we finally go to the bottom of this and it will be included in the next release.

If you want to give it a whirl ahead of time, chance your compser.json to refernce the specific commit for Craft and composer update - i.e.:

"craftcms/cms": "dev-develop#359b7f605fdcf6037e2ee0cf635ab6fcaa5ad703 as 3.3.15",

[engram-design]

@angrybrad Just ran into this issue (sorry, forgot to save the storage folder). We weren't using a load balancer, but were using OpCache on a standard Forge setup. No one was touching the admin, etc.

Going to give this a shot, but nice work otherwise! If it happens again, I know how to troubleshoot.

[gojira32]

Glad there's a fix coming. Happened to us after sending a BFCM email campaign. Lucky it was within office hours and we picked it up quickly!

[brandonkelly]

The fix was released in 3.3.16. Are either of you still getting this error after updating to that?

[engram-design]

Sorry @brandonkelly I don't think I explained that well. Haven't updated, but am doing so - will report back if it happens again

[engram-design]

@angrybrad Not sure if this is a different issue, but getting:

The command "/usr/bin/php7.1 /home/forge/site.com.au/craft queue/exec "296722" "300" "1" "" --verbose=1 --color=" failed. Exit Code: 255(Unknown error) Working directory: / Output: ================ Error Output: ================ PHP Fatal Error 'yii\base\ErrorException' with message 'Class 'craft\behaviors\ContentBehavior' not found' in /home/forge/site.com.au/storage/runtime/compiled_classes/ElementQueryBehavior.php:152 Stack trace: #0 [internal function]: yii\base\ErrorHandler->handleFatalError() #1 {main}

Every so often when trying to trigger Updating search indexes tasks. This also seems to be paired with:

The command "/usr/bin/php7.1 /home/forge/site.com.au/craft queue/exec "295187" "300" "1" "" --verbose=1 --color=" failed. Exit Code: 135(Bus error: "access to undefined portion of memory object") Working directory: / Output: ================ Error Output: ================ Bus error (core dumped)

So maybe its unrelated.

[angrybrad]

@engram-design hrm... odd and first time I've seen that 2nd error. It seems potentially unrelated. That second error looks like it's coming from Symfony Process: https://github.com/symfony/process/blob/master/Process.php#L104

[brandonkelly]

We just released Craft 3.3.18 with some tweaks to how ContentBehavior / ElementQueryBehavior are generated. Let me know if it helps.

[engram-design]

@brandonkelly Will give it a shot!

[lukebailey]

Not sure if this is related to the above issue/changes but we have started to see the following PHP errors since upgrading to Craft 3.3.17

[04-Jan-2020 05:55:16 Europe/London] PHP Parse error: syntax error, unexpected end of file, expecting function (T_FUNCTION) or const (T_CONST) in /var/app/current/storage/runtime/compiled_classes/ContentBehavior.php on line 318 [04-Jan-2020 05:55:16 Europe/London] PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0

[05-Jan-2020 06:12:16 Europe/London] PHP Warning: Unterminated comment starting line 842 in /var/app/current/storage/runtime/compiled_classes/ContentBehavior.php on line 842 [05-Jan-2020 06:12:16 Europe/London] An Error occurred while handling another error: ParseError: syntax error, unexpected 'ar' (T_STRING), expecting function (T_FUNCTION) or const (T_CONST) in /var/app/current/storage/runtime/compiled_classes/ContentBehavior.php:843 Stack trace:

[brandonkelly]

@lukebailey There have been fixes related to ElementQueryBehavior / ContentBehavior as recently as 3.3.18.4, so please try updating to the latest.