DROP Task: Make a module that adds a "Save and Edit" button to the block configuration form
solipsist - February 22, 2008 - 01:44
| Project: | DROP |
| Component: | Task ideas |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
If you have ever been typing PHP code in a custom block and have wanted to save it to test your code, only to be annoyed at having to click Configure next to your block again, and again, and again (times three million) - this is the module for you!
Getting around this is quite easy since you can use ?destination= to return to the form after clicking Save but it has to be done manually. A module that uses hook_form_alter and drupal_get_destination could easily solve this problem and enhance the usability of the custom block configuration form.
#1
As a reference, I suggested this as a 7.x wishlist item: http://drupal.org/node/216310
note comment #1, which I think is, in general, a good suggestion.
#2
Being obnoxious.
#3
I'm still a total noob with CVS and the release system, but here's my project. I've added 5.x beta and 6.x beta releases.
http://drupal.org/project/block_save_edit
#4
Had a look at your code and I must say I envisioned a solution that was much simpler. Did you try what I suggested, i.e. append ?destination=admin/build/block/configure/$bid to the path and do a hook_form_alter and let Drupal handle the rest? It was just an idea that I had, so it may not work but I think it should be tried because it doesn't involve mimicking block.module since it will redirect you anyway provided you have destination set.
#5
A simple solution works when editing an existing block, but not when creating a block. When creating a block, the submit handler doesn't know the bid and the insert function does not return it. And there's also the _block_rehash function that's normally called when you view the block list. If you don't call that, the block is not completely saved. So I handled that problem first.
The edit case does pretty much what you suggest. But I don't see how setting ?destination would work because we have two submit buttons. So setting the form redirect property wouldn't handle both cases.
In any case, I think there is probably some simplification that could happen and I'll work on it a bit.
Thanks,
Chris.
#6
How much simpler would it make it if the "apply" button only showed up on existing blocks (i.e. just ignore this function for new blocks / you HAVE to create one first the normal way)?
#7
You'd still need a form_alter hook and submit handler to determine which button was pressed. D6 makes this a tiny bit easier. It depends, are you looking for minimal code or functionality? It could certainly be removed.
#8
You're right, I didn't consider that use case.
I personally prefer minimal code when it makes sense. "Don't repeat yourself" and "separation of concern" are principles I try to code by. Perhaps there are ways you can further improve the code with those principles in mind.
Nice and quick work by the way! It's cool to see someone claim the task, especially as the lack of this feature has annoyed me for a very long time.
#9
Is this issue closed?
#10
No, not closed yet. I'd like to clean up a couple of redundant parts in the code and will check in an update.