Here's a patch to filter.module that allows users to set their preferred input format, when multiple formats are available. A selection of available formats is added to the user-account editing page. The user's selection is persistent and is used to initialize the input-format selector on the node-editing pages. This patch requires an addition of an 'input_format' field to the {users} table:

   alter table users add input_format int(4) NOT NULL default '0';

I'm not 100% sure I did this correctly. I'm no PHP coder. Anyway, it seems to work.

Patch file is attached.

Enjoy.

CommentFileSizeAuthor
filter.module_9.patch1.61 KBjchris
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

moshe weitzman’s picture

i like the convenience of this ... for this sort of pref, i prefer that we simply remember what the user chose as an input format the last time. that the most natural way to use this. who wants to go totheir profile page? i propose to do away with the UI on the profile form but i don't feel strongly about that.

jchris’s picture

i like the convenience of this ... for this sort of pref, i prefer that we simply remember what the user chose as an input format the last time. that the most natural way to use this. who wants to go totheir profile page? i propose to do away with the UI on the profile form but i don't feel strongly about that.

I agree, just remembering the previous selection would be nice though perhaps harder to implement (for me anyway). However, keeping the profile-page UI as well might allow for the extension of having per-node-type input-format preferences as well (e.g. wiki for blog, html for book) though there may be no real demand for that. Of course, I never let a lack of demand deter me. :-)

killes@www.drop.org’s picture

Version: 4.6.1 » x.y.z
Status: Needs review » Needs work

I am with Moshe, please add this to a session variable. There are already lots of settings on the user profiles that users do not care about.

moshe weitzman’s picture

to clarify, i recommend a persistant hidden user preference, not a session variable.

moshe weitzman’s picture

subscription.module has such code for its 'subscribe' chechbox on the node form.

Steve Simms’s picture

I've just created a module that remembers the last input filter used by each user without requiring an update to core. I've created a project for it (http://drupal.org/node/47983), but I don't have a CVS account yet. Once that gets created, I'll upload the code for perusal.

It operates without needing any settings, so there's no additional clutter to worry about.

ñull’s picture

If the last choice of the user is remembered, could we finally get rid of the enforced default that is hindering us? Can the default not just be the first filter?

Steve Simms’s picture

If the last choice of the user is remembered, could we finally get rid of the enforced default that is hindering us?

Not based on my module. It only works for node creation/editing, not things like comments or other cases that don't use the nodeapi hooks.

LAsan’s picture

Version: x.y.z » 7.x-dev

Feature request, moving to cvs.

sun’s picture

Title: Per-User Input-Format Preferences » Per-user text format preference
Version: 7.x-dev » 8.x-dev
lennart’s picture

That would be useful, indeed.

mlncn’s picture

Issue tags: +SettingsAPI

+1 (and also tagging as a very interesting possible edge/use case for a theoretical SettingsAPI...)

Wim Leers’s picture

Status: Needs work » Closed (won't fix)

This is a 1% feature. Plus, in Drupal 8, authenticated and anonymous users won't see a text format selector at all, because they only have access to one text format by default, in which case the selector is removed.

sun’s picture

Status: Closed (won't fix) » Active
Issue tags: -SettingsAPI

@Wim Leers: That only applies to Standard profile's default configuration, sans any customizations and/or real world use-case. Once you have multiple user roles with varying levels of (additional) privileges, real world configurations look vastly different.


An alternative approach to the suggestions in here might be to resolve this in JS only (localStorage), though I'm not sure.

Wim Leers’s picture

That was my first thought also: localStorage.

jhedstrom’s picture

Version: 8.0.x-dev » 8.1.x-dev
Status: Active » Postponed (maintainer needs more info)
Issue tags: +Needs issue summary update

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Postponed (maintainer needs more info) » Closed (outdated)

Closing as outdated as an IS update was requested 7 years ago with no followup. If still a valid feature request please reopen updating the issue summary.

Thanks!