Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The Allow users to choose default settings does not currently work.
Because of the logic the wysiwyg_status field on the user form never displays.
$profile is always an empty object.
<?php
$profile = new stdClass;
if (isset($profile->settings['user_choose']) && $profile->settings['user_choose']) {
$form['wysiwyg'] = array(
'#type' => 'fieldset',
'#title' => t('Wysiwyg Editor settings'),
'#weight' => 10,
'#collapsible' => TRUE,
'#collapsed' => TRUE,
);
$form['wysiwyg']['wysiwyg_status'] = array(
'#type' => 'checkbox',
'#title' => t('Enable editor by default'),
'#default_value' => isset($user->wysiwyg_status) ? $user->wysiwyg_status : (isset($profile->settings['default']) ? $profile->settings['default'] : FALSE),
'#return_value' => 1,
'#description' => t('If enabled, rich-text editing is enabled by default in textarea fields.'),
);
return array('wysiwyg' => $form);
}
?>
Comment | File | Size | Author |
---|---|---|---|
#37 | wysiwyg-DRUPAL-6--2.user-pref.37.patch | 5.35 KB | sun |
#36 | wysiwyg-HEAD.user-pref.36.patch | 8.16 KB | sun |
#35 | wysiwyg-HEAD.user-pref.35.patch | 7.28 KB | TwoD |
#33 | wysiwyg-DRUPAL-6--2.user-pref.33.patch | 6.75 KB | TwoD |
#31 | wysiwyg-DRUPAL-6--2.user-pref.31.patch | 7.21 KB | sun |
Comments
Comment #1
markus_petrux CreditAttribution: markus_petrux commentedAny idea on how should it be implemented? Would it be fine to using "data" in user records? Different storage method?
Comment #2
Andrew Schulman CreditAttribution: Andrew Schulman commentedsubscribe
Comment #3
Agileware CreditAttribution: Agileware commentedIt should be fine to use data to store the info or do it the way it is currently.
The problem is that no wysiwyg profiles are loaded into the $profile variable before it checks the user_choose setting.
Another problem is that this would provide a single setting but there can be multiple wysiwyg profiles with different user_choose settings.
Here is a quick patch that should resolve this, giving them a checkbox for each input filter they have access to.
I haven't really had time to test it but that's the sort of thing we need.
Comment #4
TwoDThanks for the patch!
I've added a period to the end of #description and changed the #default_value handling a bit.
If an editor profile didn't have user_choose when the user made their choice, but it does now, the profile's default state will be used until it is overridden.
Comment #5
j_mcc CreditAttribution: j_mcc commentedAny chance of seeing this added to a new update soon, or at least a dev release?
Comment #6
TwoDThis is marked as "Needs review", so if someone is willing to test the patch and confirm that it works (and is a practical solution, at least until #322433: Replace default editor status option(s) with intelligent logic gets fixed), we can get this rolled into -dev.
Comment #7
hankp98072- CreditAttribution: hankp98072- commentedsubscribe
Comment #8
mstef CreditAttribution: mstef commentedworks!
Comment #9
mathieu CreditAttribution: mathieu commentedThanks for the patch - works for me too.
Comment #10
mgriego CreditAttribution: mgriego commentedWorks for me as well. Looking forward to seeing this added into a release soon.
Comment #11
gbowman CreditAttribution: gbowman commentedThis worked for me, it didn't do what I expected it to do but allowed me to achieve what I wanted!
Comment #12
TwoD@gbowman, what did you expect it to do? If I learn what users expect, maybe I can create patches that meet those expectations better. ;)
Comment #13
gbowman CreditAttribution: gbowman commentedI'm not sure now, been a while since I wrote that. I think I was looking for it to allow me to assign an editor to particular users (namely Anonymous). I think originally I was looking to Disable rich-text for guests to make the comments form simpler.
Thinking about it though the way it is set now seems most logical... simple text box as default and a wysiwyg editor as default for my account.
Comment #14
colanSubscribing.
Comment #15
hanoiisubscribe
Comment #16
hanoiiapplied the patched and worked fine, +1 to be added to -dev
Comment #17
gr33nman CreditAttribution: gr33nman commentedThis patch worked. It also fixed a white screen of death I was getting when I tried to /user/1/edit after enabling wysiwyg in Drupal 6.19.
This does not do what I expected it to do: allow a user to select via radio-button the preferred wysiwyg editor to use as default in the body textarea when creating a new story/page. I have three available input formats: Filtered html (no wysiwyg editor applied), FCK_Editor_Full (for full FCK), and TinyMCE_Full (obvious). All three still show up and Filtered html is still selected as default when I create a new story or page. I would like there to be a filtered default for authenticated comments that has no editor, but users with editor and author privileges should be able to select their preferred wysiwyg.
I guess I'm not exactly sure what this patch changes, other than to put selectable wysiwyg checkboxes in the user my account edit area.
Comment #18
gr33nman CreditAttribution: gr33nman commentedComment #19
TwoD@gr33nman, the patch is meant to allow users to choose whether an editor profile for a format is enabled by default or not - when that format is switched to during editing, not which format is selected by default. Use the Better Formats module for that.
Sun and I briefly discussed this topic a while ago and we want to implement it a different way later. Though since this patch does make the checkbox in the profile settings do something useful for users who don't want editors by default, I think we should put it in now.
Comment #20
gr33nman CreditAttribution: gr33nman commentedOkay - thank you for the explanation and the suggestions. I greatly appreciate it.
Comment #21
mstef CreditAttribution: mstef commentedHasn't been committed to 2.2?
Comment #22
MichelleThanks for the patch. This is critical for me since WYSIWYG doesn't work in Panels and even clicking the option to turn it off doesn't make the text area come back. I realize that this is moving in another direction but it seems to me that this patch is needed in the mean time. It works fine. Why not commit it?
Michelle
Comment #23
sunWhat's this @todo? Obsolete?
We can directly use the return value of wysiwyg_profile_load_all() instead of assigning the $profiles variable.
The D7 patch will have to look slightly different, and will also need a horrible upgrade path for {users}.data records... :(
Frankly, I'd almost prefer - if we really have to do this right now - to create a new {wysiwyg_user} db table, two columns uid and format, no primary key; deleting and re-inserting all rows per uid upon user account update.
The first two conditions are !empty().
The last condition should be isset().
Let's use !empty() here.
Let's drop the description and make the title slightly more descriptive; i.e.:
"Text formats enabled for rich-text editing"
Powered by Dreditor.
Comment #24
TwoDI did not have time to test an upgrade so I've not looked into a possible upgrade path yet.
Added an extra parameter to wysiwyg_user_get_status() so its possible to get the status for someone other than the logged in user, but in D6 filter_formats() will still only present the formats available for the logged in user instead of those available for another user when editing their account.
Please correct me if the user of filter_formats() in D7 is a security risk. (If a user has permissions to edit another user, I don't think it'd be dangerous to show them which formats that user can access, even if the editing user can't access them. They'd need special permissions to do something with those formats anyway.)
This took longer than I anticipated and I have to rush this and go to work now so I might have missed something.
Comment #25
sunThanks! Let's focus on D6 for now, and forward-port later on.
mmm, we should keep the hook_user() implementation, because alter hooks are not intended to add things, only to alter already existing things.
btw, I'd be fine with dropping that fieldset, too.
Let's leave the addition of $account for later... not needed right now (and as you mentioned, not really possible prior to D7).
At least in D6, all properties contained in $edit, resp. in the submitted form values, are automatically taken over into $user->data, so I don't think that this presave implementation is necessary.
All serialized data in {users}.data is automatically "unpacked" onto the $account object, so the previous patch was correct; the account settings are contained in $user->wysiwyg_status.
Powered by Dreditor.
Comment #26
TwoDThe DRUPAL-6--2 patch is screwed up, it shouldn't have those changes at all. I'll re-diff that ASAP.
Comment #27
TwoDLet's try this one instead. I wish I had a patch viewer, and maybe even Dreditor on my phone... ;)
Comment #28
sunSeems like we're still missing the {wysiwyg_user} table?
Minor: This comment reads a bit odd, let's re-phrase it.
Powered by Dreditor.
Comment #29
TwoD{wysiwyg_user}? Didn't we talk about implementing that later and fixing what is there first?
Comment #30
sunGiven that D7 uses a new text format identifier format, and we'll have to maintain these user preferences somehow, we should really store it in an own, custom database table. Should actually be 5 minutes of work...
Comment #31
sunLike this?
Comment #32
TwoDStill on my phone so can't do a proper review until morning...
If table exists -> create it again?
The odd comment is still there, how about simply "// Only show formats that have user_choose."?
I like the "lazy-loading" of statuses! =)
Comment #33
TwoDSome minor fixes and we're good to go!
Added missing "!".
Fixed function call and changed comment to "// Only show profiles that have user_choose enabled.", the user access part happens in filter_formats() so not relevant here.
The table gets created both on clean install and update, populates and gets destroyed on uninstall. Settings now persist when set for both the current user and other users (though as noted earlier, current user can only see formats they have access to when editing other users).
Powered by Dreditor.
Comment #34
sunThanks for reporting, reviewing, and testing! Committed to D6.
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.
Now we need to quickly forward-port this patch to D7, as we need to release 7.x-1.0 this week.
Comment #35
TwoDD7 port.
Please remove the drupal_set_message lines... generated patch from my (otherwise identical) debug branch...
Comment #36
sunComment #37
sunCommitted to HEAD.
Follow-up fixes for D6. Do we need to provide db updates for the 24h time-frame?
Comment #38
TwoDAh, nice changes. I still have some reading to do over at http://drupal.org/update/modules/6/7
Patch looks good and works perfectly!
Crosspost... Second patch is good too, don't think it needs an update.
Comment #39
sunAlright, also committed the follow-up patch for D6.
Marking needs work, because this functionality can be tested through automated unit tests (and we currently have none).
Comment #40
mstef CreditAttribution: mstef commentedWhat's the status here, exactly? I know this didn't make it into 2.2 - but it's been committed to 6.x dev, right?
Comment #41
TwoDYes, this is all committed to 6.x-2.x-dev and 7.x-2.0.
All that's left are the automated tests.
Comment #42
sunLet's deal with automated unit tests later/elsewhere. This is probably one of the least important things to test. :P