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.
| Comment | File | Size | Author |
|---|---|---|---|
| filter.module_9.patch | 1.61 KB | jchris |
Comments
Comment #1
moshe weitzman commentedi 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.
Comment #2
jchris commentedi 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. :-)
Comment #3
killes@www.drop.org commentedI 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.
Comment #4
moshe weitzman commentedto clarify, i recommend a persistant hidden user preference, not a session variable.
Comment #5
moshe weitzman commentedsubscription.module has such code for its 'subscribe' chechbox on the node form.
Comment #6
Steve Simms commentedI'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.
Comment #7
ñull commentedIf 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?
Comment #8
Steve Simms commentedIf 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.
Comment #9
LAsan commentedFeature request, moving to cvs.
Comment #10
sunComment #11
lennart commentedThat would be useful, indeed.
Comment #12
mlncn commented+1 (and also tagging as a very interesting possible edge/use case for a theoretical SettingsAPI...)
Comment #13
wim leersThis 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.
Comment #14
sun@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.
Comment #15
wim leersThat was my first thought also:
localStorage.Comment #16
jhedstromComment #31
smustgrave commentedClosing 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!