| Project: | Drupal core |
| Version: | 6.x-dev |
| Component: | block.module |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
I think this bug dates back to when there was a separate checkbox for 'enabled' on the blocks page (in 4.6 I think). We eventually decided that being in the "Disabled" region was equivalent to having the box unchecked, so the checkbox was removed entirely.
There's some lingering cruft still from this change, the region for disabled blocks can either be 'left' or an empty string. Since these blocks are not in the left column ever, I think making an empty string represent a disabled block in the database is the correct solution.
To reproduce the inconsistency, fresh install D6. Take a look at your blocks table before visiting admin/build/block. 3 rows exist (login, navigation and powered by drupal). After visting admin/build/block, all the other blocks populate the table with status = 0 and region = 'left'. Don't make any changes and save the form. Now all the columns for disabled blocks are status = 0 and region = ''.
This will make our logic when pulling in blocks simpler, so we won't have to check status to see if a block should be in the disabled region.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| block_empty_regions.patch | 1.28 KB | Ignored: Check issue status. | None | None |
Comments
#1
Looks great to me. system_update_6036 just got committed though so needs a re-roll, but otherwise ought to be RTBC.
#2
No problem. Here's the re-roll.
#3
Committed to CVS HEAD. Thanks quicksketch.
#4
This patch introduces a database schema inconsistency (reported by schema.module). You can't change a table schema with a corresponding update function.
Fix attached.
#5
Agreed, committed. Thanks!
#6
Crap. Sorry Barry. I won't make the mistake again.
#7
Automatically closed -- issue fixed for two weeks with no activity.