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

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

See attached screenshot

This WYSIWYG code is provided by htmlarea, which is no longer maintained.
http://www.dynarch.com/projects/htmlarea/

So we should replace with http://www.<span style="color:black;background-color:#ffff66;">fckeditor</span>.net/, which is the chosen editor in Tiki 1.10

When I have two words side by side like this:
link1 link2

Then I select the first one and add a link to a file using the FILE tool tip in the edition bar and all is well and I get:
~np~{FILES( fileId="1")}link1{FILES} link2~/np~

Then I want to do the same with the second word. This does not work because it does not add it on the second word. Instead it replaces the first:
~np~{FILES( fileId="2")}link2{FILES} link2~/np~

Calls to plugins which are inside a call to the WYSIWYG plugin produce no output (which usually means that their effect is invisible). Some plugins, such as FOOTNOTE, have effects other than causing output, so calls to these may keep part or all of their effect.

This bug was introduced by the changes to wikiplugin_wysiwyg.php in {commit id=50752}. Tiki versions 14 to 18+ are affected.

The following call to WYSIWYG demonstrates:
{CODE(theme="default")}{WYSIWYG(use_html="n")}
This dummy content is visible.{FOOTNOTE()}Note which is invisible, but should be indicated by a number which is actually invisible{FOOTNOTE}
{GROUP(groups="Admins")}This should be visible for admins{GROUP}
{FADE(label="This should be visible")}Hidden{FADE}
{WYSIWYG}{CODE}


This happens because plugin_execute() calls ParserLib::convert_plugin_for_ckeditor() since ck_editor is true, and therefore returns an empty string to parse_first(), and therefore to parse_data(). That parse_data() has its ck_editor option true, since it is called by parseToWysiwyg(), called by wikiplugin_wysiwyg().

Unfortunately, the revision bringing this regression also fixes WYSIWYG edition. So going back to the previous situation breaks edition again. One can only choose between working visualization and working edition.

I believe the way to fix is to go back to parse_data(), but re-parse the plugin call's content differently when editing.

{syntax type="tiki" editor="plain"}
"Delete unused images" in the Admin panels does not affect images uploaded via the WYSIWYG editor, and the user interface does not provide any other means of deleting ANY images from the FCKeditor upload directory.

Can't post a reply on tiki.org forums! (wysiwyg textarea never shows up)
Tried here:
https://tiki.org/tiki-view_forum_thread.php?forumId=15&comments_parentId=57825

with chromium or Firefox and no way, from a desktop computer, as usual, where I've posted many times in the past.

Never ending "loading" bar is shown to me. with a user without admin perms.

Tested the WYSIWYG in 1.10 works very well, much to like, especially how well is handles paste from word.

__Needed:__ A popup warning to prevent a lost edit if you switch from wysiwyg to normal editor, this currently causes a ((doc:lost edit))

__Would be nice:__ the buttons in paste from word popup should be more clear "clean up box" should be named "clear box" if that is what it does.

__Would be nicer:__ Word html to Wiki syntax conversion (ignores all unsupported formatting

{syntax type="tiki" editor="plain"}
The symptoms are:
- backlinks work sometimes only
- when deleting a page it does not always become a wanted page
- others ???

The result is:
- unpredictable behavior
- negative impact on the user acceptance

The problem is, that the syntax of the links change:
Example:
1) Type "Page 1" in the WYSIWYG mode and save
-> "Page 1"
2) save again in WYSIWYG mode
-> ~np~<a class="wiki" href="tiki-index.php?page=Page+1" title="Page 1">Page 1</a>~/np~
3) save again in WIKI mode
-> ~np~[tiki-index.php?page=Page+1|Page 1]~/np~
4) save again in WYSIWYG mode
-> ~np~<a class="wiki" href="tiki-index.php?page=Page+1">Page 1</a>~/np~

This makes 3 1/2 different representations of a link to 'Page 1'

The multilingual/translation support is integrated with the WYSIWYG feature in a way that if you are working in an English interface, the text direction in CKEditor remains LTR even when the page being edited is defined as being in Hebrew, which is RTL. I expect that this applies to any other RTL language.

Similarly, it seems to me (though I haven't tested it thoroughly) that a user working in a Hebrew interface would get RTL behaviour in CKEditor even when editing an English page.

I can only assume that use of the English-language interface for editing Arabic pages and Arabic-language interface for English pages is common, as such combinations are certainly common where Hebrew is involved. The forcing of direction according to interface language rather than page language is likely to be a significant annoyance in all such cases.

The ideal solution would be to make the editor direction dependent on the page language's direction, and only according to the user's language if there is no page language set (there is a CKEditor option which does that - see http://docs.cksource.com/ckeditor_api/symbols/CKEDITOR.config.html#.contentsLangDirection)

When Javascript is minified, the ckeditor files are not loaded and (html) wysiwyg editing fails.

problem when using the (full) WYSIWYG editor with the latest IE version ie IE11

When using the link icon in the WYSIWYG toolbar (full html configuration), instead of the separate option for the Link Type being selectable from the drop down menu, ie for URL, Wiki Page etc., all the separate options are displayed one under the other and then everything locks up. You have to close the whole browser tab to get anything to work again.

Google searching suggests that this is a known ckeditor issue but was supposedly fixed with support for IE11 in ckeditor 4.3 - but it looks like the version of ckeditor in 12.2 is just 4.2.3

I think we need to move this up as 12.x is our LTS and a very significant numbers of users will use IE11 and will therefore be unable to use the editor.

13.x now has ckeditor 4.3.4 and IE11 seems to be OK in 13.x

Some buttons, such as table, do not show up on the WYSIWYG editor.

I have verified table in the list of plugins stored in the custom toolbar.

{syntax type="tiki" editor="plain"}
When using the Wysiwyg editor, there are 3 closing /np tags appearing after where the mouseover plugin is inserted in Tiki 7. This problem does not exist in Tiki 6.