Posted by sun on December 31, 2008 at 5:10am
Jump to:
| Project: | Tiny Tiny MCE |
| Version: | 6.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
It would be great if you could point users to Wysiwyg API on the project page instead.
Comments
#1
I have to disagree with the title of above comment.
Please do not abandon this project.
TinytinyMCE is now very stable while Wysiwyg API is still a work in progress.
With Wysiwyg API there is still a number of problems such as getting IMCE (my favorite file uploader) working. The API for attaching these is still changing and getting internal plugins working such as all the spell checkers, media plugin etc. gzip compressor etc still has problems.
The enthusiasm and work being done on Wysiwyg API is great and if not already, it probably will become the Editor module of choice but it still needs to prove itself over time. Even when this occurs I believe that there is still a reason to have several modules that integrate the same editor to Drupal.
Having an editor as part of Drupal is something that many thousands of installations need. Over the time that I have been following this I have noticed that all sorts of installations have very special requirements which often only one or none of the modules meet. Having several modules available gives more chance that specific requirements can be met. If they can't be then met, I would expect tinytinyMCE to be easier for someone to then fork to their own special one off requirements.
While duplication is normally frowned on within the Drupal world, the importance of having a good integration of TinyMCE to drupal is such that this is worth maintaining both.
I do agree with there being a link to the Wysiwyg module but I would also expect that the links should be both ways.
I hope both of you keep up the good work
Ken
Ausvalue.com
#2
Thanks for the balanced reply, Ken.
I wrote this module because I could not get the TinyMCE module to work in D6 (and from the issues list quite a few other people couldn't either) - though I'm sure things have improved now. By request, I then developed a D5 version. It seems that quite a few people find the flexibility quite useful (even if it comes at the cost of a little "rawness"). However, I'm not in favour of duplication myself and would, in certain circumstances, be happy to stand aside.
I can see, Daniel, that you are a big contributor to Drupal and for this I am grateful for your labours. But if this is your way of saying "welcome to Drupal" I feel that your way of greeting relative newcomers falls short of the community spirit one expects from an Open Source endeavour. "Stop working on this and point people at MY project" without any further explanation comes over as, dare I say, a little arrogant.
So, please accord me the respect that is due to a fellow contributor and offer some explanation for your request. Some of the questions in my mind are:
- Does WYSIWYG have special status in the Drupal community - i.e. some form of official sanction?
- If so, how do we identify "official" modules?
- How and when do you propose to address the gaps in functionality referred to above?
- There are other Drupal modules which implement rich-text editors. Have you approached them with the same request? If not, please explain why you have singled out my project?
For now, it seems sensible to keep tinytinymce going as there seems to be a need for it (as well as a user base). I will be happy to include a link to your project once I have heard the rationale. Later on, it may well be appropriate to encourage users to switch but I don't think we have reached that point yet.
Steve
#3
Oww. Steve, I did not know that you are a (relative) new contributor, so I'm very sorry if my request sounded harsh to you!
Of course, your contributions are very appreciated and no one wants to stop you from continuing to participate in Drupal awesomeness! :)
So let me elaborate a bit more on the reasonings for my request: Drupal always lacked in terms of content-editing. Especially regarding client-side editors (aka. WYSIWYG). That is the reason why we have plenty of editor integration modules in contrib, from which almost all use a wrong method of integrating the editor into Drupal. The new Wysiwyg API not only centralizes the integration for all client-side editors and uses a proper method for integrating them into Drupal, but will also allow *all* Drupal modules to interact with *any* editor. On top of that, it allows to use more than one editor on the same page, which opens up a completely new content-editing experience. The project not only replaces all of the existing editor integration modules, but also strives to be moved into Drupal core as soon as possible. That's why I'm trying to get all developers of editor integration modules on board and join forces (as much as possible) to increase the pace.
If you haven't already, you should definitely try it out, get on board, contribute, and let Drupal rock some more. :)
#4
From my point of view, TinytinyMCE does exactly what I need at this moment in time. The new Wysiwyg API does not. So I am extremely grateful for TinytinyMCE's existence, regardless of if it uses the "proper" method for integrating or not...
#5
sun, I have to admit that to me your request seems very very strange (from any point of view). Not to comment the title itself... ;-)
Before Drupal 6 I've been using TinyMCE module, which became too complex and confused for my taste recently. There are many issues overlapping, but simply doesn't seem to be definitely resolved... As Drupal 6 introduced quite strange approach to node teaser and body splitting, which TinyMCE module can not preserve (or, handle good enough for my taste), I've decided to stay away from it (at least for now).
Next try was Wysiwyg module you are mentioning. I have to admit it looks very promissing, but for the moment results with it were more or less as with TinyMCE module (simply too complex, with many more or less important issues or details which didn't match my needs or expectations...). So, I've decided to try this module from time to time on my test site in the future, but definitely stay away from it on my production site (at least for Drupal 6).
By chance I've (fortunately) found TinyTinyMCE module a few months ago. It is maybe not perfect, but it almost fits my needs:
A perfect solution for me would be to have this module as it is, with:
This way, I would relatively simple perfectly set it for my needs:
Now, my blacklists are quite long, and from time to time TinyMCE surprises me on some (mainly admin) screens (for new modules and so...), where it may do quite some mess (in particular on some lists), if you don't notice it was turned on and there. And, it is not nice to have such a big textarea (with all those buttons covering 85% of it) on some simple webforms or so... And, I generally prefer to enter (or, edit) the node content manually, but it sometimes can be quite convenient to make initial steps with some wysiwyg editor (and, fine tune everything manually after).
But, as said, I've found this module (even without any improvements, as above) by far the most useful and convenient for my needs (among wysiwyg editors), so I really can't imagine it to be discontinued! So, Steve, thank you very very much for this module - and, continue your work on this nice module, please.
#6
I understand that every module in contrib is different. However, did also you think of what we could achieve by joining forces and concentrating on an approach that is known to be accepted by Drupal core someday (rather sooner than later)?
Wysiwyg API not only concentrates the entire effort, but will also prevent issues like this: #355933: Filter isn't inserted with TinyTinyMCE editor - i.e. all Drupal modules will have one API to interact with. You want to use a different editor for your blog or forum posts than for your stories or pages? Or switch the editor on the very same page? Wysiwyg API allows you to do so. You want a button to insert a link to a Drupal path of your site, or to insert an image you uploaded using Image or ImageField? Wysiwyg API will allow you to do so, regardless of the editor you use. If the modules you have installed provide an implementation, it simply does not matter which editor you are actually using.
Please note that I am not saying "you have to" (I couldn't anyway). I would just like to invite you to an effort that already attracted other maintainers (TinyMCE, NicEdit, Whizzywig - more to come), developers, and users. If you want to mark this issue "won't fix", then I'll say "Bummer. We could have used your skills to make it rock even more.", but be it.
#7
Thanks for the comment Luti - I see that sun has changed the title, perhaps as a result of your post! :-).
I tried out WYSIWYG API and it definitely worked very nicely out of the box. But the main shortcomings for me were:
- no integration with IMCE
- it only seems to apply the rich text editor to node bodies
- I wasn't able to sort out Drupal teaser breaks
Other features, which seem to be useful and important (to some):
- ability to directly modify the init script
- permissions to control use of the features
- ability to toggle editor on or off
- fine control over which text boxes use the editor
- choice of spellcheckers
Is it likely that wysiwyg api will be able to implement all of these? I suspect not as the primary aim has to be to provide a standardized integration of a variety of editors. The API can't possibly address every possible feature of every editor so the effort has to go into maintaining core features. This is great but I think there will always be site builders who want finer control over how their systems are implemented and need to get "under the skin".
So, I won't be abandoning this project just yet. There does seem to be value in both approaches.
Steve
#8
#287025: IMCE_Wysiwyg API bridge module (Patch works, but IMCE maintainer seems to be away until February 2009)
#319363: Rewrite editor plugin API (Teaser break and whatever plugin/button any Drupal module provides)
#313497: Allow configuration of advanced editor settings (Instead of a geeky init script, we make all editor options configurable, even those specific to a certain plugin)
The entire battle plan is published and steadily updated at http://groups.drupal.org/node/6492/summary
Wysiwyg API applies editors to input format enabled textareas only. That's the whole point of the story: No other textareas in Drupal were ever designed to accept HTML at all. Applying an editor to those textareas is just wrong. Additionally, you are able to assign no editor to the PHP code input format, which prevents the editor(s) from hi-jacking your PHP code. And of course, the user should not have to deal with this question at all.
However, it does apply to more textareas than the body. Specifically, all textareas that are input format enabled.
Likewise, Wysiwyg API does not need extra permissions, because input formats already have permissions and are assigned to certain roles only. It would not make sense to further separate the available buttons based on the user roles of a user, because the input filters in the input format decide on whether certain contents are allowed or supported. So, for example, if the input format allows an IMG tag, there would be no reason to hide the image editor button for certain roles only. The user could enter the IMG tag anyway.
I don't know why you listed the toggle feature - this should work with any issues (at least, it does for me for all editors, and there are no bug reports in the queue).
I am unsure what you mean with "choise of spellcheckers".
#9
You all (developers of this modules) obviously know what you are doing. Joining forces and exchanging ideas would sure benefit the WYSIWYG support in Drupal. I don't think anybody should abandon anything. But it just is obvious you all have the same idea, knowledge and want to reach the same goal.
;)
#10
Steve, thank you for the new version released, and for good news (your decision to continue with this module).
Sun, don't misunderstand me, please. You are on the right way on long term (the idea or the goal is right for sure), but we need working solutions right now (probably it will take years before you will have decently working stable version as you imagine now...).
So, the best would probably be to ask Steve politely to help you with his knowledge and experience (where he can contribute anyhow), but for sure to ask him (or even request...) to stop working on his project is for sure not nice (I don't want to be rude here...). Not to him and not to us, users of his module.
Probably he knew about your project also before reading your post, so he could abandon Tiny Tiny and join Wysiwyg, if he would like to, or? ;-)
And, even when you will have a working more or less final version of your module, probably there will be many of us who will still decide for a lightweight solution as Tiny Tiny MCE is. More simplicity simply brings certain limitations, but on the other hand less chances that something goes wrong (more code = bugs & more chances for some misconfiguration) and often takes less resources.
Just look at the TinyMCE project, which shall be even less complex than Wysiwyg - it was working for me pretty well before Drupal 6, but since I've upgraded, I simply can not find a version that would do the job for me well (as in my previous post, why I really like Tiny Tiny MCE...). There are too many issues which are never really fixed, certain things doesn't seem to be resolved ever and so on. It is simply too complex and recently never really in some final stage (finished) by my opinion.
In any case, I stay with Tiny Tiny MCE for quite some time for sure! :-) Hoping the maintenance (and maybe some development) will not stop, of course... ;-)
#11
It seems I horribly failed to express my request in a friendly and inviting way. :(
Nevertheless, I hope I was able to point out that you are invited to join forces to make Drupal rock in terms of content-editing. These are ambitious plans and the more developers participate, the higher will be chance that we will see Wysiwyg API & Co. in core for Drupal 7.x. The goal is to not have to download and install a separate module to have support for client-side editors, so this will benefit all users of Drupal.
Anyway, thanks for considering and taking the time to reply.
#12
http://tinymce.moxiecode.com/punbb/viewtopic.php?id=14439
Issues like this should be adresed in all modules i guess that have wysiwyg functionality. So if you developers could join efforts in overcoming this you could make all modules more "Drupal friendly".
#13
I played arround a bit and i didn't use any module. I just for testing manually configured drupal to show TinyMCE Button bar just for the "edit-comment" textarea.
Then i found out the best thing is if TinyMCE uses these setting to work with drupal.
entity_encoding : "raw",
I read this artice too:
http://www.lullabot.com/articles/drupal_input_formats_and_filters
And it mentiones Drupal uses raw input data. I think you know that but i mentioned here beacose it gave me a lot of trouble when tinyMCE did one thing and Drupal did something else.
But there is one fundamental difference. TinyMCE needs paragraph tags to work correctly (to determine linebreaks and paragraphs and to format text correctly) and Drupal uses Line break converter for this.
But we can't just turn off Line break converter and under filtered HTML add paragraph tag. We could do that but what about users with no javascript and classic input textarea? There would be no format there any more for line breaks. We can't expect them write pargraph tags themself.
And i noticed another issue. FF3 and IE7 work differently with tinymce. If we press space just after paragraph tag in tinymce in IE7 the white space will be saved to drupal if we use raw method. But in FF not.
#14
Actually, no. I gave up too early. Even the maintainers of FCKeditor joined the Wysiwyg API project now.
Do I have the chance to turn this thread from an initial negative experience into a positive discussion about what needs to be done to get all of you on board?
In advance - just complaining about differences and too many or too less features does not help. We need concrete action items for stuff that may need to be changed in Wysiwyg API to get something done.
#15
TinyMCE has BBcode module that works great with Drupal. Not actual BBcode tags but the way it converts paragraphs tags in carriage return. It could easy be a "Drupal module" in that asspect if we removed the bbcode tags and only leave the "bloated tags" <-> carriage return conversion. (but i don't know how this affect advance functions of TinyMCE. I use only basic things for my users that have filtered html input set to standard drupal settings). I used wysiwyg api and loaded bbcode plugin in to it with api for buttons and plugins inport when i was testing some things.
I mention this here but i know you know what you are doing and probbably solved this all- ready. For now i don't use any wysiwyg module with drupal but manualy implemented tinymce. But a lot of features that wysiwyg api offers i don't have. So i wish you all well and hope you all succeed with your goals. I would help to code if i had more experience and knowledge. But i don't have. So i can't.
#16
sun,
don't understand like your post was taken negatively. It is normal that you would like to collect good developers to make Wysiwyg module as good as possible. This can be only good, and maybe we will be grateful to you one day (if the actual result will be as expected).
But, my concern is that the project is planned too complex, what always brings with too many issues (which due to the amount of them and even interferrences among them are never resolved...) and too demanding maintenance and fine-tuning...
Therfore I vote to have also more simple solutions, which are sometimes simply optimal for more simple demands in all aspects - so I really wouldn't like "smaller brothers" of otherwise very good modules to disappear (generally, not only in this case).
And, I will consider to use any Wysiwyg (or any other text edit) module only if it will be ensured that it is not changing the core Drupal behavior, but only adds users a possibility to enter (or edit) the HTML code more comfortably. Probably it is a problem of javascript code interaction which is beyond my abilities to understand it, but as long as I will have to learn how exactly to put Drupal breaks to achieve the summary to be added to the body or not (and so on), I prefer to enter the code manually, or use a module which more or less doesn't break that. And, it looks to me this is not very important issue for maintainers of Wysiwyg, so I don't expect it to be useful for me very soon...
So, it would maybe be better to ask maintainers of other modules to help you resolve certain issues (where you believe they have nice solutions for, or a lot experience about similar subjects...) or details you work on (as posted issues here), but not to leave their work (we appreciate and need) and be a kind of lost in a big group of developers of a module which could benefit of their work, but is not exactly what they want to do.
It is sometimes (don't want to say about your project at all, but just as a generalization...) like you mix very good ingredients into a cocktail (or, a meal) which is not necessarily good as well... ;-)
#17
LUTi but to be honest. If WYSIWYG API gets done and proves it is good. Don't you think 90% of Drupal users will use it? And WYSIWYG editors are getting better and better each day. Now days they are evan ussable. ;)
And just today i found this:
http://tinymce.moxiecode.com/punbb/viewtopic.php?id=12301
Looooooooooong instructions explaining different things. :) So the module that will overcome this will be complex. I agree. :) But one of moderator at TinyMCE said they are thinking about improving compitability with Drupal too for some time now.
Time will show us the answer i think. It allways does. So if you join forces or make this a competition i think both options will bring resoult. Best of luck to you all. But be aware that you are biting in the same lemon!
#18
Ledo2, I admire the development of Wysiwyg module in last year or so - it has improved really a lot.
But, unfortunately, I need for production site much less capable (or universal), but so much more stable and reliable solution. And that's where TinyTiny is at the moment for me by far the best choice (I've tested many modules about 2 months ago, and TinyMCE is the best WYSIWYG solution, but unfortunately I've had too many issues with TinyMCE module as well as Wysiwyg API module), and most probably it will be so for quite some time in the future as well (I believe I've written enough about my reasons in ma previous posts...).
But, I will for sure try both modules again (as well as some other interesting ones, if nothing else becouse of my couriosity...), probably when Drupal 7 will be out, and I will have to select modules I will use with it. And, for sure I will report whatever I will find interesting... ;-)