I somehow can't get tinymce into calendar the way I want to... And Christophs Wiki explanation is not fully understandable by me
![Sad :(](./images/smilies/icon_e_sad.gif)
Code: Select all
init_editor(array('description'),'minimal');
svasti
Code: Select all
init_editor(array('description'),'minimal');
I suppose I wouldn't fully understand it either, if I hadn't written it myselfsvasti wrote: And Christophs Wiki explanation is not fully understandable by me
In this case you have basically two possibilities: (a) require the user to install a file init_calendar.js to plugins/tinymce/inits or (b) use editor_replace() with an explicit call to init_editor(). I'll begin with explaining (b), to show it's drawbacks:svasti wrote:as calendar needs a very specific configuration (actually even two) together with a special skin.
Code: Select all
include_once($pth['folder']['plugins'].'tinymce/init.php');
include_tinymce();
tinymce_filebrowser();
$config = '...';
tinymce_replace('CALENDAREDITOR-ID');
Code: Select all
include_once($pth['folder']['plugins'].'tinymce/init.php');
init_tinymce(array('CALENDAREDITOR_CLASS'), 'calendar');
what about a CMSimple-academy? Just 1 week of learning the whole stuff? We all come and visit youcmb wrote:I hope these explanations somewhat clarify things.
Code: Select all
init_editor(array('CLASSNAME'));
Well, even that could be done without too much additional work. You might have a look at plugins/tinymce/init.js tinyMCE_instantiateByClasses(). That's basically what does the trick. And it even works, if the textareas have no IDs at all -- they're given a unique ID dynamically!svasti wrote:and calling the textareas by ID is kind of unpractical in my case
I guess, I have to learn very much for myself first. I'm still struggling somewhat with implementing editors as plugins -- that's even more baffling, particularly when it comes to coupling editors and filebrowsers.svasti wrote:what about a CMSimple-academy?
AFAIK that's not possible by default with CK / FCKeditor and we have to code something like tinyMCE_instantiateByClasses() for CKeditor.cmb wrote:Well, even that could be done without too much additional work. You might have a look at plugins/tinymce/init.js tinyMCE_instantiateByClasses(). That's basically what does the trick. And it even works, if the textareas have no IDs at all -- they're given a unique ID dynamically!
Why? You need in both cases a <textarea> and, if you need more than one editor at the page, unique selectors.svasti wrote:and calling the textareas by ID is kind of unpractical in my case, so I'd rather avoid that
Code: Select all
'<textarea name="some_name" class="some_class ....">' . htmlspecialchars($some_content). '</textarea>';
Code: Select all
'<textarea name="some_name" id="some_id" ....">' . htmlspecialchars($some_content). '</textarea>';
Code: Select all
function init_editor($ids = array(), $config = false)
Code: Select all
'<textarea id="some_id" name="some_name" class="some_class ....">' . htmlspecialchars($some_content). '</textarea>';
The pros (well known and tested editor) and the cons (fails under IE9; takes time to implement) have to be weighed. I'm still not sure about it.Holger wrote:I've talked about that with Christoph and we've discussed if it would be a good idea to provide that code.
Initializing by classes might be a simple solution for calendar. AFAIK an editor instance is available for each event. So it's quite easy to give all of them the same class, and call 1 function to initialize them all. And that's the advantage of being able to initialize by class (a similar situation probably holds for Trabant). This way the burdon of implementing it is shifted from the plugin author to the editor integrator. Under the assumption, that there'll be more plugins that uses editors than editor integrations, it's an advantage. And the editor integrator might take the code from tinymce_initializeByClasses() and modify it according to his needs.Holger wrote:But I really not see an advantage to initialize the editor by classes (and I'm happy that the default id "text" is still in the core ).
This is the most flexible way to instantiate an editor. If the user (i.e. plugin author) wants to have his own, very special filebrowser, he could have it. That's not possible with init_editor(), as this will always call EDITOR_filebrowser(). Well, it's possible not to use %FILEBROWSER% in the init, but to provide an own filebrowser callback. But in this case editor_replace() might be the more direct way. And yes, as I've already written, it might not be reasonable to call editor_replace(), but instead %EDITOR%_replace().Holger wrote:what's the secret behind function editor_replace($elementID = false, $config = '')?
I don't know, if this could be implemented with reasonable effort for different editors. For tinyMCE that would probably mean, that two config objects have to be merged by JS before instantiating the editor. Well, not too big a deal, but what about possible conflicts. E.g. the default config uses the "simple" theme, but the plugin config relies on the "advanced theme". OTOH: the plugin author can alway make a copy of one of the init_*.js files and adjust it to his needs.Holger wrote:So init_editor() will always create a working editor and $config only contains those settings, the plugin wants to overwrite.
Code: Select all
function editor_test(){
$html = '<form>
<textarea id="my_id_1" name="my_teaser">Guten Tag!</textarea>
<textarea id="my_id_2" name="my_content">I need a fullblown editor</textarea>
</form>';
include_editor();
$html .= editor_replace('my_id_1');
$html .= editor_replace('my_id_2', 'theme : "advanced",
theme_advanced_toolbar_location : "top"');
return $html;
}
Perhaps init_editor()'s specification should be slightly extended to allow a full path for $config. This way the plugin could keep the config in it's own folder.Martin wrote:But still, you do not have to spread your editor configuration files to the plugins/<editors>/inits-folder.
That's a good idea!Christoph wrote:Perhaps init_editor()'s specification should be slightly extended to allow a full path for $config. This way the plugin could keep the config in it's own folder.
Sorry, that I missed that discussion. And I haven't had a look at *_initializeByClasses(), but - at least with TinyMce - this works as well:Christoph wrote:Unfortunately it's not possible to call tinyMCE.init() more than once with different settings (at least not by ready() handlers). This was recognized while Gert developed the current version of Realblog_XH. It was not possible to have separate configs for the editors of the teaser resp. the full blog entry. To make this possible, we had to use tinymce.Editor().render(), what requires the textarea's ID. So I came up with the *_initializeByClasses() function (besides some further changes to avoid clashes, if the initialization is called more than once).
Code: Select all
function editor_test_2()
{
$html = '<form>
<textarea id="my_teaser" name="my_teaser" class="my_teaser_class">Guten Tag!</textarea>
<textarea id="my_content" name="my_content" class="my_content_class">I need a fullblown editor</textarea>
</form>';
init_editor(array('my_teaser_class'), 'minimal');
init_editor(array('my_content_class'), 'full');
return $html;
}