Hello,
After update 1-9-5, I get the follwoing error message:
Fatal error: LayoutRendererStandard::prepareBlocks(): The script tried to execute a method or access a property of an incomplete object. Please ensure that the class definition "ViewsBlock" of the object you are trying to operate on was loaded _before_ unserialize() gets called or provide a __autoload() function to load the class definition in /<MYSITE>/core/modules/layout/plugins/renderers/layout_renderer_standard.inc on line 214
Replacing the previous core do not solve to problem (1-9-5 did not asked for db update if I remember correctly).
I did not find similar issue in the forum, nor by searching the web...
Any idea how to solve?
Thanks!
Comments
Hello @patch-works, I'm afraid I haven't heard of anyone else encountering that particular problem. Have you tried asking in the Gitter live chat?
Hello,
I'm not used to Gitter live chat, I will have a look.
Thanks!
I get a supplementary error message when accessing some sub pages, e.g. /user
If a third party, I would remove it, but with a core module, I'm hesitating a little bit...
These error messages from core modules (first Layouts, now Views) are certainly alarming.
These functions and classes should be available, but it seems your system is unable to locate them for some reason. Do you know if your server is running an opcode cache? Something like APC, Xcache, or OPcache? Where are you hosting your site? Can you share any specifics about the server or set-up?
Does anyone else have any idea as to why Backdrop may not be able to locate it's own code, in this instance?
Hello,
The Website is hosted at Infomaniak, it is a shared hosting using Apache, MySQL 5.6 and PHP 7.0.x
I cannot find right away about use of cache, I will further look into it.
But, I made a test by connecting the site to another BackDrop database (a test I made for another site): the content appears ok (well layout is not ideal). This test site did not used views.
I think I will see if I can find a back up of the database to restore....
OPcache is listed in the PHP informations, hosting also provides some optimisation, but none is activated (Google page speed, file compression)
Both errors seem to mention Views. Did you have some custom Views with maybe some PHP code?
Hello,
No, no custom code, I'm a basic user (well I started with Drupal 4.5, but always using out of the box core or module only :-)
Views are used for creating lists, some with filters available for visitor to chose.
Hello,
I could progress:
By this, I could get access to the website, first with some warning, then without anymore.
The site was running apparently ok, only the views related to a menu or the menu themselves have disappeared from the front-end (menu are not visible anymore, list from a hard link in a page generate an error page). I think the blocs related to views were ok (I did not paid notice, now everything is back in place, I'm not sure....)
All views were ok in the back-end. Saving again the menu of one of the views restored all menu linked to a view. Saving again the only page linked to a menu without a view also restored the menu fully (when viewing this page, the views related menus were not present while present when consulting any other menu...)
If setting back to the initial database, the error code is back...
Now the site seems almost back to normal service.... The 2 web-forms I created seem to have disappeared (node is there, but all fields are away...). I do not see directly hwo to restore, I will probably recreate....
Hello,
Some new error message when visiting login page. I changed PHP version (back to 5.6, 7.0, 7.1), no change...
I wonder if it's file permissions. Once you changed the files the web user might no longer have access to those files?
Hello, thanks for the suggestion. I checked all folders' permissions at root level + core/modules/vies ad views UI; everything seems ok (755)
i once saw a similar issue, with a views function not found. this is obviously a hack workaround, but i simply added conditional code similar to:
if (! function_exists('views_func')) { require(that_views_file); }again, a real hack, and not the solution. but it works, and seems low-risk enough.