1.188 will not save configurations for blocks, Please ensure that each block description is unique. error is emitted. In looking at the code, I note that there are no entries in the "boxes" table, which is being validated when the error message is thrown.

This may be related to an issue I have with not being able to activate blocks on a per-user basis. The selection boxes appear in "my account" but selections do not take (no errors anywhere on that one.).

carl.

Comments

asimmonds’s picture

Assigned: Unassigned » asimmonds
Status: Active » Needs review
StatusFileSize
new803 bytes

Should check if block is a custom block in block_admin_configure_validate, info field is blank for a module block.

carlmuck’s picture

Still didn't fix the issue.

I don't believe I'm using any "custom" blocks. All are coming from drupal "standard" modules (e.g., forum and aggregator). However the error is still being emitted.

carl.

carlmuck’s picture

It appears to me that the block configuration is never setting any values in the "boxes" table for the "standard" blocks.

If I create a custom block, I can make the admin/block/configuration settings work, (they are still not live on the user's "my account" page though) however I want to perform settings on "standard" blocks (e.g., user login, aggregator, book navigation).

It's not clear to me how the 'custom' tag is being used, the logic of the block_admin_configure_validate() seems to mean "custom" to be a "custom block" however in the block_admin_configure() it seems to imply customizable content.

I'm learning quickly, but don't have a good idea how to fix this.

carl.

carlmuck’s picture

Last note, if i simply ignore the error (comment out the form_set_error) everything works ok. ) At least on the admin page..

carl.

eferraiuolo’s picture

I am having the same issue.

For example, if I wanted the "Navigation" block (which is a standard block that is there by default) to only display on admin pages I would set the setting to appear on specific pages and put "admin/*" for which pages the navigation menu should appear on. When trying to save this setting, the validator throughs an error requiring input (block description) in a field that doesn't exist on the standard blocks' configuration pages.

I believe this validation is in place to account for a bug in the 4.6.x custom blocks where when you didn't give each custom block a unique description it would through up a error from duplcate entries in the database.

It appears that a fix would be to check first if the block is of custom type before trying to validate for a description.

carlmuck’s picture

I believe that Antony's patch attempted to fix that (which does seem to be the right thing to do) however, the notion of "custom" is a little fungible in the code.

The fix he chose (checking that $form_values['custom'] is set) sounds right, however, it appears the context for "custom" in the form_values is that the form is customizable not that the block is a custom block.

I may be able to dive in more deeply this evening and see where the "custom block" data is kept (I think its in a combination of "blocks" and "boxes" tables) and which validation makes sense for (almost) 4.7.

carl.

asimmonds’s picture

StatusFileSize
new814 bytes

Sorry for the screw up, try this patch, as the block's module is in $form_values so we can test module == block

eferraiuolo’s picture

This new patch appears to work, as I was able to "configure" a standard block built by the system, without getting the validation error.

Good work!

carlmuck’s picture

That appears to have fixed this one.

thanks,

(now on to figure out why block settings don't save in user//edit.)

carl.

chx’s picture

Status: Needs review » Reviewed & tested by the community

this is good to go.

dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to HEAD. Thanks.

Anonymous’s picture

Status: Fixed » Closed (fixed)