TinyMCE is focused on developers or web experienced users so that they know how to integrate it with their systems and pages. If you need a complete solution I suggest that you use a CMS system like Drupal or Joomla those have TinyMCE integrated as a module or in the core.
What would be really great is that if you were able to resize the table cells such as it's done in other WYSIWYG-editors such as dreamweaver.
If you manage that, you're golden. And of course, add something that keeps the PHP in the code and doesn't remove it. Could either be something like the init commands (extend valid_elements ?), plugins or even programmed in to the source, just as long as it works.
Anyway, I think that you all have done a really good job with TinyMCE and I personally considure it being THE best online editor.
There is a wiki about TinyMCE (even if basic):
We want to add <code><code> (for XML) through egroupware-wiki. Wiki using tiniMCE, and whenever we want to add <code> is removing automatically.
Please HELP to resolve this issue !!
RTFM: http://tinymce.moxiecode.com/tinymce/do … ments.html
Furthermore, don't post questions like that to this thread.
Either search the forums for an existing thread with this question or add a new one.
This thread is for future features only - not a helpdesk for the current ones.
Hi,
what I would love to be able to do is to separate the JS and the INIT portion on 2 different frames to load tinyMCE only 1 time.
for example, I have a big frame with this code ion the header:
<!-- tinyMCE -->
<script language="javascript" type="text/javascript" src="tinymce/jscripts/tiny_mce/tiny_mce.js"></script>
<!-- tinyMCE -->and then an inline frame with this code using "top" to reach the library:
<!-- tinyMCE -->
<script language="javascript" type="text/javascript">
top.tinyMCE.init({
mode : "textareas",
theme : "advanced",
plugins : "spellchecker,style,layer,table,save,advhr,advimage,advlink,emotions,iespell,insertdatetime,preview,zoom,flash,searchreplace,print,contextmenu,paste,directionality,fullscreen,noneditable",
theme_advanced_buttons1_add_before : "save,newdocument,separator",
theme_advanced_buttons1_add : "fontselect,fontsizeselect",
theme_advanced_buttons2_add : "separator,insertdate,inserttime,preview,separator,forecolor,backcolor",
theme_advanced_buttons2_add_before: "cut,copy,paste,pastetext,pasteword,separator,search,replace,separator",
theme_advanced_buttons3_add_before : "tablecontrols,separator",
theme_advanced_buttons3_add : "emotions,iespell,flash,advhr,separator,print,separator,ltr,rtl,separator,fullscreen",
theme_advanced_buttons4 : "insertlayer,moveforward,movebackward,absolute,|,styleprops,|,spellchecker",
theme_advanced_toolbar_location : "top",
theme_advanced_toolbar_align : "left",
theme_advanced_path_location : "bottom",
content_css : "/example_data/example_full.css",
plugin_insertdate_dateFormat : "%Y-%m-%d",
plugin_insertdate_timeFormat : "%H:%M:%S",
extended_valid_elements : "hr[class|width|size|noshade],font[face|size|color|style],span[class|align|style]",
external_link_list_url : "example_data/example_link_list.js",
external_image_list_url : "example_data/example_image_list.js",
flash_external_list_url : "example_data/example_flash_list.js",
file_browser_callback : "mcFileManager.filebrowserCallBack",
theme_advanced_resize_horizontal : false,
theme_advanced_resizing : true,
apply_source_formatting : true,
spellchecker_languages : "+English=en,Danish=da,Dutch=nl,Finnish=fi,French=fr,German=de,Italian=it,Polish=pl,Portuguese=pt,Spanish=es,Swedish=sv"
});
</script>
<!-- /tinyMCE -->Maybe some of the config could also be converted into styles in the TOP and we could do an INIT with a style. That would be rather fast! :-)
We could even have a cache process for the button images so when the init is done it would go faster.
Actually, there are too much self.document style of code in the library to be able to do it. I would suggest using a document object that we could pass in reference when doing the init instead of using the current document. Or maybe it could use the parent docuemtn of the object being initiated automaticaly.
Maybe it's already done but if so I don't know how to do it.
Paste from word is great except that most users will not know to use it. I propose a guess_paste_from_word : true flag that prompts tinymce to look for the messy classes or other telling word pasting ugliness and, when found, 'guess' that this is word and run the algorigthm on it.
Also, how about paste from PDF?
Great software. You guys are awesome.
Dave
I don't think paste from PDF would be possible from JavaScript.
Just for the record, something that's been bothering me for a long time is the fullpage plugin. gforce301 and I have discussed of potentially rewriting it as it seems to:
1) keep the header (<head>) data saved in variables even though the page is whiped clean (newdocument plugin or whatever).
2) It persists on adding and/or rewriting a header even to documents not needing it.
What we'll try to attempt is to only preserve existing headers and potentially do a cleanup of it. This way it can edit both document parts and full pages. This will eliminate certain problems with other plugins as well.
As when editing a php for example, when some code is located at the top of the page, the rewrite won't mess up the script. The current fullpage plugin probably will since some of the commands may be HTTP header commands or cookies. This will produce a bunch of errors and probably render the script unfunctional.
The second thing we've been discussing is visual editing of tables. We've been theorizing about it a bit but we don't know if it'll be placed on our agenda or not. The first priority is the fullpage plugin. Then we'll see weither we'll look into this thing or not.
well.. full XHTML validation would be great
Regarding the fullpage plugin, TinyMCE isn't meant to be a fullpage editor and its not the most common way of handling data, or the most practical. If you don't want the fullpage plugin to mess with the header, then don't use it and don't input the header to TinyMCE. Your backend should handle that part.
Hi!
TinyMCE is really cool and powerful.
Usually i use it to copy a text from anywhere to a website. And there's the little problem, which has said out by other already: more HTML cleanup options. Pressing the button "remove formatting" [or "paste without formatting" or "paste from word"] should open a pop-up where the user could choose if he wants to keep some of the formatting, for instance, color of the text, size of the text & so on.
Stay cool!
hi folk
- edit, add forms, textarea's and so on
- for a separate editor window, automatically resize of the tinymce editor..
- more table features: add table into table
- table cell properties.. the popup window is too small, language german
- ability to split each cell not only thoes who are combined before
and all other.. i think. tinymce is the fastest and best wysiwyg editor... 
see ya
thomi
Last edited by thomi (2006-08-16 11:21:19)
As I see it, the following items should be considered for a newer version:
* Support for entering UTF-8 characters (for e.g. oriental languages - this is really urgent!), maybe even with a clickable character table like the one already available for special characters; this table might be made switchable between different languages, where e.g. "Math symbols" might be just another "language";
* Possibility for the developer to remove certain buttons (if this is already possible, the documentation should be made better accessible!);
* Possibility for the developer to remove certain layout styles, to avoid the front-end editing user to mess up the original layout by choosing the "wrong" styles (if this is already possible, the documentation should be made better accessible!);
* Clearer documentation for developing plugins.
* Possibility for developer to enable or disable HTML-cleanup, including the possibility to tell TMCE to retain user-entered HTML coding it does not know itself;
* Consider a manual in the form of a single (or maybe two) PDF documents, besides the current on-line documentation.
Last edited by HHahn (2006-08-22 13:57:27)
Just answering some of my own questions... ;-)
* Support for entering UTF-8 characters (for e.g. oriental languages - this is really urgent!), maybe even with a clickable character table like the one already available for special characters; this table might be made switchable between different languages, where e.g. "Math symbols" might be just another "language";
Still urgent! I found that entering characters in the form of e.g. "&1490;" (without the quotes) is accepted. However, this is extremely clumsy if more than a few of them are needed. An extended version of the special-character map would be a lot better, especially if it allows preselection of certain character ranges (like "Math symbols", "Cyrillic", "Hebrew", "Arabic", etc.
* Possibility for the developer to remove certain buttons (if this is already possible, the documentation should be made better accessible!);
I already found it in the current version, but the documentation is not quite clear.
* Possibility for the developer to remove certain layout styles, to avoid the front-end editing user to mess up the original layout by choosing the "wrong" styles (if this is already possible, the documentation should be made better accessible!);
I already found it, but it seems to work only partially? Don't know inhowfar this might be due to unclear documentation.
* Possibility for developer to enable or disable HTML-cleanup, including the possibility to tell TMCE to retain user-entered HTML coding it does not know itself;
Is already there. A better index to the documentation might improve the "findability" of features.
* Consider a manual in the form of a single (or maybe two) PDF documents, besides the current on-line documentation.
...including a good index!
Support for forms and form elements seems to be the only major thing missing.
As for myself, I am not so aware of a major need for rich-text editing of forms. But if other people feel this is necessary, it is okay
However, there is indeed a great need for a decent user interface for entering oriental text. As I said, an extended version of the current "special characters" window would do, with the following additions:
* Selector for different character groups (based on languages, mathematics, IPA phonetic script(!!), special HTML entities (like , , ?, ?, ?, ?, ?) etc.
* An "insert" button that does not close the window. Unlike with math symbols, the user will usually want to enter a whole series of characters. So there must be two different buttons, for "Insert" and "Close" repectively (and of course a "Cancel" button).
I had another idea the other day:
When I selected a portion of text and then called some user interface window (like using "search & replace" or "insert table" button) the previousely selected text would accidentally be altered when I forgot to first click into the respective input field to set its focus.
How about adding some setFocusOnFirstenabledFormElement() function for popped-up windows?
Just my two cents.
Greetings from Germany,
Felix Riesterer.
After dealing with troglodyte knuckleheads a lot lately, I think an end-user help plugin would be priceless. Like a question mark to click that would cause the next button you press to popup a quick blurb about that button's function.
I suggest that the html preview window not be a pop-up, but instead just toggle the wysiwyg window to show the code.
Actually, the problem in IE is that when you use the one-image thing and you have something ontop of the background image as well as your caching off, IE goes nuts and reloads all images all the time when you move your mouse around, quite effective, if you want to kill your webserver instantly.
This is easily fixed by adding this to a .htaccess file in the tiny_mce folder assuming Apache is the server:
ExpiresActive On
ExpiresDefault A18000
ExpiresByType image/gif A2592000
ExpiresByType image/jpeg A2592000
ExpiresByType image/png A2592000
This will counter the constant reloading of images that IE does when images are manipulated with JS. I think it should be done, and at least be an option even if it is off by default.
Also, can TinyMCE do UTF-8 yet?
Also, can TinyMCE do UTF-8 yet?
This sounds like the point I suggested earlier on entering oriental text. There appear to be already some possiblities for displaying UTF-8 text, but entering the text is a nighmare so far.
stever wrote:Also, can TinyMCE do UTF-8 yet?
This sounds like the point I suggested earlier on entering oriental text. There appear to be already some possiblities for displaying UTF-8 text, but entering the text is a nighmare so far.
It works fine a.f.a.i.k. Since I've seen users from China, Middle east, Japan using the editor.
HHahn wrote:stever wrote:Also, can TinyMCE do UTF-8 yet?
This sounds like the point I suggested earlier on entering oriental text. There appear to be already some possiblities for displaying UTF-8 text, but entering the text is a nighmare so far.
It works fine a.f.a.i.k. Since I've seen users from China, Middle east, Japan using the editor.
Then apparently the documentation is insufficient.
I apologize if any of these are already available, but I've read the docs extensively, without finding a way to do them.
In addition to the 'content_css' option, you could have a 'content_style' option.
So, I'd put something like:
content_style: { font: '10px arial', background-color: '#eeeeee' }
And that style would be applied to the <body> tag in the tinymce iframe. Generally I use the css option, but I've run into cases where it would've been easier to just throw a couple extra style options in for the current page.
Keeping the tabindex from the textarea on the iframe would be nice, or at the minimum, having an option to pass in a tabindex. Also, allowing to not turn tabs into spaces in Firefox would be nice (it was mentioned in another thread, and its the desired behavior around here - IMO it's a big usability mistake to override expected behavior like that).
Being able to specify whether tinymce's onsubmit hook should come before or after existing hooks would be nice. We have a required field validator that was giving us grief because it would check the textarea before tinymce had updated its value. I had to do this hack to get it to work:
onchange_callback: function () { document.getElementById('content').value = tinyMCE.getContent('content'); },
Would be nice to just say something like:
attach_onsubmit: 'before',
I know there have been other things that I would've liked at different times, but they escape me at the moment.
If you'd like, I could try to whip up some patches for those options, but only if you're willing to include them. I've had too many times where I try to help open source projects and they simply don't care.
The ability to disable drag and drop :0)
You are not logged in. Please login or register.