Call to a member function getBlockTypeHandle() on a non-object

Permalink 1 user found helpful
While I was browsing my website for editing some pages. Concrete5 failed down with

Fatal error: Call to a member function getBlockTypeHandle() on a non-object in
/c5/updates/concrete5.6.0.2/concrete/core/libraries/block_view_template.php
on line 41


I was looking for solution in the forum [1], found a lot of threads talking about cleaning the cache and other handlings from the dashboard.

But I can't go to the dashboard. The login page is accessible (when not signed in), but the dashboard also shows the same error.

I tried to access directly to the page /c5/index.php/dashboard/system/optimization/clear_cache/cache_cleared/, but it does nothing.

A response [2] in a thread said that re-installation does the job.
But a re-installation did not resolve the problem on my side.

There is also a bug report [3] marked as resolved, but it seems that their dashboard was not affected.

Do you have any ways to solve this situation?

Thanks

[1] :http://www.concrete5.org/community/forums/-/view/?search_keywords=g...
[2] :http://www.concrete5.org/community/forums/chat/site-error-after-edi...
[3] :http://www.concrete5.org/developers/bugs/5-6-0-2/fatal-error-call-t...

View Replies:
olivierweb replied on at Permalink Reply
As this bug is linked to the clipboard, I run this SQL query to dereference all blocks.

UPDATE BlockTypes SET btID=100 WHERE btHandle='core_scrapbook_display';


Of course, I lost contents, but my website is again online.
jamesfinn replied on at Permalink Reply
jamesfinn
This same error message was returned after deleting forms from the "dashboard>form results" page. I ran the above query and was back online. Thank you for this contribution.
madmichael replied on at Permalink Reply
madmichael
After setting the blocktype to 100 if you then go into the blocks table and run "SELECT * FROM Blocks where btID = 1" to get all the blocks. Then one by one change the btID to 100 refreshing your site after each one to find the specific blocks that are bad.

In my case it was the autonav blocks. I deleted those rows, re-created my autonav blocks in the page type defaults, applied to all child pages, and I was back in business.

The difference on these block was the btCachedBlockRecord field content. For all other blocks this was blank. In mine it was:

'O:11:"BlockRecord":10:{s:5:"_dbat";i:1;s:6:"_table";s:22:"btCoreScrapbookDisplay";s:8:"_tableat";s:22:"btCoreScrapbookDisplay";s:6:"_where";s:6:"bID=15";s:6:"_saved";b:1;s:8:"_lasterr";b:0;s:9:"_original";a:2:{i:0;s:2:"15";i:1;s:2:"13";}s:11:"foreignName";s:11:"blockrecord";s:3:"bID";s:2:"15";s:11:"bOriginalID";s:2:"13";}'


After the fact I thought the solution may have been to just delete that field content, but I haven't tested that theory.

When you are done it is a good idea to change all your btID fields back to one once the bad blocks are removed.