Jump to:
| Project: | OpenWYSIWYG Editor |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Ref. this discussion here:
"Which editor (if any) do you use for your Drupal site(s)"
http://groups.drupal.org/node/6558#comment-63197
My own opinion:
**Because of it simplicity, lightweight and independence, this editor has the potential of taking the Drupal world by storm.**
I think that it can be tactically smart to keep in mind that it is the administrators who decide which WYSIWYG editor to use. Hence, this module should be the administrators' best friend :-)
Therefore, the flexibility that this module brings to administering not only one site, but multiple sites, (sensible defaults that minimize manual admin tasks, etc.) is relevant.
Look at the display options provided by the other modules.
I think it would be smart if this module became the first/only module to provide real flexibility and convenience in this respect.
These functions are currently scattered across the various existing WYSIWYG editors, and to my knowledge, not a single one of them gives sufficient or "near complete" flexibility. With such a complex and flexible tool as a CMS, this is actually needed.
**I am personally normally in need of having the following options:**
- option to specify that the default state should be OFF (optional, but need that option), with specified exeptions to that rule. See below:
- specify URLs/path patterns with wildcards such as "node/*/edit" for visibility (where the editor should be enabled, and also IF possible to enable there, if users should be able to set its default state to something else than the admin setting, and if so, that should be a permission setting so that only selected roles get that option on their user page. Those options on the user page should ideally be placed in their own tab, not cluttering the main user settings.
- specify particular text area names for which the editor should have default state on or off, and which text areas to disallow the editor.
- Flexibility on the same page, same URL: it should be possible to specify the following for the node/*/edit and node/*/new pages: if the editor should be allowed for the log message area, and if so, what its default state should be, and also if the user role should be allowed to override the default state for that text area. Further on the same page is a body text area, and depending on the CCK settings, there might be more than one text area (CCK field) in addition to the body text. The same options goes for each text area on that page, they should have their own visibility settings, so that some are turning the editor on, others off by default, others disallowing it.
**The editor should also be functioning when used in multiple instances with various states on the same page...**
Further:
**Visibility permission setting to facilitate delegation.**
A permission setting specifically for managing the visibility would be smart to add, so that an admin can delegate the visibility to content managers or the like, without having to give them full control over the module. That would give it an edge where an administrator (team) deals with very many drupal sites, and hence want to delegate parts of the work without risk.
This particular suggestion is mostly related to the effects of Drupal's success: More and more companies will use multiple Drupal installations within their firm, and more administrators will have responsibility over an increasing number of sites, with an increasing number of teams they can delegate tasks to. So it is perhaps mostly relevant for the big ones, but not only, and I think that if this editor becomes the favorite pick on larger installations, that would add significant weight and attention to it, which helps spread its usage and secure further developments.
Lets have a discussion about these things here first.
Depending on the feedback on this, we might choose to break this feature request into multiple issues.
Chime in, please :-)
Comments
#1
Some of your required has supported by this openWYSIWYG module. Go to the "Visibility" tab.
Please check a make a feature request for 6.x version if required.
I won't add new feature for 5.x because I spend my time for Drupal 6.x now.
#2
I will check against the 6.x version - keeping this open just a bit longer.