Make it easier to customize a block title

The field discussed here is the 'title' field. a user must type in for no title, even though the field is blank. This is a usability bug.

Something like the following would fix this;

[ ] Customize Block Title
  [--------------------------]

(Unchecked checkbox and a disabled text input field)

Then, when checked;

[√] Customize Block Title
  [ |                        ]

(Checked checkbox and empty enabled text field)

Help text would then be unnecessary, or very simple.

If a patch were available for d6 could it go in given the various freezes?

+1 as this is a good idea!

I would show the default title in the disabled text input field until the checkbox is being checked, and reset to the default title if the checkbox is unchecked again.

The only problem is: How would this degrade w/o Javascript?

We could fall back to a solution (without a checkbox) where the default title is displayed in the field and is editable. Then we would need to provide a "Reset to the defaults" button at the bottom of the form.

Another way would be to use two radios to switch between the disabled default title and the editable custom title, something like that:

@ Default title         User login

O Custom title          [__________________________]

Probably the last variant is the best, as it is JS-free and easy to do at this late stage in the release cycle.

I would show the default title in the disabled text input field until the checkbox is being checked, and reset to the default title if the checkbox is unchecked again.

Great idea! This could be problematic for blocks that only display on certain pages, like 'node/N' pages, and have a dynamic title according the page they are viewed on. A minor tweak to the hook_block API could resolve it though. Or it could default to something generic if hook_block doesn't return a title.

Actually, if the title is dynamic, the user probably wants to think twice before changing it and making it static. Perhaps this could be integrated into a tweak to the hook_block API and the user is warned about it in the field description?

The only problem is: How would this degrade w/o Javascript?

The 'Custom Title' field is not disabled in the html, but is disabled on page load by javascript, and re-enabled when the checkbox is clicked.

We could fall back to a solution (without a checkbox) where the default title is displayed in the field and is editable. Then we would need to provide a "Reset to the defaults" button at the bottom of the form.

This is confusing and messy. The above approach involves less thinking.

Another way would be to use two radios to switch between the disabled default title and the editable custom title, something like that:

I like your second approach. I think my suggestion above is slightly better as there is less interface for the user to take in and understand. "The best interface is no interface". Your solution is easier to use in the JS-less situation -- however that is a minority for which these usability issues are considerably less important.

Moved this to 7.x-dev because I'm quite certain it won't get in to D6 (requires string changes).

Attached a patch that implements the checkbox solution outlined in #1 with a couple of shortcomings. I figured a patch would be nice to get a feel for how this could work, even if it's not complete. Missing:

• The default title is not inserted automatically because I couldn't figure out how to grab the default block title. The javascript is in place though.
• Helptext strings haven't been changed.

To see it in action you need to apply the patch and dump the new block.configure.js in the block module folder.

This solution degrades gracefully and it fully functional with javascript turned off. If JS it not available the textfield is always enabled, but its value is not used if the checkbox is not checked.

I am unsure if this solution is the most optimal one. In order to avoid changing the database format the form submit function translates the input depending on the checkbox. E.g. if the checkbox is checked, but the textfield is empty the database value is set to '<none>' to ensure the block title is left empty. Same when the form is created - on a value of '<none>' nothing is displayed in the textfield, but the checkbox is checked.

Great! Applies cleanly. Code style is good.

In the first hunk there is an unnecessary extra line break. The default title should be whatever hook_block has returned for the title. This might require a change to case 'info' of hook_block.

If the user has customized the title in the past, and then unchecked the 'customize' checkbox, they should be able to restore the customized block title simply by unchecking. Hints on one method of doing this; Don't clear the value attribute of the text field. Store the customized title, even if 'customized' in unchecked. You might need to store it as a drupal variable, or (hopefully not) propose a change to the database table.

It doesn't degrade. With javascript disabled, the Block Title text field is never enabled. Disable it on page load in the javascript, not in FAPI. Tip: Rather than make it work with javascript first and then fix it for no-JS, do it the other way around. Create it assuming no-JS, then enhance it for users with JS. That's the difference between progressive enhancement and graceful degradation. It's easier to start with your lowest common denominator then improve as more features become available to you.

The help text needs updating. It currently reads: "Override the default title for the block. Use to display no title, or leave blank to use the default block title." Something like "Leave blank to display no title." is enough.

I don't really understand your jQuery and am not sure what standards Drupal has about it's use so someone else will need to review that.

Excellent work! :)

See also #265413: Usability: block title override

Moving the issue to the Usability component for more usability exposure.

We no longer have a usability component, so adding usability tags.

Subscribe. This needs to get in.

At the moment using the PHP filter you can specify $block['content'] easily in the block config page, but it is impossible to set $block['subject'] using the same page- instead you have to make a whole module to do this. There are plenty of occasions where you will want to set the title dynamically- can we do this?

The patch needs to be rerolled with the issues in #5 addressed.

I would suggest a simpler solution:

Just put the default title in the block title screen. Don't save it to the database if it is the default, but just include it there. This means the user is not able to revert to the default, but I don't think that matters in 90% of cases. It also eliminates the need for . Since none would simply be an empty title.

Jacobsingh: nice!

I agree that is a great solution.

However there is at least one edge case that it does not handle: a block which has a dynamic title and is blank when there is insufficient context to determine it's title, might be blank on admin/structure/blocks, but non-blank on node pages, for example. With Jacob's approach the block title can not be suppressed, because the default block title is already blank on admin/structure/block.

Good call, but would clearing the prefilled string and saving that block with an empty title still work for that? Goal is to provide defaults, not forcing the ultimate fallback value, right?

In general, I'd like to move away from the UI drupalism that is the 'null is all' pattern. Other examples: block visibility settings like 'leave empty to show on all pages' and setting the default front page 'Leave blank to display the default content feed'.

Maybe we can start here :)

would clearing the prefilled string and saving that block with an empty title still work for that?

No. Because the prefilled string would already be empty. That was the entire point of #14.

Seems like with the component library we will fix this.

anyone still working on this?

Duplicate of #1875260: Make the block title required and allow it to be hidden