Sure, I would love such a functionality - but is it reasonable to expect it to appear in TinyMCE, or should we let the developers focus on the core itself. If we look at the typical user of a CMS (People like me who are looking for functions like pagebreak are, in my belief, all persons using the WYSIWYG in our CMS), so the typical user is a person who doesnt know alot about HTML, probably nothing (If he knew HTML, he would probably use raw HTML, BBcode or MarkDown for optimal control in theese XHTML days). So what does a typical webpage in a WYSIWYG rendered page look like? It could be one table surrounding the entire page which is, say 5 pages long, containing 4 pagebreaks.

This would mean that we would make the Moxiecode staff spend a heck of a lot of time for this "seemedly" easy plugin to accually rewrite the entire code of the page to work with the pagebreaks (Or this is probably where our own serverside system gets to work), we can't just do what Mambo did (again, maby they solved this lately, I havnt checked), assume that the person using the WYSIWYG is not using the plugin wrong - after all it's WYSIWYG so people tend to do alot of wrong things (Did I mention paste from word and other websites, even if told otherwise)...

Lately I have spent more and more time using TinyMCE, but I would like to share my 2 cents here to be sure that the development is going in the right direction, and not focusing on messy plugins which will hault the development unneccesary. After all the developers are doing a great job on this free tool, and it doesnt hurt if we support them once in a while instead of always demanding new functionality all the time. Finally, as hstraf mentioned, if you really like this plugin to surface the people at Moxiecode will more than happy (ugh... As George Carlin mentions this is a pretty meaningless condition, hehe) spend time developing it for you if you are willing to pay for it.

Looking forward for the next release of TinyMCE, I will need to upgrade alot of users again... Keep up the good work

Mvh,
Kim Steinhaug
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.steinhaug.no - www.easywebshop.no - www.easycms.no

It is also worth noting that the folks from Moxie are happy to develop any CUSTOM features if you really really needed something.  (http://tinymce.moxiecode.com/plugins.php - look for the "custom plugin development heading)

I will have to aggree with jojodee that this will have to be treated as a CMS specific implementation. If I where to add this as a base functionality for TinyMCE it would only be useful for systems using this approach to produce pages. In my oppinion is not a efficient and ideal solution anyway, it seems to be a quick and dirty hack. We did a simmilar thing for postnuke once.

And if we where to add this to the core it would have to be smart in two ways. It would need to be placed after paragraphs and out side tables so they don't break and they would need to be visible so users can remove them simmilar to the anchor elements. And that kind of functionality isn't done right within a coffe break.

I think the best way of doing this is to produce some kind of code snipplet plugin so it would be possible to inject any custom content within visible containers since diffrent CMS systems implement these page breaks or simmilar snipplets in diffrent ways. But this will have to wait for the 2.0.1 release, we must first get the 2.0 stable and out before adding more functionality stability is far more important than cool features.

Although many have found this xaraya plugin to be useful, it is more complex than it seems unless you can ensure that 'html unaware' users understand where the pagebreak should be inserted in their page.... or you make the plugin 'intelligent' to allow it to know where in the code it should go for proper markup (eg not between a set of <p></p> tags for example).

There are posts even here requesting help (where people are trying to create this function on their own) yet those posts are still open.  On top of that, solutions like Mambo have tried (hap-hazardly) to add the function in, but it is using an image type feature to pull this off and the function only works in one place designed specifically to look for that specific image tag to interpret it and convert it that way.

The bottom line is that 2.x should include a standard pagebreak button that would inject the code and be an allowable definition (if added as such).  To think that you folks could do all of these other functions but not create a standard pagebreak is just nutty.

Just my 2 cents

I've been thinking of rewriting the whole cleanup process so it's more efficient. But cleanup of long HTML chunks will always be slow in javascript since it's a script language. But I guess a rewrite would make it a lot faster. A server side cleanup is alot better and safer too since then it would be impossible to "inject" elements that isn't valid. We have been thinking of adding a backend API for PHP and .NET. A PHP class and a .NET webcontrol but we haven't got around to do it just yet. Such backend logic could be equipped with a serverside cleanup routine compatible with the valid_elements format in TinyMCE and would be a lot more efficient since we could then SAX parse stuff etc.

spoke,

I was just re-reading this thread, and got to thinking that if you're going to write a server-side cleanup routine in PHP and .NET, you may be able to use AJAX to communicate with it.  Not sure if it's necessary, but it may come in handy if you wanted to do a cleanup without a round trip to the server.

No, since this is a major change and will most likely not be stable in the first version I will not be able to include it in the 2.0 version. I could make some effort for it in 2.0.1. Anyway, I think this whole problem can be avoided by using the theme_advanced_styles option. If I where to make a more complex CSS handler I would need to rewrite lots of code since this parsing is somewhat complex. I should also move this into a own plugin or similar since the code will be quite large figuring out all possible combinations and so forth.

The patch is not in fact very big and does not introduce any new features, it merely corrects a couple of problems - it brings the style sheet processing of Firefox closer to that of IE and it eliminates duplicate class names from the selection list (both bugs IMHO).  The other things that were mentioned are not addressed by the patch (either they not been implemented or cannot be implemented).  If the patch did anything more than I have described here I would certainly not be pushing for it to be included in 2.0 final.

Moving the CSS processing into a plugin is a good idea as it would make it easier for people to replace the code with something as simple or complex as they would like.  Ultimately I want to be able to control which style classes are presented depending on the selected element - no doubt only some people will want this so pushing it off into a plugin makes sense.

The CSS I am dealing with is not in fact overly complex.  I can see that using a trimmed version of a style sheet while editing might solve some problems, but not I think the ones addressed by the patch.

This does not address the issues as elegantly as the patch.

Keep up the good work!

Scott

Good luck with final version 2.0, I loved the previous one.
Donadoni

Final stable releases are needed for all the CMS systems out there that use TinyMCE, they need the stable versions for integration.

No, since this is a major change and will most likely not be stable in the first version...

Why don't you go on with Release Candidate 4, 5, 6,... until the 2.0 is stable enough before go for real 2.0 version.

Use this for now, or make a timmed CSS for while editing and use your more complex CSS while presenting the page this is how we do it our selfs since complex CSS:es with floats and all kinds of custom things can break the editing experience.

http://tinymce.moxiecode.com/tinymce/do … tyles.html

I would be grateful if 1323835 could be committed.  There are numerous other patches over on SF - will these be examined prior to 2.0 final?

Thanks,

Scott

hstraf wrote:

ie:

echo value_bold("true");
echo value_italics("false");

And then bingo... it would spit out the required javascript for making this happen...

umm... If you already do all in PHP creating your own quick PHP API wouldn't be to much work. You could easily create your own little tinyMCE class which takes care of all the JS config. Or, very simpliefied if all you need is to move the JS out of the PHP files, just move it into some functions library that you probably have with some "echo" statement. Atleast you have all the JS gone.

I know we could do it.. but I'd rather have the coding done by the good folks from moxiecode, since then they would be responsible for maintaining it, updating it with new functions as they arrive, etc...

ie:

echo value_bold("true");
echo value_italics("false");

And then bingo... it would spit out the required javascript for making this happen...

umm... If you already do all in PHP creating your own quick PHP API wouldn't be to much work. You could easily create your own little tinyMCE class which takes care of all the JS config. Or, very simpliefied if all you need is to move the JS out of the PHP files, just move it into some functions library that you probably have with some "echo" statement. Atleast you have all the JS gone.