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.

Comments

chrisfromredfin’s picture

chrisfromredfin
he/him/his
Primary language English
Location Portland, Maine
commented

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.

birdmanx35’s picture

birdmanx35 commented
Title: Make a module that adds a "Save and Edit" button to the block configuration form » DROP Task: Make a module that adds a "Save and Edit" button to the block configuration form

Being obnoxious.

criznach’s picture

criznach commented

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

solipsist’s picture

solipsist commented

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.

criznach’s picture

criznach commented

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.

chrisfromredfin’s picture

chrisfromredfin
he/him/his
Primary language English
Location Portland, Maine
commented

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)?

criznach’s picture

criznach commented

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.

solipsist’s picture

solipsist commented

A simple solution works when editing an existing block, but not when creating a block.

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.

cwgordon7’s picture

cwgordon7 commented

Is this issue closed?

criznach’s picture

criznach commented

No, not closed yet. I'd like to clean up a couple of redundant parts in the code and will check in an update.