Had fatal error on site with PHP 8.1 that may be down to this module #166
Labels
question
Further information is requested
Comments
|
Thanks for reporting, @yorkshire-pudding. This is a strange error that I've never seen before. Entity Plus is like a mini-core for entities. Often the errors you get are produced in other places, but since a lot of the If you want to troubleshoot this, we'll need all the errors (including anything that happened before the one you posted), as well as a list of contrib modules in your site. |
|
|
|
I've had the issue again and switched to PHP 7.4 straight away and it fixed. Only happening on certain pages with 8.1 so time to test locally and see if I can get some useful Krumo backtraces |
Stack traceAlso got warning: Warning: class_implements(): Class MatchRedirectEntityController does not exist and could not be loaded in entity_plus_theme() (line 994 of /app/docroot/modules/contrib/entity_plus/entity_plus.module). |
|
Tracked it down. Match Redirect module is causing it. As this is not essential to the site (was using it to redirect bots looking for Wordpress pages to a custom page) I can disable without causing any issues until this is resolved. I have transferred log details to an issue there, but if you have any insights on what is going on there, then might be helpful; looking at the module it looks like the class |
|
@yorkshire-pudding thanks for including the backtrace. I'm looking at it, and there are some clues of what's going on there. First, this whole chain of events is happening because of an earlier "custom PHP error" (see line 12 in the backtrace), that triggers a "fallback" to maintenance mode. You can see that in number 10 in the backtrace (the lower you go in that backtrace, the further from "now" you are). When backdrop tries to theme the error, to do that it has to reinitialize the whole theme registry, which is not cached for some reason (see number 6). The problem is that, when you are in maintenance mode, that include file with It would be helpful to check your log to see if there are any other errors logged in before the fatal one - that can offer clues to what was the initial error that unleashed the whole series of events. Ultimately, perhaps a good stopgap measure would be for So, in the end, while disabling Match Redirect may help, ideally we need to find where the original uncaught PHP error. occurred. I'll try to come up with a way for you to temporarily patch Entity Plus in php 8.1 so that you can try to reproduce the error. Once patched, we may be able to see what the original error was. More later |
|
Hmmm... some of my logic above may not be correct - not sure if we are in maintenance mode. |
|
I'll try to see what other errors could be related. Just to clarify though:
No - it happened first updating a node. That node has entity reference fields, data, embedded youtube but nothing particularly special. After it happened there it then happened on nearly every page load until I fixed it. Then after putting it back to PHP 8.1 it behaved mostly until I tried updating a node again. |
|
Got this when accessing status report:
Also got this odd error:
but the calling URL is The header very clearly says: <link rel="apple-touch-icon" sizes="180x180" href="/files/favicons/apple-touch-icon.png"/>( I use responsive favicons module to handle these) PHP error log in docroot - from yesterday |
|
Thanks for the additional info. All of these logs point out at an initial error that triggers the whole chain reaction that ends with the E+ fatal. The first function in the chain is always In order to find out what is producing this error, please try the following manual patches: Line 180 of entity_plus.module if (isset($info['controller class']) && class_exists($info['controller class']) && in_array('EntityPlusControllerInterface', class_implements($info['controller class']))) {Line 994 of the same: if (isset($info['controller class']) && class_exists($info['controller class']) && in_array('EntityPlusControllerInterface', class_implements($info['controller class']))) {Then, using PHP 8.1, edit that node once again to trigger the initial error. Supposedly, the patches above will prevent E+ from crashing (they may produce other problems, though). The crashing happens because those E+ functions are being called at a time when autoload hooks haven't yet run. So, the above should hopefully reveal what the original error is that's triggering all of this. |
|
(Fixed a typo in the above) |
|
Shoot. More typos! Let me fix those before you patch. |
|
And presume I should re-enable match_redirect, right? |
|
OK, done. |
|
Yes, get the site to the state where it was when it crashed. |
|
Must have been something else as well as it will not recreate the error 😕 |
|
Can you check the dblog for the most recent messages after you've updated the node? |
|
Also, clear caches, update node again, save, clear caches again? Then check dblog. |
|
Nothing there at all either before or after clearing caches. 😕 |
|
Hmm... the other odd error you included there:
This is strange, and may be the originating error that triggered the whole thing - but obviously hard to reproduce. Somehow, the variable Otherwise, that manual patch should prevent the fatal error for now. Keep an eye on the dblog for other errors, esp, the one above. |
|
One common thing in all the backtraces you posted: they ALL happen in relation to maintenance mode. Can you try putting your site in maintenance mode and editing that node once again? |
|
No difference with maintenance mode: list of modules
|
|
Got more errors when running I did raise this issue quite some time ago so probably all related |
|
@yorkshire-pudding those spots can be temporarily fixed the same way I mentioned above - add It's the same issue: those functions are running before the autoload hooks have run - for an unknown reason. |
|
@yorkshire-pudding - question: do you have the Drupal compatibility layer enabled? I see match_redirect still uses some drupal namespaced functions - in hook_init, which may not be caught. |
I do have drupal compatibility switched on for that site; checked both locally and on host.
That was with the patch you suggested (it is the same site). The git pull happens before the config-import |
No, no. You fixed those other lines. I meant: you need to fix these NEW lines with the same patch.(281 and 262). |
Thanks. patching those lines too enables config-import to work |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've had a site on PHP 8.1 for a while with no problem. Yesterday on mobile, I updated a field on a node and saved. Wasn't showing in view to attempted to flush caches.
Site went 500 for logged in users whilst could still load front end, but eventually front end went as well (presumably when cache expired). When I got a minute, I went on and tried a few things to fix.
Tried clearing caches with bee and got this error:
Put in maintenance mode with bee
Deleted the entity_plus directory and re-downloaded (so latest version) with bee (no disabling or uninstalling - too many dependencies). No change
I then tried PHP 8.0 - same.
Then tried PHP 7.4 and site worked.
This site had been a bit neglected (not any security updates) and there were a few updates. I did those updates in GUI (including core) and was fine.
I then tried putting it back to PHP 8.1 and everything was fine again.
I'm reluctant to call it a bug as I have no idea of steps to reproduce. It could be a combination of things and I don't want to try and reproduce. I just wanted to put this here in case this bit of code could be improved to prevent this happening again if conditions give this function the wrong type again?
The text was updated successfully, but these errors were encountered: