Return of 4.7 features

yes. the profile per role will be available on the Access Control page, this makes tinymce follow Drupal core module setting (same as imce.module). i still find the simple way to enable the "disable/enable rich text" link. also the "customize button" will be available. any features that already included on imce.module will not duplicate on tinymce. try imce.

I find that there's a huge gap between compact and full...

but even more problematic is that there's no way to switch tinyMCE off and on in the node...

(however that is buggy in IE 7 for Drupal 4.7.4 : when switching from rich view to drupal view I often loose my cursor...!)

oupsy... I meant a huge gap between compact and simple

As it is, simple mode gives you only : underline, bold, italic, undo and lists... that's it.

No blockquote, no links...

The 5.0 version of this module is a major step backwards; not only does it strip out features numerous sites depended on, it chokes on scenarios that the previous version handled without any problems.

For now, I suggest that folks in need of TinyMCE do what I'm doing: use the 4.7 version, with the patch in http://drupal.org/node/100864. It actually works.

I don't want to be part of a pile-on, but I agree with the sentiments here.

I think it may be correct to have profiles by role on the access control page. It has always seemed a bit one-off to have this setting on the TinyMCE settings page - especially since you ALSO need to visit the access control page to switch it on. I agree that the profiles system was needlessly complex, and benefits from a revamp.

But these hard-coded profiles are very problematic. +1 on the sentiment that "compact" and "simple" are way too different. As it stands, you can not re-enable necessary functionality (e.g. format selections) without introducing other functionality (e.g. tables), which will be stripped out by the input format. This must be made configurable again!

Drupal-Id - I recognize you're in a difficult spot right now, with feisty outrage after all your hard work. At the same time, there's no way we can use this version of the module as an upgrade path from 4.7. I prefer to avoid using the patch, but will have to do this if you don't plan on adding this functionality.

Can you let us know your plans on these features so we know which way to go?

I would also like to know the future direction of this module. 5.0 simply is a step backwards.

I agree with boris' sentimentality, provide an upgrade path using different releases.

That way people who are upgrading from 4.7 access to the 5.0 version of that module. When the 2.x branch becomes usable / possible for those users to migrate in a future release, that's cool. New users will most likely choose the 2.x branch, right?

I agree, but the question is work effort.

We're gridlocked. The present 5.0 version is "broken", upgrading with a rogue patch creates a totally-unmaintained fork, and without a clear statement of intention by the module's maintainer, it's not clear which effort to push forward. And while I hate go get into finger-pointing, the present maintainer has not made one bugfix or commit to this codebase since adopting it, which means it now has a 9-page issue queue. It is disappointing to see one of the most popular modules fall into this state.

At some point, the maintainer for this module created a separate project at http://drupal.org/project/tinymce_plus , which I presume was intended to branch with the code we're now questioning. It's not clear where he intends to place his work efforts (which is why I asked). However, maintaining 1 WYSIWYG editor is hard, and I doubt that doubling the work effort will make this problem go away.

Hopefully, someone who is more in touch with the Drupal community can adopt this project or a fork. It's important enough that our company might be interested in participating in bounty, if that's what it takes.

Wow, I was really surprised by TinyMCE 5.0. Afraid I can't do much but lend my voice to the chorus, but the implementation is really broken. We need to have the ability to customize TinyMCE as we were able to with 4.7. Moreover, TinyMCE 5.0 just doesn't show up! Broken! Time to try again, I'm afraid.

Else I think will be great to get back nice theme_tinymce_theme function which give ability customize which theme will be used with different textareas.
Thanks!

Sorry my english I mean "also" )

+1 for 5.0-1.0 branch being an upgrade version of the 4.7 branch and the 5.0-2.0 version being the new 5.0 branch that is being coded from the ground up.

If the module maintainer is unwilling to go down this path would it be proper for the community to outvote him and change this of the legacy (4.7) code to be used to launch a new project that continues that line?

WOW! This same discussion is happening on the development list as well. I just posted the following response there. AFAICT, this movement seems to be driven by users who do not want to edit the theme .js files. It's hard not to sound condescending when I saying this, but are these really the people that should decide the direction of module? Is anyone who is familiar with the Drupal and TinyMCE frameworks in favor of reverting this module to the patched 4.7 code?

For those of you who missed it, I did write a hack that enables different TinyMCE themes to be displayed in different roles. That hack could be developed into a patch with a GUI that restores that feature, but I TRULY believe that bypassing the theme.js files is the WRONG direction.

FORWARD FROM DEVELOPMENT LIST...

Is everyone is aware that drupal-id was maintaining TinyMCE plus before taking over the TinyMCE module?

Is the suggestion to move drupal-id's current module back to TinyMCE plus and revert TinyMCE to the patched version of 4.7?

It seems like the project was already forked once and making drupal-id the maintainer of the primary module was an attempt to merge these efforts.

Learning to edit the theme .js files may push less technical users beyond their comfort zone, but it is really the TinyMCE way of doing things. There are 3 very usable themes included for people who just
can't edit comma separated lists. For those who want to learn to modify their .js themes, there is community that is much bigger than just the TinyMCE module users who help support this. Drupal users make up a small part of TinyMCE users.

If you really can't use TinyMCE without a GUI toolbar designer, wouldn't the proper place to do that be as a stand alone tool that output theme.js files that any TinyMCE user could use? Write that in
javascript and release it as a TinyMCE tool. Users could design their toolbars and save that .js file to their /modules/tinymce/includes/themes/. The admin interface for the TinyMCE module would simply allow users to link their theme .js files with their roles (a Drupal specific feature).

Correct me if I'm wrong, but didn't the 4.7 (and patched 5) button configuration bypass the .js theme files? Shouldn't Drupal development respect the way other frameworks want to handle their
configuration?

I have neither been involved with Drupal long enough nor been active enough to deserve a vote, but if I'd had one it would be to "stay the course" drupal-id started regardless of who the maintainer is.

Actually, if you do a little digging, you'll find that the folks who are "vocal" on this issue are not people who don't know how to edit javascript files. Rather, they're experienced developers and long-time community members who are aware of the drawbacks to what you propose.

File-editing will not work in a multi-site environment. Nor is it a responsible operating practice to deliver modified code to a client of any size. Changes to the distributed source, no matter how small, represent a "fork", and create maintenance dependencies and upgrade costs. Last, delivering a Drupal implementation that can't be further configured or maintained by its owner is not friendly either.

These arguments would be moot if the ability to manage TinyMCE from within Drupal had never existed. But this feature did exist, and there is no clarity on whether the feature regression will be addressed.

If you take the time to read the discussion, you'll find that people weren't inherently opposed to these changes, but they were concerned by the lack of a roadmap. And that concern has increased during the past 4 weeks of non-acknowledgment by the maintainer. Meanwhile, this module does not work for users familiar with maintaining 4.7 sites, and is fundamentally broken in other ways (e.g. by not working in IE).

Frankly, it's a dirty job to maintain a highly popular, end-user-centric module with many client-side issues. Nobody is racing forward to become a new maintainer. Sadly, all of this controversy increases the reluctance even further.

Is anyone who is familiar with the Drupal and TinyMCE frameworks in favor of reverting this module to the patched 4.7 code?

Yes.

I'll second that "well said" about #22. Handing over a site to a client and asking them to edit files instead of using the admin interface isn't a good idea.

I'm not in a position to be of any help, unfortunately, and it's sad to see that people that could help, like Steve McKenzie, has to give up. TinyMCE isn't just any module, it's the second most popular contrib module for Drupal! There has to be a way to make this go forward again, right?

Allie,

While I hadn't considered multisite issues modified theme .js files might cause, I have to take issue with the implication that I described the people requesting a rollback to the patched 4.7 module as "people who don't know how to edit javascript files". I didn't know enough about their motivations to say "they don't want to ask clients to edit a javascript file or deliver a project that requires a text editor to configure", but I never implied that these people are not capable of editing the file. My point has been the exact opposite... that editing these files isn't difficult. A GUI option would be great, but I think the 4.7 GUI limited functionality many 4.7 users didn't know TinyMCE even had. I want a solution that works with the TinyMCE framework.

I also disagree that modifying TinyMCE themes is an "irresponsible operating practice". This is Moxie documented way to configure TinyMCE and is supported by a very active community on Moxie's free support forum or through Movie's commercial support. Bypassing the TinyMCE framework limits the support options your clients have to the Drupal module maintainer and users. How is giving a client modified TinyMCE themes any different than custom Drupal theme work? The client can't alter the .css or page.tpl.php themselves?

Scafmac has contributed a patch to re-enable role based themes without the need to hack and hardcode variables.

The remaining feature missing from 4.7 seems to be a GUI for button selection. If generating or modifying .js theme files (working within the TinyMCE framework) is not going to work for users with multisite installs, unless bypassing the .js files is simply an option for multisite installs a fork seems inevitable as there are users (like me) who prefer to have full control over the TinyMCE configuration.

kreynen,

This argument is a red herring.

The fundamental issue at stake is the fact that features that were important and useful to the Drupal community were removed, with no further communication or clear plan of action from the maintainer. Recent commits do not suggest that this module is going in a positive direction, or that the maintainer is willing to engage in a dialog of any kind.

We are creating a separate ( hopefully temporary ) module here: http://drupal.org/project/moxie

Hi everybody,

First I like to say thank you to Kevin that already inform me if my email has problem, now my email works fine. What exactly happen is the MX record go to my other email server, but since I can receive email from CodeGear.com then I didn't notice that my email really has problem. Almost 3 weeks I was giving several Drupal trainings and finishing several Drupal website for my customers, that's why I just make very small update to tinymce.module (last update on Feb 1, 2007).

I already contact Steve McKenzie, Boris Mann and Kevin Reynen, so we hope that the tinymce.module issues will fix soon. As Steve McKenzie suggests then we will create 2 packages: DRUPAL-5--2-0and DRUPAL-5--1-0.

Regards,

Jonathan

bravo for moxie!