Does this look familar to you?
http://confluence.atlassian.com/display … r+Overview
Gues what is "rich"? TinyMCE of course 
.
Doing a simple "View Page" on their demo in edit mode, one can find code like:
tinyMCE.init({
mode : "exact",
elements : theElements,
//dialog_type : "modal",
width: "100%",
height: "480",
....Isn't that familar to you?
Ahmed.
It doesn't run TinyMCE, it uses that stupid wiki syntax (omg! who came up with that btw?!).
Sorry, but that "stupid syntax" IS wiki. If you take that out, it's no more a wiki but a CMS with many users.
My demands:
1) Should store data as standard HTML/XHTML (doesn't need to have tinymce by default).
2) Should be "exportable" to more read-friendly / read-only documentation.
3) Decent layout / gui, im not to impressed with any of the "larger" Wikis out there in terms of layout.
4) Template system, if the gui sux, atleast its possible to change it without hacking backend code.
Try
http://www.cromoteca.com/meshcms/
It was one of the first CMSes based on TinyMCE 
.
It is the simplest possible and it has documentation - very seldon in OS projects .
Ahmed.
We have been thinking of starting a Wiki for ordinary user documentation (non-technical). Just haven't had time yet. And we can't find any good Wiki that runs TinyMCE out of the box!!! Might have to make our own Wiki
No, there's no need to make Yet Another WIKI.
Since TinyMCE is an opensource project, is eligilble to get a free license of Confluence:
http://www.atlassian.com/software/confluence/
AFAIK it's the most advanced and easy to use WIKI.
Ahmed.
Nope I saw that, thats not what im looking for. That manual is more for the developer installing tinymce. What im looking for is a manual i can give to my clients that will tell that what each button does.
There's a help button on your TinyMCE bar. That opens the "user help". Unfortunately since 2.0.x it's covered with the "about" tab so it's not as obvious as before.
It would be nice if the help Tab would be the first, so that users find it right away.
Ahmed.
I can't find the form "patch" mentioned on Sourceforce - looked in patches and plug-ins. Is is still there??
Yes, it is still there. It's called Form Plugin.
Here's to URL, to find it for sure:
http://tinyurl.com/au9m6
Ahmed.
Hi guys,
The div plugin is back to life...
Every feedback is appreciated !!
Few questions first:
1. What exact version of TinyMCE do you target? This would be important to avoid suplemental problems due to "unsync" between TinyMCE and the plug-in
2. Why don't you just use the Plug-in tracker from Sourceforge like every other project? That's where most users expect to find plug-ins.
3. Back for good ? .
Thanks in advance,
Ahmed.
I know a GREAT alternative, but it will cost you a few dollars, surely worth it...
This is what TinyMCE needs a "REAL" sourcecode editor with syntax highlighting for PHP/HTML/JSSimply amazing, test the demo !
I'm not affiliated with them, it's just my humble opinion, give it a try.
Well, the screenshots are, but if I try it I'm getting errors in the browser even if the version I'm using is supposed to be supported.
Also on a normal ppp connection is totally unusable (many users of the CMS still have such connections).
Also have you just monitored the traffic that application generates? Too high IMHO.
The responsiveness is one of the main requirements for an editor, and this app is everything else but responsive.
It was so last time I tested it and it's so now - that's why I didn't even proposed it to you to try it as an example.
An alternative to using copy and paste in a full blown IDE would be to use an RCP chanel, so that the IDE can work autmaticaly on that "to edit" content. I haven't managed to achieve this with Eclipse, only with a small plug-in for IntelliJ. If I'll be able to configure Eclipse for that I'll post how can it be done.
Ahmed.
Could you imagine using part of tinyMCE's functionality to create a similar thing?
While I would also highly appreciate such a functionality, IMHO the TinyMCE team has many other much more important things to concentrate on(as they already mentioned on these forums).
There are also a few arguments against such a feture in TinyMCE:
- it adds another layer of complexity in a place considered "uncomplex".
- it removes the "last chance" to se "What You Really Get" when the browser goes crazy and the WYSIWYG does not behave as desired (this happens more ofthen that one might think).
- TinyMCE WYSIWYG is mostly made for "users" (at least most of the "users" of CMSes have no idea of programming, nor HTML), and only very few of them use that functionality at all.
So, IMHO, where it would be nice and look cool, it would not be worth the effort.
There are other many features that would be usefull for more potential MCE users.
What do you think? In my CMS I added a second code editor for additional CSS code, so this syntax highlighting feature would be a great benefit! It could also lead to some better HTML code layout in the main editor... ;-)
IMHO if one still wants such a funtionality, it should not be in TinyMCE, but as a separated project, independent
of TinyMCE. If you feel that you can, you could help improve the highlighter you proposed so that it's not that buggy and integrate it as a separated thing.
I already used (and saw in other projects - so it wasn't my idea ) a similar approach:
1.- in the FileManager/Browser or Menu from where one would call the WYSIWYG, add an extra entry: "Edit as Plain Text".
2.- allow this only for advanced users (and admins) so that simple users won't mess the site up - not even by mistake.
3.- now this "editor" should/could be enabled with hightlight since it can edit CSS/JSPs ,etc.
I did the above approach and after a while I always reverted #3 back to a normal textarea because the editor highlighter you mentioned is not reliable enough and pretty complex to be able to improve it from my point of view. Everything I tried to improve on it, was not enough. I such cases when one is not using the WYSIWYG to edit CSS and JSPs (and somethimes to clean up HTML), reliability is much much more important than other fancy highlight.
If highlight is is still very important, I do a copy and paste in an intelliget IDE like IntelliJ IDEA and there I have not just highilight but also "live inspections", "completion", "error checking" etc. (I suppose no one wants to build on the Web what desktop IDEs can - since this is hard enough on the desktop).
Ahmed.
If someone makes a plugin, and need smaller changes to the core in order to make it work, its something that can be discussed.
Please see my first post (better said that plug-in from the TinyMCE sourceforge plug-in repository).
Just try it and have a look over the code. I suppose you are better suited to tell if it's worth or not more than us(causual TinyMCE users).
In any case, it's much much more than nothing.
Also consider that the conccurence HAS Form support in their WYSIWYG. This(and a few others) is the main reason it was choosed over TinyMCE in many projects I worked(despite my protests).
Personally I like TinyMCE much more, but as a developer one needs(must) to "just do the job", not reinvent the wheel(aka a new Form plug-in for TinyMCE since the conccurence has it).
That's why I think the From plug-in should be delivered (integrated) with TinyMCE as well as the DIV plug-in.
Everything else (like Safari support, more buttons, better cleanup strategies, etc.) might be nice, but woudn't bring an effective advantage for the adoption of TinyMCE(of course, there's much lobby for them, but the reality looks different when one is looking at the percentages ).
Not so with the two mentioned by me plug-ins.
Thanks in advance,
Ahmed.
Yes I meant the visual aid! Perhaps there are more excentric people like me who don't want to insert divs with background-color and border-color? :-D
IMHO visual-aids for DIVs (like it's done for tables) wold be very imortant.
In most of the cases one is just wrapping something with a DIV and gives it a predefined class from the css (and not specifies aditional attributes and properties) or just an ID . AFAIK this is the most used scenario and IMHO this must be covered first and very efficient.
Of course some of the DIVs will get special formatting like borders, etc. but in all sites I worked with, this was only for 10% of the divs. IMHO even for these 10% DIVs, extra visual aids (layed over the original DIV) would be useful, if one is making an error (choosing bad colors) and not being able to find the DIV again.
Question:
I observed that you used webfx TabPane. Why?
Isn't the TinyMCE tabpane good enough? (utils/mctabs.js)
Thank you for the nice plug-in,
and keep up the good work,
Ahmed.
P.S. Can't wait to test the next versions of the DIV plug-in .
Hi,
For the advanced theme, if I remove all buttons from button line 3 (with "theme_advanced_disable") and move some of them on button line 2, the button line 3 is still displayed and it has two separators.
Is it possible to remove them, so that button line 3 dissapears completly? If yes, how? I coudn't find in the documentation something about it.
Thanks in advance,
Ahmed.
It is something we have been thinking about, we have a lot of small scripts and clever solutions to common problems that would benefit others. There is some work involved in writing documentation on them if we wish to release them in a more "standalone" version. We are going to develop a new site soon that will give us more space for things like this. During next year we will bring out a lot more of these scripts to be used by others.
Thank you.
This sounds fantastic .
Can't wait to try them .
Ahmed.
Hi,
Some of the javascript files delivered with TinyMCE are totally reusable in other projects that need javascript too. E.g. utils/mctabs.js and utils/validate.js. (form_utils.js is not TinyMCE independent however).
Would it be possible to make more functions (in files) general and independent of TinyMCE?
One that would be required in almost every project out there : tiny_mce_popup.js
The graceful handling of popups "a la TinyMCE" could increase the quality of many applications that have ugly and error prone local workarounds.
Of course, users could hack those interesting functions, but would not benefit from updates (unless they do the entire work one more time).
IMHO this would also increase the usage of TinyMCE, since that way many more projects would use it (also for those javascript utils).
Thanks in advance,
Ahmed.
Hi,
I suppose there's no one interested by my plugins, so I've decided not to release them to public.
Of course, there is interest, but it's very hard to judge from those "reduced sized" screenshots how are they supposed to work. I can't even really see what's there 
Most of the plug-in developers release them to the sourceforge patch system, with install instructions, and than put a message here and get feedback (even if the plug-ins are beta).
The "visual DIV editor" is really needed IMHO since there's no other way to do this with TinyMCE, and to be a real HTML WYSIWYG, it should handle DIVs too.
The "Table, cell, row enhanced dialog & functions" should go IMHO directly into the Advanced Theme of TinyMCE, not as a separate plug-in.
The "TextToImage processor" is not clear for me how it works. Doesn't it require a server part? If it requires, is it working with Java/JSP?
Thanks in advance,
Ahmed.
Funny how everyone has their own version of what would make TinyMCE the "best" or most "complete" WYSIWYG editor, form support, templates...
I don't think they are exclusive. Forms, better "list styling support", DIV support are all clear parts of HTML so IMHO a HTML WYSIWYG should try to cover them . The best part is that many of these 'user requests' already exist as patches on sourceforge, so IMHO those plug-ins that exist, should have somehow a higer priority than those request where nothing exists, but the idea .
It will probably not be in the core, there are way more important things to take care of and I personally think its weird to use a WYSIWYG editor to build html forms.
IMHO it's not wired at all:
- most CMSes need forms (at least for feedback, if not for questionaiers, et. co)
- there's no idependent web based tool that can be used by non-programmers to make forms.
- existing tools(most of them not web based) that help at a degree to make webforms(even if well made)
- are more for programmers
- totally forget the WYSIWYG aspect of a form, so the forms can't be made nice, in the same way one can make the pages.
- can't be really integrated into CMSes.
- many of them require installation.
- many web pages require HTML controls(also mostly for CMSes), but without a serverside logic in many cases:
- 'Select' boxes with an 'onChange' with a simple "window.open(this.value)" in it, to reduce the displayed link number (this is the most common required control in simple pages without
- Check boxes that trigger/enable buttons for agreements, etc. (this also does not require programming, and could be done from the WYSIWYG since 99% of the page is nice formatted text.
- in the case of pages that require some server side logic (e.g. mail forms, questionnaires,etc.) those actions already exist (their URL) so the user would only need to "bind" that URL.
So as you can see, exactly how TinyMCE as a WYSIWYG (with it's advanced theme) is more suited for (it's targeting) CMSes than other software, so do need CMSes Forms too (and the forms to be made by the same users that can edit the pages).
Also I didn't ment "in the core", but "in the main distribution" as a plug-in .
All the above activities could take from a user perspective only a small amount of time (and this from simple users), if the WYSIWYG could 'understand' forms too.
Thanks in advance,
Ahmed.
Hi,
Are there any plans to deliver with TinyMCE the From plug-in that exists in the sourceforge patch?
IMHO the possibility to edit Forms in TinyMCE is that what is missing to be a "complete" WYSIWYG, and that plug-in does the most of the work (even if it would need some polish, and some small errors corrected).
Also the exaple_full.htm should have the form plug-in activated as default so that new users can see right away the TinyMCE can do forms too .
Thanks in advance,
Ahmed.
I'm looking for a simple non-database driven CMS to allow editing of HTML files. Basically something that has a very simple backend where the user would select which html file to edit (display contents of the html directory or something like that), then allow the user to edit and save the html file using TinyMCE.
MeshCMS is very simple:
http://www.cromoteca.com/meshcms/
It's one of the first CMSes that started to use TinyMCE.
Ahmed.
You can allways make a wrapper. Forexample a php file that includes all the styles you want and then include that php in content_css.
Sorry, but this is just an ugly hack.
IMHO, it should work with multiple css files 'directly on the client side'.
Even more, the entire CSS support must be improved, to allow the selection of styles based on their context - so an intelligent CSS styling.
Ahmed.
Is there any other editor out there that loads faster than TinyMCE? And has the same functionality/flexibility.
This is not the point. Just because the others are bad, it doesn't mean you can't improve user experience.
Our users open and close very offen the WYSIWYG and their main concern was that only the WYSIWYG was slow from the entire application.
The included PHP file compresses the scripts down to around 45-50kb, thats quite reasonable in my opinion.
Yes I know that compression is one step to do, and there are tones of tools to do this (see thread on these forums), but TinyMCE does not consist only of tinyMCE.js .
It might be a bad idea, but maybe separating in tinyMCE_Moz.js and tinyMCE_IE.js would reduce a lot. If you look in the code in a lot of places there's : 'tinyMCE.isMSIE'. If the two would be splited than there would be need only for one of that sentence, not to mention that only one of those 'half files' would be used
(If scripts seem to load slow on our server, its probably cause of our connection, or yours).
This is on our servers too, and it has nothing to do with the connection. The total loading time(from a user perspective) it's the time till the entire WYSIGYG is rendered in a 'usable form'.
So maybe the preceived perfomance it's not only the size and the connection, but also what's executed until the WYSIWYG is ready .
Thanks in advance,
Ahmed.
P.S. We always used the advanced theme (and the most of the users use it also), so... .
IMHO, the future releases should concentrate on the followings:
1. Performance and loading time (as of the actiual version it takes too much to load) (maybe to split the IE and Mozilla code in 2 files would reduce what's to load to 50%)
2. Better and smarter CSS support: allow diff type of selectors based on thier context only(this would be the killer feature )
3. Document the sources and explain the functions with JSDoc: http://jsdoc.sourceforge.net/ (this won't be a problem for the size, since this should go only in tinyMCE_src.js, not in the 'obfuscated' file.
4. Spell checker for Mozilla: on the sourceforge there was proposed a solution that works with Mozila/FF on in the browser only. IMHO even if it's not perfect it's still better than nothing, since for IE there's one allready. Solutions that require serverside work shouldn't be considered cause everyone is using a diff. platform.
Ahmed.
It works in Firefox on Mac, we even took care of some minor bugs on that browser as well, so yes, it is crossplatform.
IMHO this 'feature' should deserve more marketing .
Ahmed.
Without some major updates to the Safari code we have trouble seeing TinyMCE functioning fully with Safari. We will do more extensive testing when we have time, and perhaps get some basic things working.
Have you tested if it works without problems on Mozilla on MacOSX?
If yes, than TinyMCE is 'cross platform' , since everyone can install Mozilla on his Mac too (the same way as Windows users drop IE and use Mozilla).
Ahmed.
Thoughts? Suggestions?
IMHO, NO . If there is also a commercial license, people will get more confused than they are, and you will bring even more questions about it.
We've seen this even in our team with opensouce projects that had commercial license - just discussions and discussions.
IMHO there should be a license like: 'Take it and shut up!' , cause the license around discussions are just a lost of time, considering that they don't even have a legal ground in most of the European countries.
Ahmed.
Hi Spocke, would it be possible to include the uncompressed .js each time in the cvs to understand better the changes.
AFAIK they are there: always with '_src.js' extension.
Ahmed.
Hello everybody!
I just wanted to say that the scheduled release date for 1.44 is set to 2005-05-01.
Thank you.
After this release we will focus on Safari support, full screen mode edit, better CSS support (have promised this a long time now)
IMHO, the CSS support should have the much higer priority since from this would benefit everybody. Safari support on the other hand will help only a few from the user base (even if they are always very loud and one gets the impression that a lot of users have this problem - but if one looks at the weblogs, the situation is totaly different).
and making the source editor a "switch mode" function instead of a new window.
Please don't make it "switch mode". It will just make TinyMCE look exactly like FCKEditor or HTMLArea.
IMHO is very good that the "source mode" is in an extra window, so that the user is very careful editing code by hand. Having it in an extra window, makes it even possible to offer some degree of code highlighting(I was experimenting with it and it looks good).
Thanks,
Ahmed.
You are not logged in. Please login or register.
