Right now when adding a block, users do not see the visibility options for that block. This is very confusing for new users who don't know they must go back and click 'configure' to modify vis settings.
We should also have the region dropdown (and enabled checkbox until http://drupal.org/node/91906 gets in) on the block add/edit page so we can do this in all one swoop.
Right now you have to
1) Add a block
2) Find the block in the list and go back to the same screen in #1 by clicking configure and change vis settings
3) Then find the block again in the list to enable/choose region.
Starting the issue so I remember to roll a patch.
Comment | File | Size | Author |
---|---|---|---|
#37 | block.easy.add_6.patch | 5.96 KB | RobRoy |
#28 | block.easy.add_5.patch | 5.55 KB | RobRoy |
#25 | block.easy.add_4.patch | 5.57 KB | RobRoy |
#20 | block.easy.add_3.patch | 5.83 KB | RobRoy |
#18 | block.easy.add_2.patch | 5.84 KB | RobRoy |
Comments
Comment #1
RobRoy CreditAttribution: RobRoy commentedOkay, this was a bit harder than I expected, but I've got a working version here. You can finally add a block using the same form as when you configure one. No need for new users to have to 'know' to add a block, save, find in the list and hit configure again to get all these options. Much clearer.
I'd looove for this to get into 5.0 as I think it's a great improvement to the block admin interface along with kkaefer's patch. I did take out a chunk of redundant code that can be put back in for a release cycle if that is a big deal as it won't hurt anything, namely block_box_form_validate(), block_box_form_submit() which are useless now that we are using the configure form callbacks to handle adds/configures. Also, {boxes} now uses sequences and I covered this in system.install, but I need someone to check that Postgres update.
Comment #2
RobRoy CreditAttribution: RobRoy commentedRe-rolled to include new changes in HEAD.
Comment #3
RobRoy CreditAttribution: RobRoy commentedCorrect version.
Comment #4
RobRoy CreditAttribution: RobRoy commentedAdded a screen shot. It's the same as the edit blocks page, but now we can do it while adding blocks! No more confusion.
Comment #5
m3avrck CreditAttribution: m3avrck commentedI think this is a great idea and I face this problem constantly, great idea RobRoy!
+1 for the idea
Don't have time to look into the patch thoroughly right now but subscribing for updates.
Comment #6
Dries CreditAttribution: Dries commentedPersonally, I'm not a fan of how this patch abuses the block hook -- it is a rather obscure practice, although it saves us some code. I think we'll want to work on a more elegant implementation that still re-uses code.
In general, this is too big of a change to include in Drupal 5.0.
Comment #7
RobRoy CreditAttribution: RobRoy commented@Dries, when you say this abuses the block hook, are you referring to adding a return value for hook_block('save')? What are the potential negative implications of this? Let me know any specifics and I'll try to work on them.
Also, "it is a rather obscure practice, although it saves us some code." Could you elaborate on this "obscure practice" I'm not sure I follow. Thanks!
Comment #8
RobRoy CreditAttribution: RobRoy commentedReferenced at http://drupal.org/node/98390.
Comment #9
Heine CreditAttribution: Heine commentedAn alternative approach displays the block configuration form with a custom submit handler.
Comment #10
Steven CreditAttribution: Steven commentedFixed bugs:
'' block
for new blocks.bid
sequence needs to be set to the right value in the update.Needs to be tested, especially on pgsql. Be sure to clear the menu cache.
Comment #11
RobRoy CreditAttribution: RobRoy commentedI removed one extra space and made $delta a mandatory argument since we removed the code to check if (isset($delta)). This approach is much cleaner as I know see what Dries was saying about sacrificing some code duplication for more readable code. This works with me and should get into 5.x.
Comment #12
RobRoy CreditAttribution: RobRoy commentedSetting RTBC. I know I posted the last patch but it was a very minor change so I'm not really RTBC'ing my own patch...right? This is a big-time usability improvement and needs needs needs to get into Drupal 5 IMVVVHO.
Comment #13
RobRoy CreditAttribution: RobRoy commentedP.S. sepeck told me to. :)
Comment #14
RobRoy CreditAttribution: RobRoy commentedI know this is marked a feature request, but this is also a big usability bug and with all the great usability enhancements in D5, it would be a real shame not to get this in. Dries, can you take a look and see if the latest patch (that has been looked at by Heine and Steven) is up to snuff?
Comment #15
Dries CreditAttribution: Dries commentedThe patch got better, but it is still a bit hack-ish IMO. For example, having to specify a fake delta and than special casing block_admin_configure() to deal with fake delta's. It doesn't make for readable code.
Also, this should wait for Drupal 6 IMO.
Comment #16
RobRoy CreditAttribution: RobRoy commentedDo you mean the fact that the add form has delta == 0 and then we overwrite that with the next seqid in the _submit()? menu_edit_item_form() does this and even though mid == 0 means less it's still the master root mid, right? My patch set $delta = NULL for the add form which is maybe a tad better. Is this criticism because any form_alter-injected validate/submit callbacks may think that this delta is talking about the actual block-0 not a fake added one. What would you recommend instead?
Do you mean this code to set a more apt title? We could easily remove this and just have the menu item's title be t('Edit block') if you've got a big problem with it, but I think we should leave it. Maybe I'm missing your point.
Of course I think this is thaw-worthy as it's so close and so important for blocks usability (it seems like other worthier people agree too :P), but of course...you're the man and I respect whatever you decide. :)
Comment #17
Steven CreditAttribution: Steven commentedI disagree with Dries... in Drupal 5.0 now, adding blocks is incredibly confusing and difficult. It needs to be fixed.
Will look at the code later.
Comment #18
RobRoy CreditAttribution: RobRoy commentedThat's music to my ears brother. Marking 5.x not to be a pain in the ass, but just so this gets one last look.
I've re-rolled the patch and added a bit of Doxygen over the system_update_X() call. This still works great and I'll say it again, this belongs in 5.0! =D
Comment #19
pwolanin CreditAttribution: pwolanin commentedI like the general thrust, but why does the patch alter the bid column in the boxes table from int to tinyint? This seems like it undoes a recent bugfix.
Comment #20
RobRoy CreditAttribution: RobRoy commentedGood catch. I missed that the update code had that. Re-rolled.
Comment #21
RobRoy CreditAttribution: RobRoy commentedOh, and thanks for the catch pwolanin!
Comment #22
Steven CreditAttribution: Steven commentedRaising this on the radar.
Having the "add" form for a block be a completely stripped down version of the "edit" form goes against everything we have in Drupal. This is a bug that should've been caught in the block configuration reforms, and the kind of usability goof that should put red on the cheeks of everyone involved.
Comment #23
RobRoy CreditAttribution: RobRoy commentedStill applies with offset. I've tested this out and it works great. What's holding this up? The final word from Dries?
Comment #24
drummThis patch changes quite a lot. Things like the database change and helper function changes should be split off so each part can get a proper review.
It may not be realistic to get this large of a change in Drupal 5 a this point.
Comment #25
RobRoy CreditAttribution: RobRoy commentedThe db change and form changes are interconnected, so I don't think they should be split apart as that would make reviewing harder IMO. Here is a re-roll as the update_X needed an increment.
Comment #26
BioALIEN CreditAttribution: BioALIEN commentedI must agree with the general critics with regards to the block system. I've raised my fair share of issues with it and suggestions (tracker my 1st post). It's a part of Drupal that still needs some work and it seems to be getting some usability attention right here.
+1 for the efforts to get this into Drupal 5.
Comment #27
Dries CreditAttribution: Dries commentedSorry but this is not a critical bug. Critical bugs prevent Drupal from working.
Playing tricks with the 'delta' is a bit of a hack but probably the simplest solution for now. :/ Not sure this should be committed as is.
The following function can be written shorter (or can be eliminated):
Comment #28
RobRoy CreditAttribution: RobRoy commentedHere's a patch that just does return block_admin_configure('block', NULL); I had a solution above that consolidated the form into one and you said (and I agreed) that it was a bit convoluted and would prefer some duplication over a cleaner method. This way is much cleaner and there is only a little duplication. We could remove that function and pass a #base element as a param to dynamically tell the form which validate/submit to go to, but this only adds 3 lines of code and is much more visible.
Yeah, this seems to be the best way we have at the moment.
Everything else is the same in this patch, just removed setting the $form needlessly. Look good enough?
Comment #29
chx CreditAttribution: chx commentedI am vehemently against a DB change at this point of the release cycle (of course if something is utterly broken that's something else, but this is only bothersome). And even if the powers that be overrule me, where are the pgsql changes?
Comment #30
RobRoy CreditAttribution: RobRoy commentedIt seems pgsql doesn't need changing...see http://drupal.org/node/92630#comment-157490
From a usability standpoint this is utterly broken for new users IMHO. For you and me it is only bothersome, for new users this behavior is totally borked.
Comment #31
joshk CreditAttribution: joshk commentedI was going to submit a separate bug to point out that it was impossible to set the block title (let alone visibility) when creating a new block, which is a step backwards from 4.7. With the caviat that I haven't reviewed the scope of the patch (changing the DB schema sounds out of scale with the problem) the functionality gets a +1 from me.
Comment #32
joshk CreditAttribution: joshk commentedThe DB change to use drupal sequences rather than auto increment is probably a good thing in the long run, but seems unrelated to the problem/solution here.
Comment #33
RobRoy CreditAttribution: RobRoy commentedActually the db change is related to this change here as it's needed to get the next box ID upon adding a new block. This is how we're able to add the vis/other settings to the blocks/blocks_roles table on box creation.
Comment #34
RobRoy CreditAttribution: RobRoy commentedCome on boys, let's get this in! Steven, any last words?
Comment #35
seanr+1
Comment #36
joshk CreditAttribution: joshk commentedPatch applies clean vs current HEAD and works as advertised. Only thing better would be the ability to enable and place the block in a region w/weight. But this is good. Let's commit it!
Comment #37
RobRoy CreditAttribution: RobRoy commentedThe system update needed a new number. Same patch re-rolled against HEAD.
This has had plenty of reviews, let's get this in to D6!
Comment #38
Dries CreditAttribution: Dries commentedAlright! Committed to CVS HEAD. :-)
Comment #39
RobRoy CreditAttribution: RobRoy commentedThank you. Thank you. Thank you. :D
Comment #40
(not verified) CreditAttribution: commented