I would love to see a WYSIWYG included with the installation.

* More attractive to new users
* It's a killer feature
* Also add an image mannipulation module for nodes to work with the WYSIWYG
* Running f.e. TinyMCSE with multiple db/webs in one codetree is problematic and imho its pointless to create one database per webpage just for TinyMCSE settings.

It's not just that I'm lazy and can't fix this myself. This would help new users alot and attract more people to Drupal. I know HTML but f.e. my Mom doesnt and most of the people who use CMS systems don't.

If image manipulation for nodes and WYSIWYG editors were made part of the core, that would rock.

Comments

robertdouglass’s picture

First, I agree that some form of editing help belongs in core. I also think that TinyMCE is the best tool we have available at the moment. That said, there are some problems with this. First, TinyMCE depends on 3rd party software (as do all of the WYSIWYG editors) and our Drupal release schedule would become exposed to the pressures of synchronizing with these external projects. Second, TinyMCE still has browser compatibilites.

I didn't understand your comment:

Running f.e. TinyMCSE with multiple db/webs in one codetree is problematic and imho its pointless to create one database per webpage just for TinyMCSE settings.

What problems are you talking about?

Finally, keep in mind the image module isn't in core yet, so integrating WYSIWYG and image stuff is way down the line.

- Robert Douglass

-----
If this helped you, please take the time to rate the value of this post: http://rate.affero.net/robertDouglass/

www.hornroller.com, www.robshouse.net

sepeck’s picture

No.

New users can add the module.
img_assist works with TinyMCE (though even better image handling issomething needed)
I don't like tinyMCE (well, I don't mind it and use it occasisonally :) but there are staunch advocates of htmlarea, etc).

