next »

[davidm]

I am probably not the only one pretty tired with non compliant non sensical WYSIWYG editor... sorry but neither FCK, nor TinyMCE or Xinha cut it for me. Sure, there is Textile and Markdown... but we lack something that is both "user friendly" and semantically sound and standard compliant.

That's where WYSIWYM comes into play. There are efforts out there to build something to improve web editors. One initiative stands out, since it's the only web-based WYSIWYM editor.

You can check their website : WYM-Editor
There is a demo.

Those guys happen to be french, and I happen to know they lack help to make some headway with this, currently this is working only on IE5.5+. If we are to consider integration in MODx, it would first require WYM working wiht Opera and FF...

Jeff, is this interresting to you ? I think it would make for a killer editor if it worked with FF and Opera too What's your take on this ?

Also, I had been thinking : could AJAX be an alternate way to build a standard compliant editor (just throwing ideas here...) ?

[Bravado]

Looks interesting...definitely would like to keep my eyes on this project.  However, with it being IE only...that's quite a showstopper!  Granted, IE is still the most used...but there's an aweful lot that use Firefox and Safari.  Can't very well leave them out!  Plus, the integration of a proper link and image browser would be needed as well.  Don't know how much of a fuss this would be...probably not a whole lot.  Once they've ironed out the problems with it in Firefox and Safari then I think that would be the most safest time to port it to MODx. 

In the meantime, I've been thinking about porting XStandard (http://xstandard.com)to MODx.  Pretty standards compliant.  When I have a little more time, I'll be playing with it.

Also, from my understanding, building a standards-compliant rich text editor is quite a task...especially when you're building it from scratch!  I'm sure someone will come out with more alternatives and, yes, I'm sure there are ways to improve an RTE with a little AJAX stuff.  Probably not from the point of view of XML data returns...but definitely from an interface standpoint.

[davidm]

Thanks for all the input
Nice to know you're considering Xstandards, which looks great...

Of course you're right about the image and resources browser... I know it's an issue with tinyMCE (commercial addon, if I am not mistaken...).

I'll pass your remarks on to WYM's devs.

Looks interesting...definitely would like to keep my eyes on this project.  However, with it being IE only...that's quite a showstopper!  Granted, IE is still the most used...but there's an aweful lot that use Firefox and Safari.

Exactly what I told the devs of WYM-Editor on the webmaster-hub french boards...

[edge]

Jeff,

The main issue I would see with Xstandard is the missing functionality in the FREE light version. Features such as  "Automatically inserts image dimensions" would seem pretty basic and important to render page layout quickly and when you evaluate some of the other features that are only in the Pro version I think most people will need to use that version. The cost is not bad but complicated as its licensed on a per user and per URL basis and that would seem to be a bad thing that would be difficult to manage (i.e someone creates 15 users in Modx and only some can use the editor!)

I am in total agreement that a easy-to-use standards compliant RTE is required. Personally I think your right that WYSIWYM needs to be further developed as a product before it should appear on the radar. For now is there anything that can be done to make FCK more flexible. E.g add classes via XML to float images, right and centre and avoid using the image align property in FCK. I cannot even see how your supposed to link to a PDF document right now without putting the PDF in the image directory ! Guess I will work it.

Do we have any FCK experts in the community that know how to get the most out of the product when used with Modx? After all it works but 1) Needs to be more standards compliant 2)Needs to integrate better with Modx 3) Needs to stop screwing up sourcecode when you are forced to edit there.

If we could address those areas some how FCK would be a lot closer to what we need until something really spectacular that is Open Source comes along !

[xstandard]

Hi,

I am with the XStandard dev team. Right now we are looking at the option of creating a beefed-up version of XStandard Lite for open source CMS. This version will probably contain a few XStandard Pro features not available in our free Lite version.

If you are interested in making XStandard an optional editor in MODx, please contact me by email and we can discuss which Pro features MODx users might need.

Regards,
-Vlad
http://xstandard.com

[Djamoer]

Thanks for offering that, I believe Jeff would like to talk to you more about this.

I'm looking forward to see this a super addition to keep MODx motto, which is to generate standard compliant website.

Regards,

[aour]

Hi

Actually I use notepad and copy paste in the source window of FCK.

Xstandard is a good idea

Aour

[Bravado]

Wow!  Lots to talk about!  Well...here goes my comments on some of the stuff discussed...

Edge...yeah, FCK is not the most flexible editor and certainly has its downsides.  I personally use TinyMCE and find that it doesn't muck up my code as much.  Also, with all the editors, you should be able to use the link button and upload a PDF to a directory other than Images...the dropdown box in the resource browser should allow you to do that.

Speaking of which...the resource browser is perhaps the one thing that desperately needs to change.  I'm in the process of testing a few scripts that, if they work out, might prove to be a nice, simple replacement that we can build upon.  Perhaps the XStandard guys might have some say on it as well.

Now, in regards to XStandard, the only thing I'm greatly concerned about is the limitation of it being Windows only.  I'm not very keen on spending alot of time integrating something that won't work on a variety of different platforms and browsers.  I think some standards need to be in place that allows an editor like XStandard to not only be "standards-compliant" in regards to the code it produces...but to also be "standards-compliant" from a platform/browser point of view, meaning that it will work with just about any browser out there on any OS.  That's been the goal from the gitgo with MODx...to make it as compatible as possible for a variety of platforms all the while making it easy to build standards-compliant website.

I'd be interested in working with XStandard provided that they're aiming for a much wider audience than just Windows users.  If they were to make a version of XStandard that would work with just about any browser and OS, I would gladly replace it with FCKEditor as the default editor...err...that is, provided it's stable! 

[rthrash]

