Let me explain my situation first. I have two Drupal roles of importance on a site I am working on: 1) Admins 2) anonymous users. I have set up two input formats, 1) XHTML - Administrators and 2) XHTML - Basic Users. I have successfully installed the TinyMCE library, and have set up and have bound both input formats mentioned above to the TinyMCE library, and configured the editor settings for each binding.

The general goal is that the "XHTML - Administrators"/"TinyMCE" will be used by the role "Admins", and has more advanced features turned on in the editor. Likewise, the "XHTML - Basic Users"/"TinyMCE" binding will be used by the role "anonymous users" and will have less advanced features turned on in the editor.

I have the default input format for all content types set to "XHTML - Basic Users". I also have installed a module to assign default input format by role.

I am having a problem with the following use case:

An administrator logs in to edit a node. The module I installed that assigns input format by role changes the input format to "XHTML - Administrators" for him, as desired, as he has access to the advanced editor controls. He then saves his work *without* changing the input format back to "XHTML - Basic".

A visitor comes along, and decides to try and edit the same page the admin just worked on. He clicks on edit, but can't edit the page because it was saved in the "XHTML - Administrators" input format. The input format filter module also cannot change the input format for him because his role doesn't have access to the input format "XHTML - Administrators" (and I do not want him to have access to that input format anyway).

With the old TinyMCE module, I was able to have one input format that ALL users had access to, and then I had separate editor profiles that were each bound to a specific role.

How do I emulate that behavior in this case using the wysiwyg API? As you can see from the above use case, the whole idea of binding input foramts to editor settings does not always produce the same functionality.

Comments

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

The entire idea of the abandoned TinyMCE module (and others) was wrong. You cannot use different editor functionality on the same input format. The input format is there to restrict the possible markup.

If your input format would allow anything an admin shall be able to do, then your anonymous users will be able to insert the very same content. That is a major security issue, because people often forget that users do not need to use an editor at all.

Given your use-case, I would recommend to disallow the usage of the administrative input format on contents that should be editable by anonymous users. You would use http://drupal.org/project/better_formats for this purpose.

I think this deserves a new handbook page.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Status: Active » Closed (won't fix)
sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

Supposed handbook page is here: http://drupal.org/node/417160

dan.thompson’s picture

dan.thompson CreditAttribution: dan.thompson commented

I understand where you are coming from with regards to security. However, from a usability standpoint your suggestion would not work. If I disable the administrative input format on nodes that should be editable by anonymous users, because of the way the wysiwyg api module binds a single set of editor settings to a single input format, the administrative editor would not be usable on content that anonymous users need to edit.

Perhaps there is something I am missing here. I will take a more detailed look at the better formats module.

In any case, we really do need some documentation out there that tells people how to securely assign editor settings based upon role. It is either currently not clear or not available.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

The real and underlying question is: What are you actually trying to do? Why do there have to be "two different editors" as you describe it? Where is the actual difference to anonymous users?

To get to an actual solution, that is the required information about your use-case here. All I have understood from your original post is that you have two input formats; but I do not know what the difference between them is.

Would you be open to document the gained knowledge in the new handbook page after walking through this?

troybthompson’s picture

troybthompson CreditAttribution: troybthompson commented

I found this thread by looking for the same functionality. In my case, it's not a security thing, but a UI thing. Editors on the site have been trained and know HTML enough to see more advanced buttons, but I want to keep things simpler for the public and just show bold, italic, etc.

I don't know what the original poster is trying to achieve, but in my case, I'd even be fine with a default set of buttons and an advanced set of buttons that could be chosen by the user, but the "input format" would be the same and would have whatever restrictions and filtering were desired universally.

I would also love to be able to turn off target, etc fields in the link dialog for basic users but I think that's a tinymce issue.

highermath’s picture

highermath CreditAttribution: highermath commented

The bottom line is that any piece of content can only have one filter format at a time. it it starts out in the non-privileged format and get switched to a privileged format, then once it is saved the unprivileged user can't edit it. Any use case that lets them do so would require a privilege escalation.

For example, if you do not permit unprivileged users to insert links, and a privileged user comes along and adds one, if the unprivileged user could edit the content they would be able to change that link, possibly to something undesirable.

While it might be possible to have a system where certain elements in a given piece of content were restricted, that hasn't, afaik, been invented for Drupal, yet.

dan.thompson’s picture

dan.thompson CreditAttribution: dan.thompson commented

Sorry for not replying earlier, been busy.

I am trying to do exactly what troybthompson described. Have one toolbar that is fairly limited that normal users see, and have another that is more advanced that admins see. Problem occurs when an admin saves a node in an input format that regular users can't use.

One solution is to just remind admins to always save in the lower input format. Another would possibly be to write a module that allows people to switch to a given input format for editing purposes, but not to actually save with the node set to that input format.

TommyChris’s picture

TommyChris
Primary language Hungarian
Location Budapest
CreditAttribution: TommyChris commented

My solution is to create a rule action, which sets the node input format to xHTML basic after the save, if it is not Plain text.

TommyChris’s picture

TommyChris
Primary language Hungarian
Location Budapest
CreditAttribution: TommyChris commented

But i get this error: "The integrity check failed with the following error message: "The selected data property doesn't support writing.""

TommyChris’s picture

TommyChris
Primary language Hungarian
Location Budapest
CreditAttribution: TommyChris commented

I wrote a jQuery handler in a custom module, that fires when a form is submitted. It changes the input type selection to the xHTML basic.