Closed (fixed)
Project:
Drupal core
Version:
x.y.z
Component:
block.module
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
15 Nov 2005 at 15:40 UTC
Updated:
30 Nov 2005 at 22:20 UTC
Jump to comment: Most recent file
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.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | block-validation-fix_1.patch | 814 bytes | asimmonds |
| #1 | block-validation-fix.patch | 803 bytes | asimmonds |
Comments
Comment #1
asimmonds commentedShould check if block is a custom block in block_admin_configure_validate, info field is blank for a module block.
Comment #2
carlmuck commentedStill 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.
Comment #3
carlmuck commentedIt 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.
Comment #4
carlmuck commentedLast note, if i simply ignore the error (comment out the form_set_error) everything works ok. ) At least on the admin page..
carl.
Comment #5
eferraiuolo commentedI 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.
Comment #6
carlmuck commentedI 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.
Comment #7
asimmonds commentedSorry for the screw up, try this patch, as the block's module is in $form_values so we can test module == block
Comment #8
eferraiuolo commentedThis 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!
Comment #9
carlmuck commentedThat appears to have fixed this one.
thanks,
(now on to figure out why block settings don't save in user//edit.)
carl.
Comment #10
chx commentedthis is good to go.
Comment #11
dries commentedCommitted to HEAD. Thanks.
Comment #12
(not verified) commented