catalyst / moodle-block_multiblock

Moodle plugin which allows you to embed multiple blocks within a single block region using different formats including tabs and accordions
GNU General Public License v3.0
12 stars 12 forks source link

Error when chaning dashboard for all users #62

Closed rschrenk closed 4 years ago

rschrenk commented 4 years ago

I was testing this plugin on Moodle 3.9. When I added a multi block instance on my personal dashboard, everything worked fine. I tried to add in the site wide dashboard and got the following error:

Stack trace: 

    line 617 of /cache/classes/helper.php: coding_exception thrown
    line 958 of /cache/classes/loaders.php: call to cache_helper::hash_key()
    line 392 of /cache/classes/loaders.php: call to cache->parse_key()
    line 1553 of /cache/classes/loaders.php: call to cache->get()
    line 124 of /lib/classes/string_manager_standard.php: call to cache_application->get()
    line 327 of /lib/classes/string_manager_standard.php: call to core_string_manager_standard->load_component_strings()
    line 7387 of /lib/moodlelib.php: call to core_string_manager_standard->get_string()
    line 131 of /blocks/multiblock/classes/form/addblock.php: call to get_string()
    line 64 of /blocks/multiblock/classes/form/addblock.php: call to block_multiblock\form\addblock->get_sibling_blocks()
    line 214 of /lib/formslib.php: call to block_multiblock\form\addblock->definition()
    line 51 of /blocks/multiblock/manage.php: call to moodleform->__construct()
Arantor commented 4 years ago

Did it give you any more detailed error than the generic Moodle 'coding exception'?

rschrenk commented 4 years ago

Here are all error messages of that page Fehler in der Kodierung gefunden, den nur ein Programmierer korrigieren kann: Cache definition core/string requires simple keys. Invalid key provided. Weitere Informationen über diesen Fehler

and

Debug-Info: de_block_ _1592842673 Error code: codingerror

and then the stack trace from above.

Arantor commented 4 years ago

Interesting... what caching store(s) do you have set up?

I've just tried to reproduce this on my local 3.9 which only has filestore set up, was able to add blocks normally to the system dashboard and to reset everyone (successfully) to it.

Arantor commented 4 years ago

Hmmm, that looks to me, looking at the actual code now, that you previously added a block to the system dashboard that has since been removed but without the proper cleanup step having been carried out... in your plugins list, do you have any block plugins listed as 'missing from disk'?

(It shouldn't break it like this, of course, but that is currently the best working theory as to how you have this issue.)

rschrenk commented 4 years ago

Hello,

I just checked all plugins in that Moodle. No block with missing source.... sorry. We did not modify anything with the cache stores. This is more or less a standard Moodle installation. I tried to purge the caches, but it did not change anything. I will get the same error message.

Kind regards

rschrenk commented 4 years ago

Hi, I investigated the code and found, that for some reason a block has no name! I added in classes/form/addblock.php before lin 131 the following code: echo "ADD SIBLING " . print_r($sibling, 1) . "\n"; and got as result: ADD SIBLING stdClass Object ( [id] => 37 [blockname] => [parentcontextid] => 1 [showinsubcontexts] => 1 [requiredbytheme] => 1 [pagetypepattern] => * [subpagepattern] => [defaultregion] => side-pre [defaultweight] => 0 [configdata] => [timecreated] => 1587497593 [timemodified] => 1587497593 )

In database, this block is 37 | site_main_menu | 0 | 0 | 1

I changed line 118 to if ($sibling->blockname == 'multiblock' || empty(str_replace(' ', '', $sibling->blockname))) {

Kind regards

Arantor commented 4 years ago

Interesting, thanks for the investigation! I'd be intrigued as to how it got there since it's not from a default install (and one I couldn't replicate without deliberately editing the database)

I have a slightly different fix in mind for this, which I'll release today or tomorrow - it won't just look for empty blocks, but assert that the blocks trying to be moved are valid by checking with the plugin management system (which will also prevent the case I thought you might have had, where a block that was removed was still being queried for)

rschrenk commented 4 years ago

Finally I found out, that this was the only entry in the blocks_instances table that had no pluginname. Therefore I think this was an inconsistency of our database. After removing this block instance everything worked fine.