XStandard is Windows only? If that's the case, it needs to go on the backburner of priorities. That'd alienate about 24% of the folks that come to the MODx site, which is too many to tick off.

[xstandard]

XStandard OS X version is currently in Alpha. It should work on FF 1.0+ and Safari 1.3+ on OS X 10.3.9+.

Ryan and Jeff, I'll get you more details by email shortly.

-Vlad
http://xstandard.com

[rthrash]

Wonderful news Vlad... thanks!

[davidm]

It's amazing no real solution to the WYSIWYG + compliancy and semantic markup is not yet solved...

I mean here is a vital part of web publishing that still remains to be fully solved. One could think it would rank high on priorities but it apparently is not...

Maybe it's because most clients don't really care about compliancy and semantic markup, and most power users/ geeks don't care about WYSIWYG (they use raw html or Markdown or Textile...). In the middle, designers who care about semantic markup and compliancy and user's needs are torn between the two...

[BeeStar]

XStandard OS X version is currently in Alpha. It should work on FF 1.0+ and Safari 1.3+ on OS X 10.3.9+.

Wait a minute.  You mean you have a version for Windows and a version for OS X?  That's not what I call a browser based RTE! :-)

I remember vaguely, when checking out XStandard a year ago, that it needs to install something on the client's computer, hence the different versions.  If this is the case, it is a show stopper for me, even if the product looks very nice.

I am sorry.


Bee

[xwisdom]

Hi David,

Thanks for sharing this info with us.

I'm thinking of making RTE fields support four modes:

1) Source
2) Structure
3) Design (WYSIWYG)
4) Safe Preview Mode (no scripts)

When the editing a document the content field (or RTE TVs) will load in safe mode. The user can then select the source view, structured view (WYM if supported by browser) or Design tab.

The reason for this is that most RTE takes a very long time to load when editing a document. Plus it also allows the user to easily swicth between the varous modes thus giving them greater levels of flexible editing.

What do you all think?

[rthrash]

Vlad's solution is an actual browser plugin, so it should be very  fast to load.

[sottwell]

I like the idea, my partner wants the RTE and I hate it.  I'm always changing the documents to not use it, and he keeps whining about it until I change it back.  Even in "Source" I can't make it do what I want half the time, and that's why I do computers.  Unlike children, computers always do what you tell them to do.  I don't need somebody else going behind my back telling it to do something else!

[rthrash]

Hmmm... wonder if we could create a "null" RTE and load that for user settings...

[Bravado]

Hmmm... wonder if we could create a "null" RTE and load that for user settings...

Better said than done!  It's been mentioned before about allowing for a "textarea" only option so that an RTE doesn't load for a content box.  And, believe it or not, it's just one simple line to add to the core code. I'll be submitting this little addition for the next version, but in the meantime you can make the following change:

Go to the /manager/actions/dynamic/ directory:

Open mutate_settings.dynamic.action.php
Around line 800:

Code:

<?php
// invoke OnRichTextEditorRegister event
$evtOut = $modx->invokeEvent("OnRichTextEditorRegister");
if(is_array($evtOut)) for($i=0;$i<count($evtOut);$i++) {
$editor = $evtOut[$i];
echo "<option value='$editor'".($which_editor==$editor ? " selected='selected'" : "").">$editor</option>\n";
}  
?>

Change to:

Code:

<?php
// invoke OnRichTextEditorRegister event
$evtOut = $modx->invokeEvent("OnRichTextEditorRegister");
echo "<option value='none'".($which_editor=='none' ? " selected='selected'" : "").">None</option>\n";
if(is_array($evtOut)) for($i=0;$i<count($evtOut);$i++) {
$editor = $evtOut[$i];
echo "<option value='$editor'".($which_editor==$editor ? " selected='selected'" : "").">$editor</option>\n";
}  
?>

Open mutate_user.dynamic.action.php
Around line 825:

Code:

<?php
$edt = isset($usersettings["which_editor"]) ?$usersettings["which_editor"]:$which_editor;
// invoke OnRichTextEditorRegister event
$evtOut = $modx->invokeEvent("OnRichTextEditorRegister");
if(is_array($evtOut)) for($i=0;$i<count($evtOut);$i++) {
$editor = $evtOut[$i];
echo "<option value='$editor'".($edt==$editor ? " selected='selected'" : "").">$editor</option>\n";
}  
?>

Change to:

Code:

<?php
$edt = isset($usersettings["which_editor"]) ?$usersettings["which_editor"]:$which_editor;
// invoke OnRichTextEditorRegister event
$evtOut = $modx->invokeEvent("OnRichTextEditorRegister");
echo "<option value='none'".($edt=='none' ? " selected='selected'" : "").">None</option>\n";
if(is_array($evtOut)) for($i=0;$i<count($evtOut);$i++) {
$editor = $evtOut[$i];
echo "<option value='$editor'".($edt==$editor ? " selected='selected'" : "").">$editor</option>\n";
}  
?>

All this does is add an option to the "Editor to use" dropdown menu to allow setting the editor to "none", thus allowing just a simple textarea to be displayed instead of an RTE.  I found this to be handy since I do have times when I want to insert in code that would otherwise get messed up by an RTE. 

Another little feature I'll be adding in for the next version is the ability to switch between different RTE "modes" while editing a document via a dropdown menu.  Definitely will be handy in those times when you want a given RTE to be the default but want to switch now and then temporarily when you need a textbox or the like. 

[davidm]

@Raymond : about the 4 modes RTE, it would be great, yes !

@Ryan : I love the idea of per user setting for RTE

@Jeff : Thanks for theses code changes, will test that !

[rthrash]

David, you can already choose editors on a user-by-user case: Users > Manage users > User Settings tab > Editor to use