I am in the process to cut through the input format clutter. My analysis at http://groups.drupal.org/node/8911 shows that there are numerous modules to allow admins to limit the number of input formats per role and/or node type. This first patch adds order customization support to allow sites to set their preference, instead of taking the default "Filtered HTML", "Full HTML", ... order and live with that.

The attached patch does the following:
- adds a weight column to {filter_formats}
- provides upgrade path to this weight column
- orders the formats by this weight
- modifies the format admin form to be a tree form so we get all weights submitted
- also modifies it to use the format is as key, not the name, so invalid chars will not end up in the HTML output (which breaks the form submission)
- adds the weight column to the form
- adds drag and drop support in the theme and asks the JS to hide the weight column when it is active
- saves the weights in the submit function

I tested both the upgrade path and the functionality and it seems to work fine.

In the meantime we discuss how to limit the displayed input formats at http://groups.drupal.org/node/8911, easing content input for users, getting rid of an unneeded selection widget in most cases.

CommentFileSizeAuthor
#5 order-input-formats-1.patch11.13 KBkeith.smith
order-input-formats.patch5.96 KBGábor Hojtsy
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented

I'd like to include a CHANGELOG.txt hunk in the final patch as well, but http://drupal.org/node/222190 currently blocks that. It should not hold off testing however :)

Dries’s picture

Dries CreditAttribution: Dries commented

It's possible for people to change the default -- doesn't that solve most (if not all) of the problems? I'm not sure I fully understand what this enables ... maybe I'm missing something. Could you explain the use case, benefits and purpose of this patch in slightly more detail? Thanks.

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented

Well, I am planning gradual improvements to the filter API / interface. Currently, if you run a wiki site, but would like to add static pages with full HTML content as well, you most probably add the wiki input format as the third input format. You can set that the default, but it looks clunky to have the third input format the default, right? For users to be able to see the logic in "this is the one you will use most", "this is one you use slightly less", "this is one you only use when absolutely needed", proper ordering for they eye scanning would be great IMHO.

My next step (patch coming) is to eliminate some options altogether on certain sites, where it is possible to tie input formats to node types, so options can be taken away (not just reordered), further simplifying the users decision. First, I think ordering support would enhance the user experience, since currently Drupal only supports an order of how the formats were set up, with the "built-in" formats being up at the top. A good example is if you enable the PHP module before you set up your wiki format, it looks like PHP input is conceptually more important (up in the list) compared to your wiki formatting. This is easily confusing.

I think better content input starts with clearing up the usability of what we have, so we have a solid base to build on.

Dries’s picture

Dries CreditAttribution: Dries commented

I've applied the patch and it works as expected. However, from an end user's point of view, it is not clear what the ordering is for. Should we try to clarify that with an extra sentence in the help text? I don't mind committing it as is, but I'm afraid it might confuse some users. Then again, if this is only an intermediate state, it might not be worth documenting the usefulness of this.

keith.smith’s picture

keith.smith CreditAttribution: keith.smith commented
FileSize
order-input-formats-1.patch11.13 KB

At Gábor's request, attached is a patch that reflects the original patch with the following changes:

  • The help text at admin/settings/filters has been substantially reworked. I removed the initial paragraph, as it was redundant with the information at admin/help/filter (though, perhaps we should add a theme("more_help_link", url('admin/help/filter')) on that page for easy linking to the embedded help). The new help text should cover the drag-and-drop ordering and have a bit more information about the Input format fieldset. The new help text does not explicitly provide instructions for adding new filters or mention that one must select configure to modify an existing input format. If necessary, I can add a sentence or two for those cases. In line with what we've done in other similar situations, there are no specific instructions for ordering items without using drag-and-drop.
  • The help text at admin/help/filter has been updated to follow the text at admin/settings/filter, and to reflect the new ordering options.
  • I added a CHANGELOG.txt entry in the style of similar entries in Drupal 6.

By the way, thanks to both Dries and Gábor for the opportunity to keep the help text in sync with new features. Playing catch-up later, probably right before string freeze, is tough!

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented

Thanks Keith! I read through your help improvements and they look great. I am in support of this getting in, but since it is my patch, I am not going to change status :)

Dries’s picture

Dries CreditAttribution: Dries commented
Status: Needs review » Fixed

Alright, great. This looks all solid so I've committed this to CVS.

Dries’s picture

Dries CreditAttribution: Dries commented

One more thoughts: doesn't that deprecate the 'default' checkbox? How about we make the first option always the default?

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

Reasonable suggestion. However, if input formats per content-type will be implemented, selecting "the default" might not be that easy. Because, what's the default input format, if the default format is not available for a certain content-type?

Can we dynamically select the first format as the default, based on the available, ordered list of input formats?

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented

Yeah, I thought about making the first option the default in all cases, as sun explains as well. But since selecting the default has permission implications (the default format should be accessible to all), reordering results in permission changes as well. This should be obvious to the user, and visible on the interface. I thought I'd better defer that to another patch, so to have smaller chunks to discuss.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.