I am a web developer with long experience in PHP Nuke, OpenPHP, and Mambo/Joomla. After take a deep look at the Drupal source code and coding that available on TinyMCE and FCKEditor module, I can say that next Drupal version must has a builtin WYSIWYG Editor. Please CMIIW, but read my reasons first before you have different opinion:
- Both TinyMCE and FCKEditor only find
<textarea>then translate to their editor interface.
Then how to avoid certain Textarea not converted? The anwer is not possible. What TinyMCE does only disable editor on certain page and FCkEditor will work if the textarea >= n rows.The real case is disknode module. When you set disnode to allow more than 1 file per disknode then the
<textarea>of file upload list will converted to Editor. Currently, you can disable the<textarea>on this page but the<textarea>for type description of disknode will be disabled too. You may say, that you can enable the rich-editor-toggle, but you can't set 2 default value: the description using Editor and the file upload list using<textarea>. - A best solution, IMHO, is provide a function in Drupal to call the Editor. This Editor() function simply call the ediitor if available, but if no editor installed then Editor() uses
<textarea>. - Developer like me, will be easier to create module that need both Editor and
<textarea>in same page/block - We can extend the User Administration: adding capability to select which default editor for each users. We can set that default editor for user is: none (mean using textarea), TinyMCE, HTMLArea, FCKEditor or any editor that installed by third party modules.
- Easier for community website which contain people that aren't not familiar with HTML tag
- Easier for blogging site, since blogger usually a person with limited website knowledge, such as journalist, teacher, employee or doctor
- At the rest, Drupal will no doubt called as the killer CMS. This will add more powerful to Drupal, the best CMS that I love.
What are the advantages if Drupal has Editor() function?
Comments
My gut reaction.
EDIT: oh, do you mean a function and NOT an editor MELDED into the core? Then why do you say 'built-in?' I am confused...do you mean IN THE CORE.... yikes! horror if so...!
----earlier text below:
you probably know a LOT more than me...tho as a lONG time mambo/joomla nut...when I found drupal I fell in LOVE big time... NO HUGE nest folders and folders of stuff in the core... God, i'm even freaking that there's now going to be an installer...
though that hopefully can ALL be deleted...
How SEXY to look at the files in the download of drupal 4.7
and with joomla ALL the editors SCREW up the code... in very insideous ways...
No NO NO please god.... no built in editor... add-on good...core level bad...
I PRAY not on anything in the core beyond the BARE NAKED essentials...
have you compared the size of Joomla to drupal?....
FCK is the ONLY editor for joomla that 'usually get's it...erm... ok with the code...
I just run it standalone to practice how the client will use it in the joomla backend...
NO is my vote for ANYthing In the core...
Please don't ruin my life... there's already a joomla huge-ware
best wishes to ALL
truly!
that's it
totaly agree with you :)
--
ufku
Geneticists from METU
This attitude just floors me
So is Drupal some coding work of art that will be "defaced" if the code gets beyond some "artistic limit?" Or is Drupal a tool for building effective community websites?
Granted, Drupal has done a great job of keeping the code clean and flexible, and that isn't likely to change in the future. Adding more editing functionality isn't suddenly going to turn Drupal into some bloated nightmare of code like many other CMS's. The secret of Drupal's tight code lies in the skill and philosophy of the core coders, period.
HOWEVER, Drupal desperately needs more powerful handling of input by casual users. Otherwise, Drupal might go down as an artistically beautiful code set that is impractical for the casual user.
Since text entry is the gateway into any CMS, (and the door hackers slip through) it makes sense that enhancements to text entry should be part of core in order to protect its security. This includes better handling of picture and file uploads.
Providing core hooks for WYSIWYG editors (or other types for that matter) makes imminent sense. It will allow these editors to be more tightly integrated into Drupal and hopefully enhance file and picture upload as well. Developers would have more granular control over when these editors were activated.
All this, without bloating Drupal's beloved tight code.
Agree 100%
I agree 100% with zoon_unit
ditto .. precise and to the
ditto .. precise and to the point .. excellent
consider the users, not the admins
I agree with zoon_unit. my users freaked when we moved from wordpress to drupal, because drupal lacked the rich text editor they were familiar with, and NEEDED. why did they need it? because it made it dead simple to add formatting and especially add links to their content. if you don't know how to support these users you have not learned what it means to administer a community site.
not again
please lay this issue to rest...
we're considering the admins, admins have the choice to add one of the modules for an RTE and then the end users will have no problem if the admins do their job.
--
I work for Ontwerpwerk
this is not how it works
To put it very simple, this is not how form API works. However, I can imagine people adding
#wysiwyg => FALSEto their textareas and the WYSIWYG editors skipping these. This would require zero code change in core (form API does not care about attributes it does not use), just a little communication w/ contrib authors. Communicating is something you can do, too: contact disknode, tinymce and fckedit maintainers and point them to this comment. The handbook page of WYSIWYG modules should include that they care for this property and that's about it.The core authors see this as cruft. A fictional manager module which stores fields (form id and field id) could add this attribute.
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | please donate
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
see also...
sun started work on a module that adds the
#rte = falseattribute to core fields http://drupal.org/node/81297#comment-137803So I guess that will be the way to go..
--
I work for Ontwerpwerk
zo dat is dichtbij :-)
I also work for a company in The Hague.
And I definately agree with the topic starter!
So what?
Before ppl begin to litter this thread with "me too!" let me point out the only measure of relevancy in this community: contribution (be that support, documentation or code). If you have not contributed anything, you have no base to make demands (topic says "must").
And, quite interestingly those who have contributed seriously know it better than making demands...
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | please donate
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
What?
The topic uses the word 'must' in a non-demanding tone -- it is even a question. People can make suggestions regardless of their Drupal history. Relax, chx. Thanks.
Note: two answers
My first answer was absolutely constructive -- even if it turned out to be duplicate of an older thread I was unaware of.
My second answer was a bit more forceful because I am sick and tired of ppl demanding (strongly or weakly but still demanding) to include *broken* stuff into Drupal core. This guy even spammed the devel list with this idea and there someone answered rightly: there is no working WYSIWYG editor.
I am totally relaxed though and spend most my time with constructive stuff. Have you seen the taxonomy term interface patch :) ?
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | please donate
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
Well, if you are sick and
Well, if you are sick and tired, stay in your bed. And if not, please post you reply to the right guy.
I think he has a good suggestion so please don't complain. Not all of us read the dev lists so we can't know that...
Dries, how difficult would it be....
...for Drupal to reach a compromise on this editor thing? Here's my suggestion:
Extend the existing textarea filter code to include a non-wysiwyg editor similar to phpbb or the quicktags module. (http://drupal.org/project/quicktags) In other words, the user can highlight code in the textarea, and then click an icon to "wrap" that text with either valid html code or bbcode, etc. You don't have to be wysiwyg to improve usability.
This would at least ease the learning curve for amateur users. The editor icons would ensure that the user inputs valid html and acts like a training tool as well. The user sees the correct html usage.
In order to truly ease the burden for non-technical users, this editor should tightly integrate with the image and img_assist modules to simplify adding inline images. There should be an image upload icon that inserts the tag information at the cursor location. The editor icons should be extensible from modules, so additional icons can be added for things like the new embedding module for audio and video.
Admins also need more granularity to control the image upload options in img_assist. For instance, one user role might only allow linking of outside images but no uploading, while another role might allow linking and uploading, as well as image resizing. Admins should be able to set these functions from a checklist by role. Right now, img_assist is just too simplistic and restrictive in how it can be customized. Image upload is a pretty universal need with most CMS's. Shouldn't it be part of core?
The main goal here is to make data entry and image inclusion as simple as possible for casual users, while ensuring efficient and SAFE html.
I responded too quickly on the dev list...
Didn't realize that the conversation was really here....
I get what your saying - I agree even. But a few facts stand in the way.
A) Unless there is a HUGE overwhelming need, Drupal doesn't use third party code. It is a big step to be integrating the jQuery library, and as I unerstand it, that has ben based on a long discussion regarding aligning the two projects paths - no such discussion has been had with any of these other third parties.
B) None of these work very well. Oh they work and a lot of effort has been put into making them nice - I'm not disparaging these projects. But none of them are at the level of being integratable beyond a contrib module. (e.g. If you try you can break the demo versions of these products on their own sites. )
C) WYSIWYG should always be a cntrib module. In general, I've foun them to be as large or larger than core itself... not that that is so big, but if you don't use it, its a whole section to think about that you shouldn't have too.
Now, I like the idea of making it an optional built in specification for contrib modules. This very much paves the way for a worthy WYSIWYG to be integrated across all contrib modules. If you were to start organizing peple now to do this in their contrib modules, it could save A LOT of work down the line once a WYSIWYG people can agree upon is fine.
In fact, I'd say that is one of the best WYSIWYG initiatives I've heard posited in this forum yet standardize a wysiwyg interface across contrib regardless of the editor. Could save a lot of eople a lot of time.
Good Luck!
Sam Tresler
http://www.treslerdesigns.com
-------------------------------------
"A list of common problems and their solutions can be found in the Troubleshooting FAQ."
jquery wysiwyg
Is there a project that plans to create a wysiwyg using jquery.
Other than
Other than http://jquery.com/docs/Plugins/tinyMCE/
I don't know of any such efforts
--
I work for Ontwerpwerk
There is already one
take a look at it http://drupal.org/project/widgeditor
it does not have the full functionality of tinyMCE or FCKEditor but should be OK for most users
----
world experts tag cloud
------
GiorgosK
Web Development
How do we solve Drupal problem in textarea?
Ok Drupaller,
Based on your all answers now we know that at least 5 answers for textarea problem in Drupal. The problem is: if we have more than one textarea on same page, how do we set that textarea-1 must converted to editor while textarea-2 still as textarea?
The answer are:
1. Include a built in editor in Drupal, such as TinyMCE, FCKEditor, HTMLArea, or create new one.
2. Include an Editor() function. I mean only the function without real editor code there. This Editor() function will try to find if an editor module installed then call the editor, otherwise, if no editor module installed then stay tune with textarea. Admin can set which editor is the default one for every users. Users may select any available editors that given by the administrator. So, every users will be convenient with his/her selected editor.
3. Add a class on the textarea, such as class="enable-wysiwyg". If Drupal find this class then call to replace textarea with the editor. This implementation supported by most WYSIWYG Editor but their use different class name. So, to make easier, Drupal need to say what class name should be.
4. FCKEditor has an option to trigger the editor if textarea >= n rows. But I see this option not available on TinyMCE (version 2.0.6.1).
5. Forgot this problem, since Drupal will not extend their feature on this editor area. And stop reading this issue!
Drupaller must be understand that I am writting this issue because we really face this problem. It is not about include a third party or not. Also, it is not about alter the clean-codes of Drupal. It's about how to solve this problem.
For me, who has been more than ten years in computer field and has certified in Internet, RH Linux, Windows Server, Programming, Oracle, Router, and Network, this is not a big problem for me, because I can hack the Drupal code to meet my requirements. But, for who love Drupal without computer background what are their options? They try Drupal first because they heard/read Drupal features (such as multisite and blog), but once they know Drupal is not easier then they try Mambo/Joomla and never back to Drupal (but I hope they are still monitoring if Drupal become easier in the next version).
Again, in my point of view as a Developer: Drupal is easier to extend and great CMS with huge features and very good skeleton code, BUT not easier to use for people without computer knowledge. That's what my tens clients say.
We all love Drupal and want Drupal still the best, otherwise, other CMS will take Drupal users by increasing their feature. It's not difficult to make other CMS take the Drupal code/idea because of GPL's right. We see that other CMSs using jQuery too. This is the time to make Drupal easier and has more features.
Regards.
...
I draw your attention to this page for your consideration.
People continue to praise Drupal for it's clean code, architecture and ease in implementation then require/demand/complain that bloated non-standards compliant things be added to core that slow down page loads, have weird issues and complicate things arn't installed. My experience with TinyMCE required that I hand edit 75 nodes of a site to repair the damage done.
I think that it is more important to have the option for you, the site implementor, to add the editor style of your choice to your site. You can choose FCKEditor, TinyMCE, QuickTags, BBCode.
In 5.0 there will be an option of profiles. This will let others develop their own custom Drupal distro that comes with a pre-configured setup depending on the profile someone else designs. So some mysterious 'someone' can if they so choose make a distrobution like CivicSpace with the editor of their choice and package it for download. The rest of the people can choose to not download it and perhaps stick with Drupal core or even setup a competing distrobution.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
hi sepeck, i mention that it
hi sepeck,
i mention that it is not about clean-code or which editor should we choose. Drupal currently has no feature to trigger the editor, thus a Distro Profile will not solve this problem. Checkout the Drupal source code, especially on textarea tag, then you will understand what do I mean.
Regards.
umm....
Your very first item was
You then said to include a trigger for said editor that might or might not exist and might also need to be written by 'someone'.
So I posted my reply. If you think there would be benefit to a trigger, then that's fine. If posible submit a patch. Of course 5.0 is api frozen at this point so it will probably need to be targetted towards the next version.
I will continue to point to the principles of the project because clean code and elegant solutions are very important. It is the foundation on which all other stability of the system resides. Can Drupal be improved stil? Yes. Needs more work. Work is ongoing as it has been for 5 years per the mission and principlas of the project. I also think with install profiles that most of these arguments will be removed by distribution offerings by various people.
In some ways Drupal development appears very fast and in others there are foundations to be built and transistions points to be setup for things planned for two versions for now. See the presentations from Brusselcon for some of these future paths.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Adding Editor() function
Adding Editor() function will still keep the Drupal codes to be clean. This hack only require very2 small line codes adding to the core.
I still don't understand how one can say that this function will make Drupal code not clean anymore? (Except the #1 solution: add an editor scripts).
I guess that many reader didn'y understand what is the different between editor scripts and editor() function. Let's me explain in simple:
1. Editor Script: is a full scripts to provide WYSIWYG Editor, example of this editor scripts are TinyMCE and FCKEditor
2. Editor() Function: is a function only to call the editor scripts (so, Drupal needs no to include the TinyMCE/FCKEditor/HTMLArea). This function only requires several lines code.
So, anyone agree to extend Drupal feature to meet WYSIWG requirement?
Regards.
Follow the dev list.
It is unfortunate that this conversation has split between the forums and the dev list. Just to bring people up tospeed the conversation there seems to be revolving around finding a handle to target the various text areas in drupal. Mainly, ones you'd want to enter HTML into (e.g. body:)and ones you would never want to enter HTML into (e.g. tags) .
The object being to then use those points to in turn use a contrib module calling something like this editor() function. Thusly standardizing are various options and making them interchangeable by user. user/2 likes FCKeditor user/3 likes tinyMCE user/4 likes html area etc.
This would eliminate a lot of the need for these indendent modules to maintain where the editor appears etc, could be used as a handle for many things that aren't related to WYSIWYG editors but need to find specific text ares (nothing springs to mind, but...) , and be the first step towards making WYSIWYG easier to use in drupal - core or not.
Anyone who knows better please correct me if I'm incorrect in conveying this, This is just how I perceived the discussion.
Sam Tresler
http://www.treslerdesigns.com
-------------------------------------
"A list of common problems and their solutions can be found in the Troubleshooting FAQ."
Say what?
Ease in implementation? Only Drupal die hards believe that! As MANY posters point out here everyday, (and the CMS community concurs) Drupal is NOT easy to implement and customize for the new developer.
I've been reading a lot of your posts lately, and your attitude and that of many other Drupal diehards seems to be:
1) Drupal is perfect. We have a code of principals that overrules all. There is no need to consider the opinions of outsiders.
2) Newbies who don't know enough to contribute have no right to complain or point out deficiencies in Drupal's design.
3) It's all about Drupal being small, tight, and made for heavy duty programmers. The actual USERS of a Drupal site are afterthoughts, so long as the website developer has a clean program that he can spend months tweaking and learning.
I know this is a gross exaggeration, but I wonder if you realize how your attitude and that of some of the other Drupal elites comes across to newbies who WANT to become Drupal fans and developers.
This attitude of "it ain't broke, so we won't fix it" rules out the kind of open minded dialogue that can sometimes discover wonderful solutions to problems that satisfy all. For instance, no one is even considering a compromise non-wysiwyg editor, because it's all about protecting your position rather than finding solutions.
I just spent 4 days searching through hundreds of posts on this site, studying the Drupal api, reading through reams of php (a language I'm just learning), just to find a way to display different size user images on certain nodes. Drupal may be easy to set up in its native form, but extending and customizing is DEFINITELY not easy for some functions. User input and image handling is deficient, period. And yet many here are too busy defending the status quo to look for elegant solutions to issues that the unrespected newbies bring up.
Here's the bottom line: Drupal needs an enhanced data entry and image handling option, whether its wysiwyg or not. If you can't see that, why even read these posts in the first place? Thankfully, Dries seems a bit more open to these ideas than most.
My apologies for the extreme response, but frankly you have a tendency to grate on people with your smug response to legitimate concerns expressed by aspiring Drupalers. I don't want to get into a debate. If you don't agree with my statements, fine. But I felt this needed to be said. I'll shut up now.
...
You continue to do this to me zoon_unit. I try and answer your question and you then post stuff like this. I am trying to help point you to the reasons things are the way they are. To help you understand the why so you can help accomplish your 'what' effectively.
Your leapt to conclusions and method of expressing this is ... trying.
1. Drupal community takes input all the time.
2. I answer to educate. I am not the only voice but choose to take the time to help new people.
3. You fail to understand. Drupal core is small and tight to provide a flexible base. This allows widespread flexibility. There was a lot of usability work and discussion between 4.4 to 4.5 and a lot of those items have been implemented into 4.6 and 4.7. Each iteration allows for new features and tools to implement those features. The interface for 5.0 had far more end discussion on UI then you can evidently be bothered to research.
Drupal can be a CMS out of the box but needs additional modules added by someone to tailor it into a solution for a specific need. I use Drupal core with additional modules with no programming or development at all. However Someone Still Needs to Build the Site. Adding everything and the kitchen sink will only take away options.
The actual users of Drupal.org are not end users. They are site developers, programmers, power users, site implementers. They are not a given sites end users. Deciding how and what features to implement for a site is the responsibility of that sites creators. Deciding if Tiny_MCE or FCKEditor or Quicktags is the right solution for their users should be their choice. Drupal gives that person that choice and that responsibility. It does not tie you into a solution that you need to 'remove things' It starts you with a base where you add things. This makes it more easy for people you don't pay to maintain a clean flexible base that can have api's and features added to it. So discussing 'how' to make this easier is a better approach then 'requiring' that one arbitrary one be added and I do believe I mentioned that.
My mention of 'profiles' is one such solution. Profiles will allow people to package Drupal core with additional preset modules more easily. This means that if you want to provide a service with a preconfigured wysiwyg editor built in, then you can far more easily do that. This will mean that you can use Drupal core and provide a reconfigured option to a given group of people. This is one of the under rated features of 5.0. It will be interesting to see how it develops and see if more people provide preset distributions like the CivicSpace folks do. ie, one focused on blogging, another focused on corporate brochure, a third on gaming sites.
Does Drupal needs a better file handling API. Yes it does. Why aren't YOU working on it? (Oh right, now you're going to attack me again because evidently saying that is offensive). I know who is (it's public knowledge). You want to help them? All you have to do is involve yourself in the community to find out who is working on this. There was even a presentation on it at the Drupal Brusselcon. Evidently foundations have to be laid to achieve the desired results so features may take a version or two to fully realize. Until then yes advance stuff will take more complex solutions.
You could have used my contact form. You could have sent a private message and we could have worked things out in a mature, reasonable way. I don't take the time to 'get smug' before I answer peoples questions. I try and help them. Rants and demands aren't solutions.
You chose to flame me in public for trying to help explain things to new people. Wow. Just wow. Way to go. Thanks.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Well just for the record....
A) Quicktags is the non-wysiwyg option that is being considered and would implement this editor() function as well.
B) Not that I want to get dragged into the debate - but having read your posts I get the feeling the reverse is also true - meaning that you only consider people who you see as condescending, rude, and smug to be drupal elitists. I consider myself a drupal elitist and I've never turned down good advice in these forums - to my knowledge.
C) Please consider the delineation you are drawing. Yes, newbies (I hate that term) - new users, rather, can have good input and their are entire groups of 'Drupal Elitists' out there harvesting their opinions but like it or not the devs know more about how drupal works than anyone else on the planet - they don't need to dig the api.drupal.org - cause they wrote it.
When they give good reasons as to why something doesn't exist - its just that usually, a reason - not an adamant no, but a reason. Ergo, when people come along and offer valid solutions they get lots of discussion - been about 20 posts on this editor() function here and another 20 on the dev list - people are listening and taking the first steps twards implementing this. Because this guy came with a possible solution - not just a another problem. It isn't that new users don't have a right to point out problems - they just don't have a right to expect a solution that they don't figure ut themselves. They DO have a right to a helping hand - which is what a lot of devs give in he 'This is why it doesn't exist format' or to rephrase - 'If you want t build that - this is what you need to address' IT IS HELPING!
D) Right now there are 2062 issues open, down from 2140 one month ago - those are bugs in existing code - NOT feature requests like this is. 78 fixed in a month. We are in code freeze. If people aren't jumping off their current projects to address this, no one should be getting offended. And those numbers go far to refute your impression that ANY dev on this project things 'Drupal is Perfect.
E)"3) It's all about Drupal being small, tight, and made for heavy duty programmers. The actual USERS of a Drupal site are afterthoughts, so long as the website developer has a clean program that he can spend months tweaking and learning"
I've personaly given you the reasoning for this before. Small tight and clean keeps that issue list in the 2000's not the 10,000's - If discipline is not kept with this - on a complex system like drupal, things will go horribly awry. Again, dev speaking from experience of having prjects crash and burn from sloppy and redundant coding practices can attest to this - last I check new users lacked that experience. No one s discriminating agaist them for this lack of experince, but they should listen when this has been repeatedly explained, time and again, and in the coding practices, and in the mission statement.
F) And for the record, I am not a coder but an amateur like yourself. But if ayone ever spoke to me in the way you speak to sepeck - who might I add has 120 some odd pages of forum support threads and contributions in his tracker - I'd get very angry. The forum is a place to discuss drupal development, support, issues, consultation - but absolutely not for calling individuals out. If you feel that passionately about his attitude, keep off the forum, please.
G) and please, stop lumping all drupal dev's and power users together. You've done it before, and its offensive.
Sam Tresler
http://www.treslerdesigns.com
-------------------------------------
"A list of common problems and their solutions can be found in the Troubleshooting FAQ."
Good points
For the record, I've already apologized to Steven in private, but I suppose I owe him a big, public APOLOGY. My bad. I took my post too far. New user input is a trigger point for me because I consult with corporations who tend to ignore user input, then wonder why they lose business and receive complaints. It's a pet peeve that I let get to me.
As to your points:
If that's true, then that is GREAT!! That would be a perfect comprimise by making the existing editor more usable without bloat. Those that wish wysiwyg still have that option. Great, great, great!
That is certainly not intended. I try to take care to use the term "some" when making a generality. I've always believed in the adage, "criticize the behavior, not the person." However, it's hard not to make certain behaviors personal when you're responding to a particular post by a person. I've seen tons of helpful "Drupal elitists" (of which Steven is certainly one) and a few not so helpful elitists.
I would be remiss to offer advice to others if I can't accept advice. So, I stand corrected with my behavior. I'm going to bow out of the "listen to new users" issue from now on, and concentrate on paying back all the wonderful contributors that have helped me improve my Drupal skills.
Chow
Conclusion.. please ???
I am surprise that this topic become more interesting, but now users need a conclusion, any one capable answer these question below?
Will Drupal extend the capability in editor are?
If no then stop. If yes then:
a. Which method will be used? Add new function called editor(), add built in editor, add standarize TAG name, or ...?
b. When? Drupal 5.x, 6.x or 7.x?
I hope anyone who capable answer this question going here (as you know, there is no Drupal roadmap available, so everything must be ask separately, one by one).
Regards.
Doesn't quite work like that....
Development on an open-source project largely comes in a 'scrath-your-own-itch' flavor. Meaning when someone who can code needs this or someone who can't is willing to pay, or organize volunteers who can this functionality will be pursued. It certainly won't be for 5.0 as that is currently in code freeze. Now if someone wanted to write a contrib module at this point, they certainly could.
But even though the entire dev community agrees on a way to do things, doesn't mean it will happen... This was the last I saw on the dev list about it:
Which comes close to answering your How? question. As to when.... when someone steps up to code it and supply a patch.
Sam Tresler
http://www.treslerdesigns.com
-------------------------------------
"A list of common problems and their solutions can be found in the Troubleshooting FAQ."
Tinymce nor fckeditor should
Tinymce nor fckeditor should be included in core anyway. As a module they suck too (like file browser etc). What is needed is a drupal specific WYSIWYG module that totally integrates with drupal. A new module is needed, that doesn't require thirdparty integration.
Hallelujah brother!
My sentiments exactly:
One of my top 3 'niggles' with Drupal is the lack of a WYSIWYG editor. I have stated in the past:
Could widgEditor (or an eventual derivative of widgEditor) be the one? - widgEditor - http://drupal.org/project/widgeditor Although this editor still has many rough edges and issues, it is one of only a few editors (and the only WYSIWIG editor) that installs without fiddling and fiddling and fiddling.
Casper Labuschagne
Where am I on the Drupal map on Frapper?
Drupal is like a puzzle
Drupal is like a puzzle and this is the reason I love it.
My humble suggestion for those who like to have a solved puzzle (Drupal) for their needs is to have a place where those guys may upload combinations of core and contrib modules.
I want to be free to play with features and modules .. don't you? .. it is a good thing and it is simple. I have the opportunity to use the editor I like. Why to impose something? ... come on, think a bit!
Drupal is and must remain a usefull tool.
------
The World is a big puzzle but not a solved one!
Florian
Right. But if you take a
Right. But if you take a deep look, currently the editor can not only convert certain textarea to editor! This case happen when you have more than 1 textarea but only want one of them converted to editor! This kind of weakness come from Drupal core. Currently there is no standard way how to solve this problem for every editor (TinyMCE, FCKeditor, HTML Area, etc). What Joomla does is provide editor() function, this is very smart approach! Now, how Drupal core solve this problem?
Look kids, Big Ben...
Look kids, Big Ben... Parliament.
-zach
--
harkey design
: z
Nice reference :)
Something from Groundhog Day would've been far too literal.
To be fair to the OP though, this time around there was at least a potential solution suggested that actually got others thinking about it further.
--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ
After reading this debate . . I don't think Drupal is for me
I've been evaluating various CMS options and I want to like Drupal. I really wish I could choose it above other alternatives. But there is just no way the users are going to be happy with it. Despite all of the shortcomings, Joomla or even WordPress are better options from content producer (end user) perspective. They have built-in WYSIWYG support. I'm continuing my testing, but not with Drupal. I was looking for some string of hope that v5 would provide an acceptable solution for my situation, but I'm pretty sure it will not. I know could customize but I really don't want to. I could wait for a tailored Drupal distro, but fragmentation seems even more of a pain from a long-term support standpoint.
I thought you might be interested in hearing from a potential user who picked an alternative solution and why he did so. Best of luck with future development.
This would be a good place
This would be a good place for me to mention that last week I converted 2 longtime Joomla guys to Drupal. In both cases the deciding factor was the ease of extensibility and lack of feature bloat in the core. Net gain: 1 user.
*Of course, to be fair, they didn't just base their decision on "reading this debate," they actually tested the system.
-zach
--
harkey design
: z
Yep, me too.... drupal NODEs do it 4 me over Joomla's code
UPDATE NOTE: have revived myself here after trying todays beta 1 of version 5. Check it sitting down.
me also: >> LONG LONG time mambo/joomla guy.. done sites for 40 or so clients and a dozen friends... Now I am convinced the CORE of Drupal [from actually using it] totally blows Joomla over... read the dev pages on Joomla and how a nodes based content system is WAY off in the distance for Joomla...
And really... understanding the core is what it's all about for me now... no, I'm just an intermediate user with no large understanding of php css or html particularly [damn relentless on any needed learning of course :)] .. personally I just find the curve of learning drupal doesn't top out [as Joomla did for me - TOO much core code for starters] and leave you with a massive beomouth of features [huge upload time AND server space requirements as well] ... anyways, you get my point...
Joomla definitely tops out .... discovering nodes and all really made me go...hmmm..
Best wishes to all... just can't bear to hear Massivo-joomla being tooted as easy for users.. it is and it ain't ,,,,, the editors ALL screw up the code/look... -sigh- I could go on...
I'd say.... yeah, keep your Joomla if you need it [many of us still do, obviously] tho don't miss Drupal's rise to the top [imo]... LOOK what can be done with it... There are some Freakingly cool things [PRO layout-wise] that i have never seen in any Joomla site ... and that sexy small core[not cluttered with hundreds of sub-folders - almost NONE at all .....wooo!] ... feels real manageable/know-able..