Core should not have stuff that relies on third party stuff like that. I think that having a broad array of choices available i smuch better. My choice is to to it by hand. For my sister-in-laws site, she uses tinyMCE, but tinyMCE does not work completely in Firefox on any of my installs and she doesn't use IE so doesn't get the advanced features (she's learning html instead)

On the choice front, with add-ins we have HTMLArea, TinyMCE, BBCode, Wiki and proabbly more. This allows YOU to customize a solution for your client/environment. This keeps core clean, allows for more/better text entry solutions as they develop independantly over time outside of Drupal.

With a little effort, this easy flexibility also helps your Drupal site not look the same as every other Drupal site.

I think better documentation on how to assemble sites from bits and pices of Drupal would be of better long term use.

-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

benshell’s picture

I agree with keeping the core as clean as possible. However, I'm afraid that because what is included in the core is so minimal Drupal make not look as impressive to someone browsing www.opensourcecms.com or the demo on Drupal.org. Just like with an interview, the first impression is critical. There are a lot of CMSes on www.opensourcecms.com, but I've only looked into a few of them. Others I've dismissed after just a few seconds. I found Mambo extremely tempting because it is so graphical (and includes TinyMCE), and I only gave up on Mambo because I didn't like how the code was organized. But that's because I'm an coder and I knew that whatever CMS I picked I'd make changes and addons.

My conclusion: How about installing some of the most popular addons, including a WYSIWYG editor, into the demo version on Drupal.org? There would have to be a disclaimer that says not all addons are included in the "base package" (car ads do this all the time) but I don't see anything wrong with this. I don't think it'd be possible to do this on www.opensourcecms.com, but just upgrading the demo on Drupal.org would be a great start.

zach harkey’s picture

Guys, drupal.org can can barely handle 100% plain text as it is. I think if they turn on even one more module the whole site will come to a crashing halt.

: z

killes@www.drop.org’s picture

About which demo version on drupal.org are you talking?
--
Drupal services
My Drupal services

benshell’s picture

Umm... nevermind! I didn't realize the Drupal demo link was going to the demo on opensourcecms.com. Has it always been like this? It's been a couple years since I first tried Drupal.

killes@www.drop.org’s picture

There was never a demo on drupal.org. Mainly because there is one on opensourcecms.com. Also, our server couldn't handle the extra load.
--
Drupal services
My Drupal services

sepeck’s picture

Keep in mind, that a demo that appealed to you, may not appeal to me at all. Drupal's core audience has been developers, site admin's or hobbiests who like to assemble and customize there stuff. This enables them to have a large degree of control over their sites and features.

My site, no text entry gui interface, I use w.blogger and web.
Your site, gui interface of your choice.

My site, no forums blocks with Aggregator content
Your site, forums and a shoutbox.

Very flexible solutions.

-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

imerlin’s picture

Running f.e. TinyMCSE with multiple db/webs in one codetree is problematic and imho its pointless to create one database per webpage just for TinyMCSE settings.

I run around 4 different web pages under the same Drupal installation, they share some database tables but the tinymcse module requires new tables for each web (does not like to share the settings). I really loathe storing useless information in useless ammount of tables.

This ofcourse may be something I should be commenting on within the module development of tinymcse.

First impressions are very important but I can understand wanting to keep the core clear of 3rd party programs even if they have nice licences.

Here's a suggestion...

Simular to what f.e. Ubuntu does it there is official relaeses that are supported by Ubuntu. Then "unsupported" "extra" packages. At least modules should be more easilly installed and without the need to manually create tables for each one.

I might put some work into this myself but any input is appriciated.

(I apoligize for my bad english, I'd prefer speaking Icelandic) :)
--
Andri

Administrator by day... Hobby programmer by night...

robertdouglass’s picture

TinyMCE module has the great feature that you can have different profiles for different roles (newb, power-user etc). If you don't mind all your sites having the same roles there is no reason why you can't share the two database tables betwee 10,000 sites. I don't understand the problem.

- Robert Douglass

-----
If this helped you, please take the time to rate the value of this post: http://rate.affero.net/robertDouglass/

www.hornroller.com, www.robshouse.net

imerlin’s picture

You're right... For some reasons I had no profiles and thats why I had an SQL error on my other pages. Didn't show up on mine because I don't use rich text.

Please ignore my comments in regards to the tinymcse module, it works...

Reginleif’s picture

Both FCKEditor and HTMLArea look like really nice packages, but do either of them offer role based configuration? I want the wysiwyg to be restricted to certain roles. I KNOW this can be done with TinyMCE, but last time I had it installed, it broke my valid XHTML for some reason.

dikini’s picture

While WYSIWYG is useful there are problems with xhtml support in most if not all editors I have looked at recently. TinyMCE is nearly good, but still it has quite a few quirks. Try neted lists, for example. The only one I have come across, which produces valid xml is kupu, but it is quite heavy.

IMO WYSIWYG editors are not there yet, if you want your output to be valid xml. This is a showstopper for inclusion in core.

jakeg’s picture

People should remember that including a module in core does NOT mean that module has to be required or turned on by default. Most modules in core aren't turned on by default.

The importance of having code in core is that the code is more heavily developed and also gets updated when a new release comes up. You don't have to rely upon the owner of the modules to update them when it comes to a new release or security vulnerability.

I agree with the general comments about not including code from non-drupal projects (e.g. tinymce)... but of course coding one from scratch or forking e.g. tinymce can also be a right pain.

chucktx’s picture

but if it's not turned on by default that almost defeats the purpose. While I agree with many of the other comments above I do believe that one should be included w/ the default install & I think it should be turned on. There are many things that people who use drupal regularly do after they first set a site up. One more step that included either disabling the WYSIWYG or to change the settings for the pages that it displayed or roles would not be that bad. I think that it keeps new users from using drupal. While some people probably think that it's good to not have to many "newbies." Most people are only newbies for a short period of time. It is very difficult to change an entire site over later. If you just simply had to change the way that you operated the site then there would be that many more people that might start & stay with drupal.

chucktx’s picture

would be to do something similar to what Typo3 does. Typo3 is very difficult to learn right off the bat, & I believe that it has many things to improve on, power & possibilities not being two of them, they do have a good idea when it comes to beginners. They have a separate script that you run & it installs a basic site & gets the templates setup & everything ready for a new site. This allows someone who does not know the software but who wants to learn it & stay with it to use it from the beginning. This at least allows for a slower process to a better site without having to recreate the information. I'm not saying that one for drupal should include a blank site like that one does. One could be creted though that would install WYSIWYG & turn on certain modules & maybe even put them in certain blocks. This way a site could more easily be started and improved in drupal, rather than having to learn more about the CMS just to get started.

bradlis7’s picture

I would really like to see a WYSIWYG editor in drupal that's well built in. I've got a few problems with the tinymce module right now, though it's working better than the others I've tried.

I just opened an account on wordpress.com to see what wordpress had in the way of text editing, and I think it is tinymce as well. Just in case anyone was wondering.

--
Bradlis7.com | Churchofchristnet

lambert-1’s picture

Not sure about this.

The rendering engine is now out of core, and rightly so. Different users have different requirements, and what if a better rendering engine comes along?

The same argument applies with equal force to WYSIWYG.