Oh and if you copy a snippet call from resource repository, it probably has <!-- --> comment tags in it when you view the source..
"He can have a lollipop any time he wants to. That's what it means to be a programmer."
-
☆ A M B ☆
- 1,056 Posts
Quote from: Bravado at Jul 11, 2006, 10:35 AM
Doze, you pretty much have it right on the money. However, rather than using the valid_elements config setting, I think the extended_valid_elements config setting should be used instead. If you look at the plugin code, you’ll see a line like this:
extended_valid_elements : "a[name|href|target|title|onclick],img[class|src|border=0|alt|title|hspace|vspace|width|height|align|onmouseover|onmouseout|name],hr[class|width|size|noshade],font[face|size|color|style],span[class|align|style]",
It’s pretty easy to figure out what’s what on this line. To add support for the "rel" attribute for "a" tags, you could simply add in the "rel" attribute to the the part of the line dealing with anchor tags (a[name|href|target|title|onclick|rel]). Just modify the code like that and you should be set.
Probably what I’ll do for the next revision is add in the valid_elements config setting to where just about every valid element in the XHTML specification is covered. That way we won’t have a bunch of elements constantly being replaced on users.
More to come....
Jeff
Ahh..that would explain why my ID attributes were being dropped from UL/OL ... hmm..somewhat frustrating to have to do this, but I can also see this as being a very useful feature.
Heh heh...yeah, it can be a bit of a pain. In the process of updating the plugin, I’m placing a variable for this at the top of the plugin code for easy editing. I found trying to add this variable to the plugin configuration was quite difficult so...I just placed the variable at the top of the code since, in all likelihood, not very many people are really going to edit this code very much...if at all!
I’m coming along quite nicely on other things. Alot of issues that have been brought up are being address upto and including custom button assignments, plugins, formats, and other customizations. I’ve also added styles and formats to the Advanced theme and will allow for quite a bit of customization to the Full Featured theme. Should be enought to make everyone pretty happy for now.
Jeff Whitfield
"I like my coffee hot and strong, like I like my women, hot and strong... with a spoon in them."
anybody has setup 2 instances of tynimce?
i couldent do...
I don’t know what you want to achieve but you could see how it’s done by doing this:
Setup a TV with the RTE widget, assign it to a template and then edit a page with that template in the manager. You should now have an instance of tinyMce for the main page content and an instance for the TV.
Have a look at the source of editor frame and perhaps that will give you something to start from.
The TinyMCE archive contains assets and install folder. You need to FTP those on to your MODx site root including all paths.. So Tiny MCE files should end up in /assets/plugins/tinymce
"He can have a lollipop any time he wants to. That's what it means to be a programmer."
-
☆ A M B ☆
- 1,056 Posts
Quote from: doze at Oct 16, 2006, 10:11 AM
The TinyMCE archive contains assets and install folder. You need to FTP those on to your MODx site root including all paths.. So Tiny MCE files should end up in /assets/plugins/tinymce
So...is TinyMCE vs. FCKEditor simply a developer’s choice? Or, are there any serious considerations one should make before leaning one direction vs. the other?
Having never used TinyMCE, and primarily FCK till now, what are some reasons I should consider switching, etc?
(apologies if this is better suited for an alternate board...)
