Hey

I think it would be great if this feature was added into the module.
Users who can access other input filters, could choose to select one for their usage, different from the default for their current role.

that setting would be available in the user edit form.

example:
- someone in moderator role, which access to full html, could just choose to use only filtered html;
- two input filters, the same settings, but different WYSIWYG editors - users can pick which one to use (like WYWIWYG tinymce vs fckeditor vs ckeditor vs even the same editors but with custom menus!

this functionality already exists as the User Default Filter, so it shouldn't be hard to merge it into Better Formats.

i say merge, not only because it doesn't makes much sense to have 2 similar modules installed, but also because they don't work together. Better Formats is replacing User Default Filter functionality.

side note: User Default Filter only has a global setting per user, not a setting for node, comment and block editing.

Comments

dragonwize’s picture

dragonwize CreditAttribution: dragonwize commented
Priority: Major » Normal
Status: Active » Postponed (maintainer needs more info)

I thought about this before and actually intended to include it in the original version of BF. The problem is where would such a choice fit in the hierarchy of format defaults?

For example, a site has set:

1. Core global default: Filtered HTML
2. BF global node default: Full HTML
3. BF page content type default: Full HTML editor
4. BF(2.x) field level default: Markdown

Currently, the defaults override each other in the above order, where the greater number will be used as the default. So where would the user default go?

It seems logical in a pyramid type logic going from big to small that the user would be inserted at #2 since user is more specific than the site but not as specific as a node. That is until you think about the fact that the BF node default is always set so the user default would never be used, making it a useless feature.

My current thoughts, though I am welcome to new ideas, is that the level of defaults that BF allows would never work in combination with a user default method because you would have to have only the user default for that to work correctly.

lpalgarvio’s picture

lpalgarvio CreditAttribution: lpalgarvio commented

well, since this particular setting would be given to roles which some sort of powers (think power users, admins, moderators, etc), i think it should override #1 and #2, leaving only #3 and #4.

1. Core global default: Filtered HTML
2. BF global node default: Full HTML
**** user default ****
3. BF page content type default: Full HTML editor
4. BF(2.x) field level default: Markdown

Field defaults are very specific and should not be overridden ever i think.
Content type defaults are not as much specific as Fields, but still specific enough imo. they are also an optional feature.

User defaults would then override Global node/comment/block defaults and Global defaults.

as for the user defaults selection box, add:
- input formats allowed by the role(s) the users belongs to
- site default (no change from #1 and #2)

i'm also inclined to think that there should be a field set, and i should include the user default selection box for node, but also for comment and for block, instead of just a global default.
while inside a field set, it will clutter less the interface.

this feature could also be optional (or not) like content type defaults.

whether or not this would require a new role permission, like "allow user to set default input format"... i think it won't require developers to rethink the feature.

the roadblock imo is more managing #1, #2 and the new feature and how to store it.

lpalgarvio’s picture

lpalgarvio CreditAttribution: lpalgarvio commented

to complement it, add a checkbox to the fieldset in which the user opts or not by overriding content type and field defaults. this would optionally cover all cases (#1, #2, #3 and #4), with the default behavior covering only #1 and #2.

if the permission is added, it would apply also to the checkbox.

On for role:
- show the input defaults field set
- show the selection box for node, comment and block inside the fieldset
- show the "override all defaults" checkbox for node, comment and block inside the fieldset (bellow the corresponding selection box

Off for role:
- show nothing

if the permission is added or not, it won't pose any security risk. the input formats already have permissions tied to them; it's only a matter of giving the user the ability to set their default input format - a usability feature.

the advantage of a permission vs a global checkbox to allow user defaults or have always the feature on, is that you can choose which roles can see it - this could simplify things for users who don't know much about drupal. that's almost like disabling the input format selection box for the node form per role...

lpalgarvio’s picture

lpalgarvio CreditAttribution: lpalgarvio commented

bump

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
CreditAttribution: greggles commented

I think the user provided value would trump all others. I don't see why anything else could make sense.

I agree it should require a permission "set own default input filter" so that not all users could use it all the time.

dragonwize’s picture

dragonwize CreditAttribution: dragonwize commented

But what happens when that default format is not available, we then have to go through our normal workflow of finding the best available default format. If you default is not available in many places then your default does little good. Since it is only one global default for everything and that format is not always available or even if it is people will then want personal defaults at every other level (entity, field, etc.).

I think for a simple site it might work ok but I see it snowballing into a real nightmare for any other site.

doublejosh’s picture

doublejosh CreditAttribution: doublejosh commented

This would sure be a lovely addition.
There is also the Preferred Format module to draw from, which allows a preference by node type.
Oh and Remember Filter, which seems a little dangerous to me.

dragonwize’s picture

dragonwize CreditAttribution: dragonwize commented
Issue summary: View changes
Status: Postponed (maintainer needs more info) » Closed (won't fix)

6.x is now unsupported.