You can find a resume of this in the next post
After testing TinyMCE, CKEditor and SCEditor the team (me and EXreaction) have decided to keep SCEditor.
The rationale behind it is that:
TinyMCE -> The BBCode plugin is too buggy, incomplete and the code is not easy to read, the text editing mode disables all BBCode buttons.
CKEditor -> The BBCode plugin is too buggy and incomplete. It would take a fair amount of work to fix it, the text editing mode disables all BBCode buttons.
SCEditor -> The BBCode plugin is mostly complete, works quite well, I only know about 1 bug so far which is probably easy to solve, allows us to add BBCode in a very simple and working way, the text editing mode allows to keep all BBCode buttons enabled.
Now, we have to think which problems we need to address to make an, at least, acceptable WYSIWYG editor.
To solve that, we've investigated multiple BBCodes that are free and made made for phpBB we found out there in the W3 (AKA WWW).
After we've made the investigation until this far we came up with 5 points we just cannot ignore in order to make a proper WYSIWYG editor for phpBB.
1. There's the need to exist a separate textarea for the HTML replacement specially made for the editor (no viable replacements for this are found) in the ACP in the BBCode module.
The reason behind this is quite simple. There are BBCodes that (YMMVAPD) require to appear slightly different in the WYSIWYG editor than how they appear in the final version even if we are only talking about changing minor stuff.
The most notable BBCodes I found that make this really looking like a must have were the youtube BBCode and the spoiler BBCode.
We also came to the conclusion that there can exist admins that, for certain restricted BBCodes, just want to use the same way as they are currently used, without any formating change in the WYSIWYG editor itself.
The advantages of having this extra are huge compared to the disadvantages so we agreed that this should be a must!
2. The editor already has loads of replacements installed that uses the browser's internals to apply 'em. Maybe we could take advantage of that.
I don't really know what the dev team of phpBB thinks about this, anyhow, it's true. The WYSIWYG editor uses the browser's doCommand() method to apply many of its predefined actions of its buttons Something that is native is usually good and for all browsers phpBB supports, in my tests the behavior was really great in all browsers phpBB gives support to. The idea behind this is a discussion is to conclude what should we do about this information.
We could make more BBCodes to match all or some in the editor, we could just ignore 'em, we could make some kind of "vodoo" (
) detection and use it in the replacements when the BBCode is meant to do the same as the custom BBCode... Other options may appear.3. There are BBCodes that cannot be altered or it is unavoidable to alter while in the WYSIWYG mode.
A "changeable only in BBCode mode" button may be a good option as it provides better, more reliable way to go from the WYSIWYG mode back to the BBCode mode.
I don't really know about how much strength should be given to this thing but, certainly, it can allow more precise and new browsers work proof when going back and forth between the WYSIWYG mode and the text editor mode as no real HTML parsing is needed at all.
4. The order of the infos may not be the same. Save the order as they appear in the HTML vs the order they appear in the BBCode.
E.g.
[abc]uio,huh,ui[/abc] -> <span title="ui"><b class="huh">uio</b></span>
This is a stupid, yet valid example of a possible BBCode the system may have to deal with one day or the other.
To solve such problem one idea is to obtain the order they appear in the HTML vs the order they appear in the BBCode. This can easily be solved using a simple array to associate position in the HTML -> position in BBCode. The other way around is always trivial in every single test we've made.
5. There can be repeated information from the BBCode towards the final HTML.
If it's changeable, which one should be used when going back to the original BBCode? Which one was the one the user was able to change while in the WYSIWYG?
If the user was able to change both, only one counts, right? So just looking at the one that changed from the original is no option.
Alternatively, if we keep both in sync there's no questioning about which one contains the correct information.
E.g.
[titled]{text}[/titled] -> <span>{text}:</span><span>{text}</span>
[titled]I towt I saw a pootycat[/titled] -> <span>I towt I saw a pootycat:</span><span>I towt I saw a pootycat</span>
Another silly example with a properly valid BBCode. This is another problem that we'll need to prepare for. When there are two matches in the HTML side for a token in the BBCode side. How to solve this?
I came up with the idea of using a prefix in the token. Something like {C_*} (E.g. "{C_TEXT}") in which, this one would be the one that is meant to keep and the other is meant not to keep. Even if it's changed, those changes are ignored for the {TEXT} and only the {C_TEXT} is taken attention when going back to the BBCode.
EXreaction came up with a different idea. His idea is to use javascript to keep all off those in sync. Sounds good, no? Well... not really. To have that working, we'll need to be prepared for our "friend"IE8. Yes... IE8 (I won't repeat myself, just read it below) (...). So... We can then question ourselves... how to do this? Well... if we change the source code of SCE and prepare it for IE8 in such way that we override the copy of the current block element to do the new line into placing a <br> (or it's xHTML counterpart) we may have this made easier. Another problem... How should such code work? I'll leave that question opened.
EXreaction Also came up with another possible solution which is to use HTML comments to delimitate where are each of the informations needed for the BBCode.
Another subject that makes sense to discuss is to make a verbose mode. Well... It wouldn't be actually a "mode". It would be 4 extra textareas, hidden by default, that would be used such way that the user may completely personalize the behavior of the BBCode to HTML translation and back and also to personalize what happens when a button is pressed. With this one could even do a modal box to request additional information from the user and not just use the possibility of selecting the text and place it between the tags. Multiple formatting is possible and possibilities ate limited only by the limits of HTML and javascript itself.
SCE uses images for its buttons. Actually, it uses the background-image for each and every button (bold, italic, etc..., not forgetting the advantages of sprites).
This means that custom BBCodes will need to have an image or there's a need to generate, somehow, an image automagically for a custom BBCode.
To make one automagically, there's no need to go far. Just use the text of the tag and place it over a predefined image and there you have it.
Otherwise, the user is able to upload an image meant to be used for the button for the corresponding BBCode.
What do you think we should do? Create an optional input@type=file such that if the user sends a file, if it's an image, it is used otherwise an automagic image is generated?
A problem... Our "friend" IE8.
IE8 has a noticeable bug that is specially noticed every time you use enter in your code and it just uses a copy of the current block element to mark the new line. There's a way to tweak that. Just need to take some crack (everybody knows that you need to be on something in order to have the patience you need to do something just for IE) and hammer the keyboard to cook something that removes the differences between IE8's trident and the other one's browser engines.
This is all that I can remember that is needed to keep you guys updated on the current status of the WYSIWYG editor for phpBB. I'll edit this post as I remember of extra stuff that may be useful for the area51 users I'll edit or post an extra post with the extra information.
