The TinyMCE WYSIWYG editor is a critical module for many sites. Yet, it remains difficult for non-technical users to configure. This module would jumpstart that process by automating the process of setting up a flexible, secure starting configuration.

The TinyMCE Defaults module will:

1. Give the authenticated user role rights to access TinyMCE (check/add values in the permissions table)
2. Create a default profile for TinyMCE named "default" and allow the authenticated user role to use this profile (tinymce_role table)
3. Make filtered html the default input filter, and adjust the tags permitted in this filter (variables table) --

Projected Use:

1. A site user installs TinyMCE.
2. A site user then installs the TinyMCE Defaults module, which delivers a secure configuration of the module with a mouse click.

Ideally, the module will create a new link within the "Site Configuration" options: Set TinyMCE defaults. This page will have a single button: Create/Restore TinyMCE defaults.

Obviously, this module will have a dependency on TinyMCE.

I'm attaching a zip file with three sql dumps -- these dumps are databases. The first is a core drupal install; the second is a database after TinyMCE has been installed; the third is the db after TinyMCE has been configured. The settings for the TinyMCE module can be pulled by doing a diff on the second and third database dumps. Once a student claims this task, I'd be glad to go through the process of configuring TinyMCE via the web UI with them if needed.

Deliverables/Tasks:

1. Verify that the tags included for the input filter are okay. I used this page as a resource, but it's always good to check. -- for the record, the tags used are:

<a> <b> <blockquote> <br> <caption> <center> <code> <col> <colgroup> <dd> <del> <div> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr> <i> <img> <li> <ol> <p> <span> <strong> <sub> <sup> <table> <tbody> <td> <tfoot> <th> <thead> <tr> <u> <ul> <tr>

2. As part of the development process, get feedback from people within the TinyMCE group on g.d.o: http://groups.drupal.org/tinymce-development -- this feedback will take the form of posting an announcement about the module within the group

3. Write the module for Drupal 5.x.

4. Once this module is written for 5.x, we can create a follow up task to port it to 6.x

The primary contact for this module will be Bill Fitzgerald/bonobo

CommentFileSizeAuthor
tiny.zip64.66 KBbonobo

Comments

aclight’s picture

aclight commented
Status: Active » Needs work

A few comments on this proposal:

1. We try to avoid tasks where students must create a module, since the module also needs a maintainer and someone with CVS access. If the student isn't able or willing to do that, would you be willing to be the module maintainer?

2. I'm not sure about this, but it seems to me that having a module that itself modifies access permission settings is not a good idea. I can't think of another module that does such things.

Other than my concern in #2, I think this looks like a well written and interesting proposal.

bonobo’s picture

bonobo commented

RE: 1 -- yes, we would maintain this.

RE: 2 -- The only access privilege this would change is that it would assign the rights to access TinyMCE to authenticated users. This doesn't pose any security risk.

There are a few people who have reported issues with configuring TinyMCE in the past -- this module would turn a long, somewhat technical task with multiple steps into a simple process completed with a few mouseclicks -- a big usability win, IMO.

This could also be a starting point for people looking to maintain configs over multiple installs. Using this module as a starting point, you could configure standard TinyMCE settings over multiple sites quickly, with minimal hassle.

I'll leave the ticket open for a bit longer and then copy this over to the Google issue tracker.

wmostrey’s picture

wmostrey commented
Status: Needs work » Needs review

I think this is a great idea. There actually are modules that do a similar thing: put test data in the database. From a technical point of view, this module would do not much other: inject pre-defined data in tables.

There are two important things to consider: security, and loss of user data. Make sure the module only adds records, and not updates them. You don't want a user to enable this module after having used TinyMCE for a long time and to find his old settings altered.

I think this is good to go.

aclight’s picture

aclight commented
Status: Needs review » Reviewed & tested by the community

Ok, sounds good to me.

@bonobo: Go ahead and create an official google task and a corresponding d.o issue in the appropriate queue. Once you've done that please post a link to both of those as a comment to this issue, and I'll make sure both of those are configured properly and you'll be all set. Thanks for your work on this idea--it should be useful to lots of people.

bonobo’s picture

bonobo commented
Component: Task idea » GHOP Task
Status: Reviewed & tested by the community » Active

Link to issue on Google: http://code.google.com/p/google-highly-open-participation-drupal/issues/...

Link to issue on TinyMCE issue queue: http://drupal.org/node/203173

aclight’s picture

aclight commented
Component: GHOP Task » Task idea
Status: Active » Closed (fixed)

Since this issue has been created, i'm closing this issue.