Category: WYSIWYG (What You See is What You Get)

The wysiwyg editor no longer shows the defined toolbar (as set in toolbars admin) when editing a wiki page. Instead the reduced wiki syntax toolbar is shown which does not allow all the edit features possible.

The fullscreen WYSIWYG is missing format eraser. The "format eraser" takes away the text formatting, but leaves the text.

It used to be there in previous versions.

When the GALLERIFFIC plugin is used in the WYSIWYG editor (full html) then the editor no longer opens - just the 'Loading' message forever. The plugin seems to run ok once it is in there ie it was there before an upgrade or put in new first time round - and you can also use the standard wiki editor ok.

Console errors shown when trying to load the editor are:

"TypeError: imageData is undefined
var index = imageData.index;

jquery....ffic.js (line 505)

which might have something to do with it


... just to confirm that this is still a bug at r 55993 Aug '15

Not totally sure if this is feature request, bug, or lack of knowledge. Basically I need some way of supporting maketoc with WYSIWYG pages.

The CKeditor does not show the help pop up.
it works with the wiki editor and the page
tiki-ajax_services.php?controller=edit&action=help&modal=1&wysiwyg=1&plugins=1&areaId=editwiki#content_ajax_services1-2

Shows the help, but when inside a page the help does not pop up
a white area appears for the title
{img fileId="1286" thumb="box"}

I can't see any error the js
And without the help there is no support for inserting the widgets

Wysiwyg enabled, using wiki syntax. Article has wysiwyg, and in the body, this content is added:
{CODE()}
{file type="gallery" fileId="41" showicon="y"}
{CODE}

When viewing the article, the html tags for the icon are shown instead of showing the file icon.
{CODE()}
<a href="dl41" class="internal"> <img src="dl41?thumbnail=y&x=16" alt="Image" class="regImage pluginImg" /> </a>
{CODE}

Mmmm, I can't reproduce, for some reason, with the show instance. I will provide a dbdump of my production site to any developer willing to have a go to fix this issue. (whatever permutation of settings is needed seems to be achieved - by chance - in that production site). {sign user="xavi" datetime="2014-04-24T16:49:50+00:00"}

(For the record: diaspora site)

I noticed after pulling the latest code from SourceForge that certain icons in the WYSIWYG and Wiki editors were not being set properly. A condition inside an if statement in /lib/toolbars/toolbarslib.php on the line 1709 was setting several icons to the plugin.php icon.

I began looking for the cause of the issue and discovered a series of several commits that had caused the bug. The icons in question are the features 'Image', 'File', 'Mouseover', 'Insert Module', 'HTML', 'Include', 'Code', and 'Remarks Box'.

The problem code for each of the above features can be found in the lib/wiki-plugins/ directory and is attributed to a single line of code in each file. The structure of the hash tables located in these files appears to have been changed from using

'icon' => 'path/to/icon'
to
'iconname' => 'iconset_definition'

Unfortunately, this has caused the regression on my site. To fix this, I can simply comment out the line with 'iconname', and replace it with the previous 'icon' line, however this increases the number of customizations on my site I would need to keep track of, and would prefer not to go down that route.

The revision numbers and files for the features in question are as follows:

'Image' = r56275 -- /wiki-plugins/wikiplugin_img.php
'File' = r56269 -- /wiki-plugins/wikiplugin_file.php
'Mouseover' = r56280 -- /wiki-plugins/wikiplugin_mouseover.php
'Insert Module' = r56280 -- /wiki-plugins/wikiplugin_module.php
'HTML' = r56273 -- /wiki-plugins/wikiplugin_html.php
'Include' = r56276 -- /wiki-plugins/wikiplugin_include.php
'Code' = r56254 -- /wiki-plugins/wikiplugin_code.php
'Remarks Box' = r56291 -- /wiki-plugins/wikiplugin_remarksbox.php

I looked into the new iconset definitions as well, and didn't notice any issues with it, so this is why I'm am submitting the bug report. Let me know if there is anything I can help with!

{syntax type="tiki" editor="plain"}
If you click on an Edit Section button, the Switch Editor button is not available when you are editing.

Hi,

Using Wysiwyg, I upload a image then it is stored in like .../wiki-up/image/xxx.jpg.
Under MutiTiki environment by domain name, this page does not show the uploaded image.
The source of the page shows that ".../wiki-up~~#FF0000:/domain_name~~/image/xxx.jpg" while that image was stored in .../wiki-up/image/.

So I guess that FCKEditor has to store a image into NOT .../wiki-up/image/ but into .../wiki-up/~~#FF0000:domain_nmme~~/image/ under ===MutiTikiwiki environment===.
(How to know for FCKEditor that the site is under MutlTikiwki, I don't know)

Thanks and Best Regards,
Shigeru Serizawa (Japan)

In IE7, after double clicking an image to get the image plugin editor and making changes, a new image is created at the top of the page instead of editing the image plugin.

In IE8, the same attempt appears to make no changes to the plugin, but no new image appears either.

This works in Firefox.

adding pref will "fix" this. However, for IE, there is an additioal CKEditor bug that still needs to be fixed: [http://dev.ckeditor.com/ticket/4208]

{syntax type="tiki" editor="plain"}
Critical Usability Problem With WYSIWYG Editor

Version 4.3

"Insert an Image" does properly put an image in the Web page but the editor does not preserve the "Vspace" and "Hspace" attributes in the source code. It is not possible to do spacing around an image in a Wiki page.

The editor properly shows the spacing around the image after inserting from file gallery and before preview. Looking at the source inside the editor before a preview or save shows only this example:

"{img src=/tiki-download_file.php?fileId=1&display height=211 width=200 imalign=left}"

While the editor properly shows the spacing (inside the editor), the source code is not set to save the spacing.

It is not possible to manually enter the "Vspace" and "Hspace" into the source and save or preview successfully; the "Vspace" and "Hspace" are deleted.

It looks like the source code is simply using the original Tiki text approach. This would be a deal-breaker for my users.

I just recently installed TikiWiki on my Ubuntu server by copying all the files in the .ZIP package into /var/www/html/wiki/. This makes the site run at wiki.mysite.com. Now, when I go to edit a page and try to add an image, go to Browse Server, I get an error message saying: "Error creating folder "/var/www/html/wiki/wiki/img/wiki_up/image/" (Permission denied)"
The path seems to be wrong. There is /wiki/wiki/img when it should be just /wiki/img. There shouldn't be any permission problems if the path was correct like: /var/www/html/wiki/img/wiki_up/image/

When I click Insert Object Link, it hangs forever, and PHP lists errors in searchlib-unified.php

Same problem in category admin if you have unified_add_to_categ_search enabled the add objects hangs too {sign user="jonnybradley" datetime="2016-02-01T10:13:11+00:00"}

This is hard to explain. To reproduce, create below a page like this:

Link1
Link2

Link3
Link4

Paragraph formatting is on, so each line is on it's own paragraph. Take care NOT to press enter at the end of Link4 for now. There is no blank space before Link1 which is on the first line

Note the blank line between Link2 and Link3.

Now do the following test:
1) Select Link1 taking care to select only the text and not the start of line or end of line around it, click on Insert Wiki Link. You get Link1, all good

2) Select Link1 aggressively, dragging the mouse cursor to the left of the Link1 before the start of line, or alternatively to the right of the end of line. You will get Link1Link2Link3 picked up.

3) Now add an enter at the end of Link4 (the end of the text)

4) Now repeat step 2 above, you will find that instead if Link1Link2Link3 you will now pick up Link1Link2Link3Link4

5) Now another problem: If you highlight Link3 "accidentally" capturing the br above it (the blank line), and then click Insert Wiki Link, you get nothing.

6) Now select from beyond the end of line of Link4 back but only "nk4". You will get a garbage.

The above tests were done in Firefox.

In Safari, 5) is reproducable, but the rest can't really be reproduced except note that if you select Link2 accidentally capturing the blank line below, you get Link2Link3 or Link2Link3Link4 depending on whether there is a blank line at the end of the text.

