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

If you create a tracker with one field which is a text area set to WYSIWYG, plus another field which is an Item Link that has the "Add Items" options set, the WYSIWYG editor will not load using the TRACKER module. It must be a conflict in the two scripts. Disabling the "Add Items" option allows the WYSIWYG editor to load fine.

Maketoc fails to parse headers which contains other tags.
See [http://dev.tiki.org/WYSIWYG+testing] for an example.

(This page also shows that the maketoc plugin has other issues, since the title is corrupted and no numbering is displayed.

Strangely enough maketoc seems to work well on my other Tiki8 sites. So, maybe this is a regression.

{syntax type="tiki" editor="plain"}
Using my version is 8.4 (MyISAM), installed via softaculous, when WYSIWYG is enabled the editor does not show up on the Admin>ContentTemplate page. I looked at the generated source code where the editor should appear and what it shows is this :
~lt~tr>
~lt~td/>

instead it should show:
~lt~tr>
~lt~td>
(code for WYSIWYG editor goes here)
~lt~/td>

Both features work fine independently, just not simultaneously.

{syntax type="tiki" editor="plain"}
Editing a simple wiki page, converted into wysiwyg, added new content, saved page, and nothing of the new content is saved (old content is shown at save time and when visiting the page again)

People tend to make the comment that adding images in wiki docs is a tedious process - compared to what they are used to in other (local) applications/editor. Most of which support drag & drop of images directly in the editor.

I reply that this is a web application and not a local application. Few people are satisfied with this explanation.

Drag & drop of images in the - especially in the WYSIWYG editor - would be really nice.

The dropped files should be stored in the File Gallery, I guess. Once dropped Tiki should automatically insert the image tag at the drop location in the editor.

The user must be able to open the image properties to configure the image settings afterwards.

In Docuwiki there is a floating command bar. It follows the page view. Always in sight, always there with the commands. Easier.


I am not sure how TikiWiki can fit this in, but the "instant readiness" is a plus.

Another nice feature is the display of the icons only - when using the page, but on mouse over the command titles are displayed in a popup.

See: [http://demo.tiki.org/trunk/tiki-index.php?page=For+Arild]

{syntax type="tiki" editor="plain"}
loss format text when user re-edit submission (use Wysiwyg)
ex:__abc__ -->abc

i have try tw 9.2 and have problem with plugin Source in wisywig editor. it give me sorce of not last version of page. How i can change it?

Essentially as the title says, I am unable to use the {maketoc} tag to work correctly on a page in a structure using the WYSIWYG editor. If I switch to the wiki markup, it works, but then I lose my WYSIWYG formatting (eg for tables and the like).

I've tried {toc} but it won't show headings in the page.

If I try {maketoc} on a wiki created page, the headings will be created in the WYSIWYG editor.

This tracker is made to help filtering and sorting the features vs categories vs options we need to tag a bug/regression/wish with.

r45987 - still a problem in r46589

FILES plugin (in either the wiki or wysiwyg (full html) editor) is not working correctly as follows:

*the "FileID" parameter is being ignored - FileID list should allow just specific files to be shown.
*if the "Show Parent Gallery Name" (showgallery="y")is set, then the table headings/contents get out of alignment
*--Plus in the WYSIWYG editor it now breaks completely producing garbled content. THIS OK NOW--

Going from tiki 9.0 to tiki 9.3 (Possible still relevant to new versions, but have not had time to check if still occurs in new versions).

Works in 9.0, broken in 9.3

WYSIWYG editor generates headers (for h1-X) looking like {CODE()}<h1> header text </h1>{CODE} when it should be like {CODE()}<h3 class="showhide_heading" id="Some_text">Some text</h3>{CODE}

this breaks the ability to use hash tag to navigate to page headers.

r46040

http://dev.tiki.org/item4532?show=view

Created a few pages through the Workspace UI. My settings were wysiwyg optional, displayed by default, reopen with same editor, content is parsed like wiki page, use wiki syntax in wysiwyg. Ah, codemirror is on, even if I wonder if it matters for this bug. When I went to paste some content to one of those new pages, I opened the page, pasted content from somewhere else (another wiki page with simple text editor, som plain ascii), and nothing was shown in the wysiwyg editor. I tried again through the button to paste content, but same effect: nothing is displayed on the page (in the editor, still in edit mode, I mean). Then I clicked at "source", and pasted the wiki syntax there. It was shown in the editor. then saved. and the content was parsed, and displayed properly also in the wiki page (in display mode). ~~#FF0000:Edited by Bsfez:~~ Could be related, paste in this field (text area with wysiwyg) show only a string "undefined".

Go to a wiki page and edit it using the WYSIWYG editor.
Click the button to create a Wiki link.
Select a Wiki page to link to and type the text as its name.
Click OK
Save page and click on link.
Link is broken doesn't go to Wiki page selected from Wiki Link "Generator"

When I edit a wiki page :
*in edition mode it's works fine.
*in wysiwyg mode, I loose the content of the page.

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

maketoc does not generate any table of contents (only the heading "Table of Contents" shows) on a wysiwyg page

When the MAP plugin is used in the WYSIWYG editor (full HTML usage) and an already configured plugin is opened in the edit screen (by double clicking the grey box to open up the Plugin Editor) the parameters that were set for the 'centre' parameter have been moved and added to the end of the 'height' parameter with some other characters inserted in between

An example of a corrupted 'height' field is:

400¢er=-1.734241247177124,51.421028334349295,14

which should be 400 and to which the centre parameters

-1.734241247177124,51.421028334349295,14

have been added with the additional ¢er= characters added in between

This does not happen happen when the plugin editor is opened direct from the wiki page by clicking its edit icon and it obviously does not apply when the standard wiki editor is used.

FIXED with r46190 - thanks jonny

{syntax type="tiki" editor="plain"}
Hi. I've installed Tiki 27.0 and turned on markdown (which is marked as experimental). When I try to create a wiki page, the editor is just missing. Nothing can be entered. This is due to my javacript blocker. It's called Noscript and is a Firefox extension.

According to Noscript, there is a dependency on toast.com, for some javascript code. It looks like the editor component is loaded from that external source. When I allow for javascript code to be loaded from toast.com, then the editor appears and it works.

It's a security problem, in my eyes. I don't want to have to trust some external source, like toast.com. The markdown editor should be included in Tiki, like all the many other libraries and components.

(Aside: There isn't any accurate choice for the mandatory "Category" field, so I've chosen "Bug". Maybe there should be added an "Other" category).

When switching a "wiki" format page to the wysiwyg editor, wiki markup not converted into HTML.
Likewise switching an HTML page to the normal editor, HTML markup not converted to wiki.

My wiki (http://wiki.alphasoftware.com/, on version 4.2) intermittently fails to respond to mouse clicks for module box and menu expand/contract toggles, tab buttons for administration interfaces, the button to toggle between WYSIWYG and Normal editing, and other buttons that invoke JavaScript Ajax actions.

Changing random administrative settings or themes sometimes changes this behavior, but it still seems to come back.

I think it might be a bug, but I might also have some inconsistent settings.

I am willing to upgrade to the trunk build if these are bugs that have already been fixed.

This is still an issue at r46589 - there is a worked example at my test site at www.opendev.enmoreservices.com/test+MOUSEOVER+plugin+wysiwyg+editor

(access given on request)

when this page is first shown or the page refreshed then (using Firebug) you can see that the span tag containing the pop-up content is:

<span id="mo1" class="mouseoverclass" style="width: 300px; height: 100px; background-color: rgb(255, 255, 240); padding: 5px; cursor: pointer;">

which means it is displayed in line with the link text

once you mouseover and show the pop-up and then close the pop-up the span reverts to what it ought to be ie display: none is added to the style element as below

<span id="mo1" class="mouseoverclass" style="width: 300px; height: 100px; background-color: rgb(255, 255, 240); padding: 5px; cursor: pointer; position: absolute; left: 437px; top: 551px; display: none;">

If the plugin is used with the standard wiki editor it works fine - not tested with the wysiwyg wiki editor option

I don't know how anyone can use the Beta version - the links in ALL Wiki pages are wrong.

The correct link to a Wiki page "Cars" should be ..../tiki-index.php?Page=Cars

Instead ALL Wiki pages are wrong with the link ..../cars

Obviously no one is using Beta or this would have been fixed in 1 minute

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.

This is an alternative to full WYSIWYG.

Wiki parser does some things. To get Javascript WYSIWYG, you would have to rewrite and maintain in javascript.

It re-uses existing features and has less chance of What you Saw Was Not What You Got.

Clicking Preview is a great way to see what you will get. But it's slow and it makes you loose your cursor position.

How about having a button to open a second browser window which refresh every 5 seconds (configurable) the content of the wiki edit box?

Lots of people now have large screens so they could put this side-by-side (or however they want it)

With the option HTMLdiff, you could in quasi real time not just see what you will get, but also see the colored diff. (cool!) So before you save, you know what you are about to delete.

((WYSIWYG-ish wiki))