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

Here is an example of opening a page in WYSIWYG, not changing anything, but the data is affected.

{flash type="url" movie="display364" width="495" height="338"}

Most icon images are absent from the WYSIWYG toolbar when using Firefox. The below table lists experimentation results. I did disable all Firefox browser add-ons as part of the testing. This issue does not effect the Wiki toolbar.

The problem does not occur in the "Show" instance that was created. This tells me the problem is not entirely browser specific, but some combination of site settings with Firefox create the problem.

||__Computer__|__OS__|__OS_Ver__|__Browser__|__Browser_Ver__|__Result__
::Rorschach::|::Linux::|::Mint 14::|::Firefox::|::25.0.1::|::Broke::
::Rorschach::|::Linux::|::Mint 14::|::Opera::|::12.16::|::Works::
::Snowball::|::OS X::|::10.6.8::|::Firefox::|::25.0.1::|::Broke::
::Snowball::|::OS X::|::10.6.8::|::Safari::|::5.1.10::|::works::
::Darkknight::|::Linux::|::Mint 14::|::Firefox::|::24.0::|::Broke::
::Darkknight::|::Linux::|::Mint 14::|::Midori::|::0.4.3::|::Broke::
::Redwood::|::OS X::|::10.6.8::|::Firefox::|::25.0.1::|::Broke::
::Redwood::|::OS X::|::10.6.8::|::Safari::|::5.1.10::|::Works::
::Birch::|::OS X::|::10.6.8::|::Firefox::|::25.0.1::|::Broke::
::Birch::|::OS X::|::10.6.8::|::Safari::|::5.1.10::|::Works::
::Gem::|::OS X::|::10.6.8::|::Firefox::|::23.0.1::|::Broke::
::Gem::|::OS X::|::10.6.8::|::Safari::|::5.1.10::|::Works::
::WinXP::|::Windows::|::5.1 SP3::|::Firefox::|::25.0.1::|::Broke::
::WinXP::|::Windows::|::5.1 SP3::|::IE::|::8.0::|::Works::
::Aiuto::|::iOS::|::4.3.3::|::Safari::|::-::|::Broke::%%%(never loads)
::BCi::|::iOS::|::5.1.1::|::Safari::|::7534.48::|::Works::
::BCi::|::iOS::|::5.1.1::|::Ghostery::|::1.3.1::|::Works::
::iPS::|::iOS::|::5.1.1::|::Mercury::|::7.4.2::|::Works::
::iPS::|::iOS::|::5.1.1::|::Ghostery::|::1.3.1::|::Works::||

{syntax type="tiki" editor="plain"}
We are running Tiki 6.2 (clean install), on a Windows 2003 Server, Apache 2.2.16 w SSL, PHP 5.3.3, remote MySQL 5 database.

This bug is across all browsers.

