Category: WYSIWYG (What You See is What You Get)
Show subcategories objects| Name | Type |
|---|---|
| Non default WYSIWYG editor skin doesn't load | tracker item |
|
Normal editor destroys table from WYSIWYG editor
{syntax type="tiki" editor="plain"} In WYSIWYG, I introduce a table (4 rows, 2cols, 1st row is header). This is html. There is no Allow HTML checkbox in this editor, but the page is saved correctly with emphasis on the first row. I edit the page with the normal editor. There is only one cell left in the first row (text of the two original cells concatenated). I cut the cell again in two with "|". Emphasis is lost. Now there is an Allow html checkbox, I check it and save. Going back to the WYSIWYG editor, I restore the emphasis on the first row (again html seen in the source) and I save. Back in normal editor, Allow HTML is lost again and the table gets the same defects. |
tracker item |
|
Option to use WYSIWYG editor on Articles like WiKi pages
For WiKi pages I use the WYSIWYG (FCKEditor) but this is not an option for Articles. There you can only use the simpel Text Area and Quicktags. It's must better if you can use the WYSIWYG (FCKEditor) for every text input. |
tracker item |
|
Option: "Content is parsed like wiki page" leads to unwanted problems
If you uncheck the option: Content is parsed like wiki page some features of the tiki wiki will not work anymore. --- __Our case:__ We have many code examples where we, for example, have arrays like you have them in javascript with square brackets. ~np~["array"]~/np~ When wiki syntax is parsed, the square brackets are interpreted as a wiki link, which is not the case. __The solution:__ we solved the problem with the option "Content is parsed like wiki page". We unchecked it, so wiki syntax is not interpreted. __Side effect:__ Now, if we try to insert an image from the file gallery, tiki wiki inserts it as a wiki image with the wiki syntax. That won't work, obviously. Another feature that won't work anymore is the codemirror plugin. The plugin inserts wiki syntax too. __My opinion:__ All features that use wiki syntax have to check, if this option is set. If it is not checked, than they have to insert html. I mean, if the file gallery inserts a simple img html tag, it would simply work, the same for codemirror. |
tracker item |
|
Plugin dialog is hidden when full-screen is on
Using wysiwyg, full screen plugin dialog are hidden under the page (not in full-screen the dialog is on top). {youtube movie="http://youtu.be/rzg355BRNVk" width="320" height="280" allowFullScreen="y"} |
tracker item |
|
Plugin Edit removes line breaks in FancyTable
{syntax type="tiki" editor="plain"} Using Plugin Edit to amend a FancyTable in WYSIWYG submitting a change causes all line breaks in the table body to be removed. The PluginEdit shows the field "Rows separated by >> in the header; for the table body, one row per line. Cells separated by | in both cases." Creating a working FancyTable with table body rows like this: row 1 cell 1 | row 1 cell 2 row 2 cell 2 | row 2 cell 2 after inserting with the plugin edit tool this changes to: row 1 cell 1 | row 1 cell 2 row 2 cell 2 | row 2 cell 2 |
tracker item |
|
Plugin Gallerific Displays Incorrectly
__Describe precisely what you did (how to reproduce)__ I displayed a file gallery using PluginGallerific in Tiki_15.x_Situla The parameters are set as follows "Thumbs Width" 100px "Show Top Pager" Yes "Show Bottom Pager" Yes ''The rest of the parameters are left empty or default.'' __Describe exactly the faulty consequences__ The faulty consequence renders a poor layout in a wiki page. Site width is set at default. __Explain what you expected instead of the faulty consequences__ What I expected was a cleaner layout. Thank you for considering this bug for your attention John |
tracker item |
|
PluginMouseover data in WYSIWYG : line breaks are lost from the mouseover data
{flash type="ur |
tracker item |
|
WYSIWYG plugin fails to open if no parameter for page (regression from version 17)
The WYSIWYG plugin no longer works starting from Tiki 17 if there is no page URL parameter, for example on the homepage. I wrote in the wiki page the usual way to have the plugin to show up: {CODE()} {WYSIWYG()} {WYSIWYG} {CODE} I save the wiki page. When one clicks the "Edit" button at the bottom right corner of the plugin, a JavaScript error occurs: {QUOTE()}Uncaught TypeError: Cannot read property 'type' of null at HTMLButtonElement.<anonymous> (tiki-ckeditor.js:188) at HTMLButtonElement.dispatch (jquery.js:5206) at HTMLButtonElement.elemData.handle (jquery.js:5014){QUOTE} jqueryTiki.current_object is null. If the homepage is accessed using relative URL tiki-index.php, the issue occurs. If the homepage is accessed using relative URL tiki-index.php?page=HomePage, the issue does not occur. Tiki 16 does not have this issue. |
tracker item |
|
PluginWysiwyg doesn't open for edition in production site after upgrade to 18.x
I can't make a simple ((doc:PluginWysiwyg)) call to work as expected in Tiki18 (afaik it worked as expected up to Tiki16 at least; I didn't try in Tiki17). {CODE(ln=1)} {WYSIWYG()} foo {WYSIWYG} {CODE} Using wiki plain text editor. Unluckily, I have NOT been able to reproduce the issue in a show.t.o instance http://xavi-9794-6661.show.tikiwiki.org/tiki-index.php?page=Community (it works as expected there) And I've noticed that if I clone the same page contents from my production site to a page in the show.t.o instance, the issue can't be reproduced: admin user can open the wysiwyg editor coming from the plugin wysiwyg. And if I add perms to the page in my production site so that anons can edit the wiki page, the issue vanishes Odd, after adding and removing perms in that page in my production site, I can't reproduce the issue any more. :-/ Ok, I'll close this bug report, with a tag "works for me". Who knows what was going on. |
tracker item |
|
POST request to tiki-autosave-save breaks typing text leading to lost characters in Wysiwyg
My client wrote about typing text in Wysiwyg: {QUOTE(replyto="Mark")}When I am typing, every so often the system stops responding for a couple of seconds so that the letters that are being typed are skipped. I've tested it on an Apple and Windows machine, both using Firefox and it is the same. So I think it is the tiki or the server? It is very annoying and the team will lose patience with it if this happens to them when they are typing. It happens about one or two time a minute, I would guess. Sometimes more. It happens anywhere on the tiki site. It does not appear to happen in the firefox browser. This morning, Friday 10/9/15, the droppe letters seems to be much more frequent. Every 10 seconds maybe. VERY annoying.{QUOTE} In Firebug console I can see every several seconds (maybe half a minute?) the POST to tiki-autosave-save causes this. Could it be fixed so, that this does on a DOM copy of the text and thus does not prevent typing more text while the call is made (or something like that)? Thanks, luci |
tracker item |
|
Quicktags simplebox assign from single caret to double to allow for more elements inside
{syntax type="tiki" editor="plain"} The tiki normal editor has a problem when a page uses multiple carat elements. It creates unwanted boxes. i.e ~np~10^¹¹~/np~ used twice would create a malformed simplebox breaking the natural math operators into unreadable divisions. The {img src=images/code.png}%%% {CODE()} ~np~ … ~/np~ {CODE} is not a workaround as this creates an unwanted space after the carat and before the next character. It is also awkward. It also does not allow the natural use of an otherwise perfectly suited math symbol. |
tracker item |
|
Random Poll with {poll} in user module not working
{syntax type="tiki" editor="plain"} When i try to add{CODE(wrap="0",ishtml="0",ln="0",wiki="0",rtl="0",cpy="0")} {poll}{CODE} without id= to a user module in order to display random active polls (which i have previously created, activated and checked countless times) i get the following error when i edit the user module again. Using ckeditor, the sourcecode still shows {CODE(wrap="0",ishtml="0",ln="0",wiki="0",rtl="0",cpy="0")}{poll}. {poll id=n} {CODE}is working as it should. {CODE(wrap="0",ishtml="0",ln="0",wiki="0",rtl="0",cpy="0")} PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> http://tiki.org"(external link) /> FehlerFehler missing poll ID for plugin POLL Close Window {CODE} // Removed some empty lines from the code view |
tracker item |
|
Renaming or creation of pages with brackets in name not updating links when Wysiwyg
{syntax type="tiki" editor="plain"} Renaming or creation of pages with brackets in name not updating links when Wysiwyg. Affects both ? and normal links. |
tracker item |
|
Saving in WYSIWIG removes Edit Section buttons; saving in Wiki restores them; Wiki edit option disappears when doing a section edit
{syntax type="tiki" editor="plain"} If you save a page in WYSIWYG, Edit Section buttons disappear. (However, if just before saving, you Switch Editor to wiki, the Edit Section buttons will (re-)appear (:wink:)) Note also separate bug #3764, i.e. the Switch Editor button does not appear if your edit is invoked by a Edit Section button. This makes the first bug very discouraging for new contributors. This bug is a big issue for sites wishing to encourage collaborative editing, especially with longer pages: *Having Edit Section buttons at each heading cries out 'Edit me! Edit me!'. If they disappear, it is much scarier for a beginner to edit a page. *If someone bravely uses an Edit Section button only to find that it has disappeared as a result of their work, they may think they no longer have edit rights. They will think the site is stupid, and be greatly discouraged re further editing. |
tracker item |
|
The second editor of a page in wysiwyg mode will see an empty editor bloc when overriding
Tested on Tiki 11 release (no svn) with page editing in mode wysiwyg. If a second user (with proper perm) come to edit a wiki page (overrinding) he will see nothing in the editor bloc as he was getting into an empty page. To reproduce on the show instance: Open in one browser. Log as editor1/12345. Edit and let open in editing mode the homepage. Open in a second browser. Log as editor2/12345. Edit the homepage, when warned the page is already edited by editor1, override. You'll get an empty page. Used to work. |
tracker item |
|
Special Characters with tilde ~ don't seem to work
Wiki Syntax for special characters seems to fail in 1.10 (I can get it in WYSIWYG). Thus, ~np~~169~~/np~ no longer shows the copyright symbol. The problem appears to lie in TikiLib - parse_data if (!$simple_wiki and $prefs['feature_wysiwyg'] == 'n') { $this->parse_htmlchar($data); Here's this issue - I have WYSIWYG set to Y, but NOT showing by default. It seems that the test should be whether WYSIWYG is actually showing - I have no idea what the variable is. |
tracker item |
|
Structure TOC Plugin breaks CKEditor
When the Structure TOC Plugin is activated, I can no longer edit pages in WYSIWYG mode. CKeditor sits and spins "Loading". Errors produced: /vendor_bundled/vendor/ckeditor/ckeditor/plugins/Tabledesmati%C3%A8res(Structure)/plugin.js?t=I8BH:1 Failed to load resource: the server responded with a status of 404 (Not Found) ckeditor.js:248 Uncaught Error: [CKEDITOR.resourceManager.load] Resource name "Tabledesmatières(Structure)" was not found at "http://outilingua.net/vendor_bundled/vendor/ckeditor/ckeditor/plugins/Tabledesmatières(Structure)/plugin.js?t=I8BH". at window.CKEDITOR.window.CKEDITOR.dom.CKEDITOR.resourceManager.<anonymous> (ckeditor.js:248) at f (ckeditor.js:244) at Array.n (ckeditor.js:244) at r (ckeditor.js:244) at HTMLScriptElement.CKEDITOR.env.ie.d.$.onerror (ckeditor.js:245) This occurred on two separate Tiki sites after upgrading from 18.2. I have no workaround as Structures are an important part of both sites for navigation. |
tracker item |
|
Switch from WYSIWYG to normal (wiki) editor error
{syntax type="tiki" editor="plain"} When switching from normal (wiki) editor to WYSIWYG editor everything works fine. But when switching back from WYSIWYG to normal (wiki) editor, this actions simply times out, and IE or Opera are timing out. This problem appears in 4.0 which was working fine in the 3.x version. |
tracker item |
|
Switching between 'normal' and WYSIWYG loses edits.
Doing edits in the WYSIWYG editor & switching to 'normal' loses the edits. The remaining content is presented as HTML source. Workaround: turn off option to use either 'normal' or WYSIWYG editor? |
tracker item |
|
Table Builder tool always inserts a table with a single row in WYSIWYG-wiki mode
The Table Builder tool offered in the toolbar when using CKEditor with wysiwyg_htmltowiki enabled inserts incorrect code in Tiki 17 and ulterior, although it worked in Tiki 16 and earlier. For a table with "R1C1" in the first cell and "R2C1" in the first column of the second row, the inserted syntax should be... {CODE(caption="Proper code" colors="tiki" theme="default")} ||R1C1 R2C1||{CODE} ...but it is actually... {CODE(caption="Broken code" colors="tiki" theme="default")} ||R1C1 %%% R2C1|| {CODE} Which is to say, each newline is replaced with 3 percentage signs. There is no change dialogTableInsert() between Tiki 16 and 17. In fact, things seem to go well in dialogTableInsert(), and even when it calls insertAt(), up to the point where insertAt() calls cked.insertText(), which is where it gets too hard to follow for me. If the issue is in CKEditor's insertText(), it seems likely that the regression was introduced by the bump of CKeditor from 4.5.11 to 5.7 (done via r61891). |
tracker item |
|
Text area field width and height parameters are not applied when using wysiwyg
Text area field width and height parameters are not applied correctly. Width is never applied. Height is not applied when wysiwyg is on. |
tracker item |
|
Text Disappearing in WYSIWYG
When I go to source or the wiki editor and add ~np~ <form> ~/np~ and save the <form> appears on the page. But if I go edit page again, it has disappeared. It will not show up <form> in the WYSIWYG and when i save it again <form> does not display on the page. The same is happening with ~pp~ and the code syntax. I have no idea what the error is. But it's happening both on my localhost and on the main server at work. Kind regards, Laura |
tracker item |
|
The field with the smilies does not appear in places where they should be available
In certain instances when editing a page through the text editor (or creating a new blog post), with the wysiwyg-available available (though hidden) the smilies field is not displayed. The problem is probably due to the fact that the variable $wysiwyg contains an 'n' if the editor is hidden while in some instances the value is NULL. This is probably because if the wysiwyg feature in admin-features is disabled then the $wysiwyg value is NULL, but if it is enabled but hidden the value is 'n'. There is a conditional in templates/tiki-editpage.tpl that does not take this into account. (The problem may be present in other versions as well) |
tracker item |
|
Tiki 6.2 : CKEditor translates all my wiki pages (containing HTML) to wiki syntax ???
{syntax type="tiki" editor="plain"} Hi guys, Yesterday, with tiki 6.1, i had a page witch source (partial) was like this : ------------ {HTML( wiki="0")}<h1 style="text-align:center;font-family:arial;font-size:26px;">Le Bureau de Windows</h1>{HTML} {img fileId="50" thumb="y" rel="box[g]" align="center" desc="desc" alt="Exemple de bureau Windows" class="reflect"} {HTML( wiki="0")}<div style="text-align:justify;font-family:arial;font-size:16px;line-height:20px;font-style:italic;">Le <b>bureau</b> de Windows est l'équivalent de notre bon vieux bureau ou table de travail.<br />Après le démarrage du système, c'est ce que nous avons en permanence sous les yeux et on y revient chaque fois que l'on quitte un programme.<br />De même que la table de travail d'un architecte ne ressemble en rien à celle d'un écrivain, chacun de nous a la liberté d'organiser et d'utiliser son bureau comme il le souhaite.</div>{HTML} {HTML( wiki="0")}<h2 style="text-align:left;font-family:arial;font-size:22px;">Que mettre sur le Bureau ?</h2>{HTML} {HTML( wiki="0")}<div style="text-align:justify;font-family:arial;font-size:16px;line-height:20px;">Il est pratique d'avoir sur le bureau des <b>raccourcis</b> vers nos programmes habituels comme navigateur Internet, messagerie, jeux, etc.<br />La <b>corbeille</b> y a aussi sa place bien entendu.<br />On peut également y installer des <b>raccourcis vers des fichiers</b> de tous types (photos, vidéos, documents...) ; En double-cliquant sur ce type de raccourci, Windows lance le programme approprié (associé à ce type de fichier).<br />On peut aussi déposer sur le bureau des notes en forme de 'post-it'<br />On trouve également aussi un raccourci vers le <b>Poste de travail</b> (appelé aussi Ordinateur) pour accéder aux données de notre machine (disques, clés USB, CD ou DVD...)</div>{HTML} {img fileId="51" thumb="y" rel="box[g]" align="center" desc="desc" alt="Exemple de bureau avec des raccourcis" class="reflect"} ------------------ Today, with Tiki 6.2, if i want to edit this page in wysiwyg editor the source is : ------------------ <p> {HTML( wiki="0")}<h1 style="text-align:center;font-family:arial;font-size:26px;">Le Bureau de Windows</h1>{HTML}</p> {img fileId="50" thumb="y" rel="box[g]" align="center" desc="desc" alt="Exemple de bureau Windows" class="reflect"} <p> {HTML( wiki="0")}<div style="text-align:justify;font-family:arial;font-size:16px;line-height:20px;font-style:italic;">Le <b>bureau</b> de Windows est l'équivalent de notre bon vieux bureau ou table de travail.<br />Après le démarrage du système, c'est ce que nous avons en permanence sous les yeux et on y revient chaque fois que l'on quitte un programme.<br />De même que la table de travail d'un architecte ne ressemble en rien à celle d'un écrivain, chacun de nous a la liberté d'organiser et d'utiliser son bureau comme il le souhaite.</div>{HTML} {HTML( wiki="0")}<h2 style="text-align:left;font-family:arial;font-size:22px;">Que mettre sur le Bureau ?</h2>{HTML} {HTML( wiki="0")}<div style="text-align:justify;font-family:arial;font-size:16px;line-height:20px;">Il est pratique d'avoir sur le bureau des <b>raccourcis</b> vers nos programmes habituels comme navigateur Internet, messagerie, jeux, etc.<br />La <b>corbeille</b> y a aussi sa place bien entendu.<br />On peut également y installer des <b>raccourcis vers des fichiers</b> de tous types (photos, vidéos, documents...) ; En double-cliquant sur ce type de raccourci, Windows lance le programme approprié (associé à ce type de fichier).<br />On peut aussi déposer sur le bureau des notes en forme de 'post-it'<br />On trouve également aussi un raccourci vers le <b>Poste de travail</b> (appelé aussi Ordinateur) pour accéder aux données de notre machine (disques, clés USB, CD ou DVD...)</div>{HTML}<span> </span></p> {img fileId="51" thumb="y" rel="box[g]" align="center" desc="desc" alt="Exemple de bureau avec des raccourcis" class="reflect"} ------------------------ But, if i use by section editing, i recover my code like this : ------------------------ partial sample <div style="text-align:justify;font-family:arial;font-size:16px;line-height:20px;font-style:italic;">Le <b>bureau</b> de Windows est l'équivalent de notre bon vieux bureau ou table de travail.<br />Après le démarrage du système, c'est ce que nous avons en permanence sous les yeux et on y revient chaque fois que l'on quitte un programme.<br />De même que la table de travail d'un architecte ne ressemble en rien à celle d'un écrivain, chacun de nous a la liberté d'organiser et d'utiliser son bureau comme il le souhaite.</div> ------------------------ What's the matter ? Thanks Jean-Luc NAVARRO. |
tracker item |
Found the origin of this bug:
Select on Control Panel "Wysiwyg" for setting "Full WYSIWYG editor skin" one of the non-default skins.
Results in non loading editor (only shows for short time a loading bar) when editing a Wiki page.
Workaround:
Select "Moono (default)" as editor skin.