In IE (IE8 and in IE7 compatibility mode), you don't get any text whatever you do. IN IE8 compatibility mode you get a "scroll bars appearing in the popup" which is a separate problem I suppose.

When inserting an 'internal link' the objects offered are limited to Wiki objects only. (WYSIWYG editor). It would be good to have other objects included also.

Hello,

I just install the version 7.2, and here is the php info: http://grip.umich.edu/tikiwiki/tiki-phpinfo.php. When I switched to the WYSIWYG editor (I tested all WYSIWYG editors), I could create content and sometimes could save it, but when I edited it the editor could not load the existing content.

Installed new site using v7.1. WYSIWYG editor was working OK (not perfect, but could at lease copy and paste Word documents with 85% accuracy, switching between source and WYSIWYG worked, tables worked, inserted HTML tags worked).

After upgrade to 7.2 WYSIWYG has become unusable. The following problems have been seen (there may be others):
#Toggling between source and WYSIWYG (using the SOURCE button) gives mixed results. Wiki syntax in source is correct but in WYSIWYG it displays wrong (most notable is bold not parsed). WYSIWYG will display page semi correctly in the editor window with some of the formatting, e.g. auto numbering is correct, but when displayed in preview (or saved page) wiki syntax is ignored and is display as one long line (no cr or formating).
#Editing a table in Source will cause any other table to break by changing the wiki syntax by adding a carriage return after each cell and the cell delimiter.
#Can not post text copied from a Word document any more. Comes out as HTML code unparsed, then on save displays as one long string of HTML code.
#When inserting HTML code using {CODE()}{HTML()}...{HTML}{CODE} to change styles, save sometimes drops first two character, changes first > to HTML {CODE()}& gt;{CODE} and drops closing HTML tag, at other times will add {CODE()}< x >{CODE} at third character. Can not correct using any editing method in the WYSIWYG editor.

Standard editor works fine.

When trying to create a Wiki Link using the WYSIWYG, the auto page find doesn't work anymore making it almost impossible to link to another wiki page without knowing exaclty the page name

{img src="https://img.skitch.com/20111124-r2ai2a29x2xyriua1mu3a3996h.jpg"}

How to reproduce:

Using WYSIWYG, edit a page which has a link to a wiki page which has an accented character and the link will change from accentué to accentu�


Workaround:

* Avoid non-English characters (éàç) in page names

{syntax type="tiki" editor="plain"}
Android browser on Tiki8: It just says "Loading..." forever


[http://cksource.com/blog/CKEditor_3.6.2_released|Recent iPads and iPhones should be OK]

If browser is not supported, should Tiki revert to entering text (or manual HTML?)

We have links to external pages using file:// because the pages are internal to our system. This type of link worked in version 3.0 and now doesn't. The links work within a browser so we know it isn't an address error. This type of link uses the protocol (other) within the WYSIWIG editor.

{syntax type="tiki" editor="plain"}
This is a minor issue, and not sure if it something for tiki or google to fix. However I try to push Chrome as the default browser in my school because we use Google apps and it works better for that.
I don’t want to have to tell my users they need to switch browsers to insert an image. This will not get tiki accepted very fast.

I have tested this on a fresh install of 8.3, svn pre8.4, and svn pre9.0

I am on a windows 7 system with Chrome 18, Firefox 11 and IE9.
In wiki syntax mode the file galary image selector works fine.

In WYSIWYG mode the image slector works fine in Firefox and IE, in Chrome I have a new window that tries to open. The window is listed in the task bar but I cannot access it.

I have turned off pop up blockers and disabled all extensions while testing with the same result.

I have also tried from different computers.

{syntax type="tiki" editor="plain"}
When you insert a Code plugin {CODE(caption="such as this")}printf("i write everything in only one line");
{CODE}
the line breaks.

after upgrade from 9.x to 12.x wiki pages with html code are reopened wrongly with wysiywg editor and no way to switch to normal through UI

It was rather annoying, since there was no way to revert back to a the normal plain text editor unless I appended by hand in the url the "__&mode_normal=y__" param.

I'll try to reproduce locally with the dump of the production site where this happened, and if I manage, I'll send a dbsump to a developer willing to bugfix it.