Our users are editing in the CKEditor WYSIWYG and trying to add anchors. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%%our users use the Anchor icon (flag) to create an anchor at the bottom of a page. The anchor name window comes up and they give it a name, save, a yellow anchor icon is displayed in the editor. If they jump to the top of the page and create a Link (using the Link icon in the toolbar) and select Link Type: "Link to another anchor in the text", Select an Anchor/By Anchor Name and press Ok. At this point everything looks correct in CKEditor.The user presses Save. The Link at the top is correct using the normal syntax %%% {CODE()}[#myAnchor|Link to bottom]{CODE}%%%however the anchor at the bottom is gone as if it never saved or the parser has discarded it.

I have had to instruct our users how to type in manually the anchors using the old plugins [http://doc.tiki.org/PluginAlink] and [http://doc.tiki.org/PluginAname]. They are not happy about using long hand plugin notation.

I have tried in both IE 8 and FF 3.6 with the same result.

Since IE is our corp standard our users need to be able to add anchors using that browser. Also, they had no problem in Tiki 5.x but that was a different WYSIWYG system.

May be related to [http://dev.tiki.org/tiki-view_tracker_item.php?itemId=1499]

{syntax type="tiki" editor="plain"}
We are using Tiki v6.2 vanilla, PHP 5.3.3. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%%we can not edit a section using the Edit Section button. A blank WYSIWYG screen is displayed and if you enter content and save it gets thrown to the bottom of the wiki page and not within the section.

Reproduce: Create a blank wiki page in WYSIWYG, create a bunch of headers, save, view edit icons (if not already), click on "Edit Section" button.

{syntax type="tiki" editor="plain"}
We are using Tiki v6.2 vanilla, PHP 5.3.3. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%%we can not format the header (color it red) without breaking the "header" status.

Currently we have a page with a ~np~{maketoc}~/np~ at the top and a bunch of h1, h2, h3 headers. We wanted to make the text color red for one of the h1 titles so it was more visible to users. Once we did this in the WYSIWYG editor, the header is no longer listed in the maketoc AND the Edit Section button is gone next to the header text. This ''may'' be associated with another bug [http://dev.tiki.org/tiki-view_tracker_item.php?itemId=3763].

{syntax type="tiki" editor="plain"}
We are using Tiki v6.2 vanilla, PHP 5.3.3. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%% the lists (numbered and unordered) have irregular spacing between lines. Edited in Wiki normal and WYSIWYG Source modes work fine.

To reproduce create the following structure in a WYSIWYG editor{CODE()}*blah zaa zaa
*This is a list
**now indenting the list
**blah
*back out
**back in
***really far in
*all the way out{CODE} %%% this example displays for us as {CODE()} blah zaa zaa

This is a list

now indenting the list
blah

back out

back in

really far in
all the way out
{CODE} %%% Sometimes there is a break, other times there is not. If I Preview while editing it looks fine. If I edit the HTML via the Source WYSIWYG view and save then it looks fine until I save it in WYSIWYG mode again.

{syntax type="tiki" editor="plain"}
When editing or creating a page using the WYSIWYG_6x editor, setting any text as a header then saving the file works correctly, however if the page is edited again, the WYSIWYG editor inserts a ! before or sometimes after the text you decided to format as a header.

Looking at the source, it appears that it is inserting the following into the page:

<p>
!</p>

Attempting to remove it by deleting the ! in the WYSIWYG editor just results in it showing up again, either immediately after saving or on the next edit of the page. This results in people not wanting to use the header feature or finding other workarounds such as larger font size.

When using the WYSIWYG plugin (to edit the contents of a call to the WYSIWYG plugin), a line break is added at the end of the call when saving.

This happens in Tiki 15, but did not happen in Tiki 12, as a result of r55910. However, the proper fix is to leave tiki-ckeditor.js as-is and to instead modify parserlib.php as shown in the attached patch. This dirty patch also solves issue #6592.

When using the WYSIWYG plugin to edit the contents of a call to the WYSIWYG plugin containing several consecutive line breaks, some of these newlines can be removed when saving.

This happens in Tiki 15, but did not happen in Tiki 12, as a result of r55910. This can be solved by removing the line added in r55910, as shown in the attached patch. This patch also solves issue #6591. But I've ended up only applying the changes to parserlib.php due to issues described in my third comment in #6591.

{syntax type="tiki" editor="plain"}
I upgraded an instance from version 27 to 29.1. When I open the WYSIWYG editor, the buttons that are supposed to open dialogs don't work. The following error is displayed in the console in the browser:
createCustomButton.js:9 Uncaught TypeError: Cannot read properties of undefined (reading 'call')
at HTMLButtonElement.click (createCustomButton.js:9:52)
at HTMLButtonElement.dispatch (jquery.js:5145:27)
at HTMLButtonElement.<anonymous> (jquery.js:4949:28)

{syntax type="tiki" editor="plain"}
Put the following in 11.x

{CODE()}# lorem ipsum
** lorem ipsum
# lorem ipsum
{CODE}

Then, preview, and compare

Sub-question: how does one do a ** in WYSIWYG? Normally, there are arrows to indent.

In IE & Chrome, it's OK

{img fileId="678"}

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))

When switching between wysiwyg and syntax, or visa versa, an "ajax error" is triggered. I have seen this error since tiki14, it is random, and happens so often, I have not seen the error in a long time since I was using tiki15x, but after installing a fresh instance of tiki16x, the "ajax error" is back. Please see screen shot:
{img fileId="1119" thumb="box"}
---
After configuring the show instance closely to my own tiki instance, and after installing text on the home page, I was able to recreate the "ajax error" when switching between wysiwyg and syntax.

{syntax type="tiki" editor="plain"}
When activating the WYSIWYG in either HTML or Wiki mode, I get an strange Ajax error that prevents me from even using the editor.

Please see SHOW and JCapture for demo

I also tested this on Firefox, Chrome (Mac, Win 7) and IE 9

Anchor are lost after parsing. Tested with WYSIWYG and with normal editor.

insert:
{img src=images/code.png}%%% {CODE()}
<a name="myAnchor01">bla bla</a>
{CODE}

after preview or saving
{img src=images/code.png}%%% {CODE()}
<a>bla bla</a>
{CODE}

When trying to create a new page with apostrophe in page name, the wysiwyg editor does not load

Cutting and pasting text often involves text which has paragraphs which begin with indented lines. These could be recognized by the editors and converted into paragraphs.

If text area feature "paragraph deindent" is turned on, a line which begins with two or more spaces should be converted into the start of a paragraph. In the normal editor, this text would be moved to the start of the line and a single blank line would appear as a paragraph separator. Note that multiple blank lines before the paragraph should be compressed to a single blank line. Text with indented paragraphs often does not have a blank line between paragraphs, so the code needs to ensure that a paragraph marker exists.

Some users don't want to understand the difference between "Page Name" and Link when creating an internal link.

This attached patch makes the Page Name field automatically fill in whenever the Link field is changed. The patch was made against tw 4.1.

I think it should be up for debate if both these fields are necessary. Many users of the WYSIWYG feature may be new to the concept of creating links. Less is simpler, and I vote for removing one of these fields.

P.S. Sorry about spamming the mailinglist with this request. Next time I will only submit patch here.

Some users don't want to understand the difference between "Page Name" and Link when creating an internal link.

This attached patch makes the Page Name field automatically fill in whenever the Link field is changed. The patch was made against tw 4.1.

I think it should be up for debate if both these fields are necessary. Many users of the WYSIWYG feature may be new to the concept of creating links. Less is simpler, and I vote for removing one of these fields.

P.S. Sorry about spamming the mailinglist with this request. Next time I will only submit patch here.

Some users don't want to understand the difference between "Page Name" and Link when creating an internal link.

This attached patch makes the Page Name field automatically fill in whenever the Link field is changed. The patch was made against tw 4.1.

I think it should be up for debate if both these fields are necessary. Many users of the WYSIWYG feature may be new to the concept of creating links. Less is simpler, and I vote for removing one of these fields.

P.S. Sorry about spamming the mailinglist with this request. Next time I will only submit patch here.

Location: local server
O.S. : Windows 10
Method: WAMP

Issue: Can't easily utilize FADE function. Assumption is when utilizing tiki on an active website, it will behave the same as a local server.

Request: Remove FADE as a plugin and instead make it part of TIKI so a user can just add FADE tags herself.

Benefits:
* This will ALWAYS work as opposed to right now, FADE magic wand won't
activate after it was already clicked on.

* User can drag and drop items into a wiki page and keep current formatting.
Yes formatting is intact when pasting, but NOT when pasting inside the current fade menu.

* User can edit at any time, move the faded items any where and keep formatting inside the FADE tags. Information is only handled once.

Example:
User opens a new tiki page utilizing the wysiwig editor.
User would paste formatted items into her page.

User adds FADE tags without clicking on the magic wand.
1. Prep your kit
[FADE color=red; iconarrow=no; title="Click here if you are a newbie"]
1. do something.
2. do something after first step.
3. do something again.
[/FADE]

Later, user edits the page again to add another FADE tag. This time NESTING and adding bulleted list with color fonts.

1. Prep your kit
[FADE color=red; iconarrow=no; title="Click here if you are a newbie"]
1. do something.
2. do something after first step.
3. do something again.
[FADE color=yellow; iconarrow=yes]
1. when condition is met do this....
2. if not your condition do this instead
[/FADE]

Open the following if you need to copy and paste 30 lines of code.
[FADE color=orange; iconarrow=yes]
30 lines of code
[/FADE]
[/FADE]


Expectations: When using WYSIWIG editor.

* Being able to keep formatting when pasting into a FADE user interface.
(It doesn't keep format, no bullet list, no colors)
(Also, when you save and view the page, the items pasted into FADE are all
jumbled page code, not neat listings.)

* Being able to utilize the FADE function more than once.
(It works once, then you have to save and re edit).
This causes needless tracking, needless rollback history.

0x40736375

Please see: ((tw:CMS Landscape)) and ((tw:Wiki landscape)) and try to edit those pages without getting lost.

Now you understand what we need :-)

Also: https://doc.tiki.org/Unified+Index

This looks cool:
http://twiki.org/cgi-bin/view/Plugins/EditTablePlugin

If a blog post is created in the wysiwyg editor (full html config) then viewed as a RSS feed then all the html tags are visible.

This is suspected as being a (very last ??) vestige of the parser/encoding issues we experienced in Tiki 9/10