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

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

{syntax type="tiki" editor="plain"}
This bug is seen by our IE 8 clients. 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.

Our users are editing in the CKEditor WYSIWYG and try the Code plugin from the toolbar. The Code window opens as expected and the users enter their code in the correct field. On pressing Insert (or Replace) the code plugin is added in the editor but there is no contents in the plugin. If I open the normal editor it displays as%%%~np~{code caption="MyCode.java"}~/np~%%% which is completely the wrong syntax.

If I try using the Code option in FF then it opens a new window and I can add the code just fine. I view from the normal editor and it reads%%%~np~{CODE( caption="MyCode.java")}public class MyCode {
//testing a point
}{CODE}~/np~%%% which is correct.

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

Thanks,
Tim

There is an example available.
However this is how to reproduce the problem:

Let's say I have a page NamespaceA:_:Home
Then I edit that same page throught WYSIWYG editor creating a wiki-link to the not-yet-existing page "Target". In source code this corresponds to ((Target)).
Once the page is saved I click on ((Target)) link. This way Tiki automatically creates NamespaceA:_:Target page.
I'd like to underline this is an extremely useful feature since it allows even not-developer users to create new pages with the correct namespace without having to mess with the source code, which is a desirable feature.
However once NamespaceA:_:Target page has been created, no backlinks are present in there.

However if now I edit page NamespaceA:_:Home by adding a wiki-link to "NamespaceA:_:Target" (in source code this would correspond e.g. to ((NamespaceA:_:Target|Target)) ), the link works just fine and moreover a backlink from NamespaceA:_:Target to NamespaceA:_:Home is generated.

Option "Force all non-namespace page links to the same namespace" does not seem to solve the problem.

---------------------------------------------------------------
In short: ((Target)) and ((NamespaceA:_:Target|Target)) are both valid links towards page NamespaceA:_:Target (starting from page NamespaceA:_:Home), but one is recognized as a backlink by Backlinks plugin while the other one is not.

----------------------------------------------------------------
The problem lies in the fact that if a not-developer user were to use Tiki, the above-mentioned feature of automatic page creation with correct namespace would be extremely useful but it introduces the above-mentioned problem.

----------------------------------------------------------------
I think one possibility would be to edit Backlinks plugin to recognize ((Target)) as a valid link to NamespaceA:_:Target as well (in this context, taking into account the namespace of the page on which the link resides).

Another possible solution would be to have WYSIWYG plugin work (optionally?) in a little different way: if I am in page NamespaceA:_:Home and I write a link towards page Target it should automatically translate the link in ((NamespaceA:_:Target|Target)) instead of just ((Target)). Maybe this second solution is cleaner? I don't know.

Thank you very much for your attenction

{syntax type="tiki" editor="plain"}
Looking in the browser at the underlying xhtml code of a wiki page edited in WYSIWYG, I see that the whole page is enclosed in a p tag as follows:
^<p><h1>Big title</h1><p>some text</p><h2>Subtitle</h2><p>more text</p></p>^
Compliant xhtml must comply to html 4 and html 4 prohibits block elements (including <p> itself) inside a <p> element.

Check video

When creating a table using the table button in the editor. the table acts and feels exactly how you set your preferences.

Once you save then all the formatting leaves

If you try to edit the table properties after then they never get applied

Show Account Info

user: admin
password: 12345

{syntax type="tiki" editor="plain"}
Just pretty inconsistent behavior depending on the browser. Images get converted to HTML images, sometimes the tiki_plugin div disappears etc.....

{syntax type="tiki" editor="plain"}
dev.tw.o: users apparently can delete their tracker items but they are not deleted and no message

To reproduce:
* Log in as normal user to dev.tw.o (without admin perms) (ot test with user "xavi" if you prefer).
* report a bug/wish
* edit it in order to see the edit form
* click on the red cross to delete it
* after that, you are shown the list of tracker items, as if your tracker item was already deleted. No message indicating any problem is shown. However, the tracker item is not deleted.
+ Example: http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=2879

---
reported in comments as still around in tiki5 and tiki6

{syntax type="tiki" editor="plain"}
Turn on the WYSIWIG editor, then try to edit the "HomePage" of a mint installation, the page is uneditable and you see borders of the invisible div. {IMG(id="119")}{IMG}

It is harder than it needs to be to use an image on a wiki (or other) page. you have to upload the image, then remember the id and use it on the page, or slightly better, upload an image then drag it to the screen.

The preferred behavior would be to select the image icon, which would then offer to upload or use one from the library. (so far, just like it is today) Then once you have uploaded an image, it should automatically use the image(s) uploaded and create the img tags on the page at the cursor. If I am uploading images, I should not then have to re-select the images to use.

There is at least one other recommendation to drag-drop images, which would be nice, though I suspect a bit harder to do, and would not invalidate this suggestion.

A suggestion (for that one) was to use the jcapture plugin, which is actually harder than the current approach as you have to use something else to display the image, then adjust your window(s) to display it, capture it, and still have to use it.

Any WYSIWYG edit to a WYSIWYG zone (defined using the WYSIWYG plugin) fails quietly if the call to the plugin follows an inclusion (made using the INCLUDE plugin). CKEditor goes away as expected and the contents of the zone are displayed, but instead of the new contents, the old content shows.

This bug exists in Tiki 12 and persists in trunk as of r64360.

If wiki page Parent includes page Child, the following WYSIWYG zone causes the wysiwygPlugin() function to be called at page load with its page parameter set to "Child" instead of "Parent" as should be the case. Which causes the AJAX calls to action_replace() from edits to have the wrong value for their page parameter, causing them to have no effect, and action_replace() to return simply "~np~[]~/np~".

wysiwygPlugin's parameter is wrong because wikiplugin_wysiwyg()'s $sourcepage variable has the wrong value, because it is wrongly set to $wikiplugin_included_page instead of $page. This is due to a parser context management issue.

Some wysiwyg wiki pages lose content on edit-save.

Just editing the page, not changing anything and saving changes the page display.

Example with a ~np~<br style="clear: left;">~/np~ which is changed into ~np~<p> </p>~/np~

The result is loss of confidence into the wysiwyg edition from users, since parts of the page they did not edit are visually messed up.

------
!Issue

If you look at [http://jyhem-9952-5164.show.tikiwiki.org/tiki-index.php?page=JML+test+03] and view the source of revision 1, it contains
{CODE(wrap="1")}<table align="left" border="1" cellpadding="0" cellspacing="0" style="width:50%;">
<tbody>
<tr>
<td style="text-align:left;">
<div class="more" style="text-align:left;margin-left:36px;">
<p><strong>Contents</strong></p>
</div>

<p>bla bla bla</p>
</td>
</tr>
</tbody>
</table>

<br style="clear: left;">
<h2>Distribution</h2>

<p>Although the disease probably originated in southeast Asia, the first recording of the disease was made in 1874 in Australia, where it was observed at Eagle Farm near Brisbane</p>{CODE}

And visually, the Title __Distribution__ is ''below'' the table because of a ~np~<br style="clear: left;">~/np~

If this is not what you can see in [http://jyhem-9952-5164.show.tikiwiki.org/tiki-index.php?page=JML+test+03], just rollback to version 1

Then you can edit the page, and it does not show correctly. If you save it without touching anything, the code is now:
{CODE(wrap="1")}<table align="left" border="1" cellpadding="0" cellspacing="0" style="width:50%;"><tbody><tr><td style="text-align:left;">
<div class="more" style="text-align:left;margin-left:36px;">
<p><strong>Contents</strong></p>
</div>

<p>bla bla bla</p>
</td>
</tr></tbody></table><p> </p>

<h2>Distribution</h2>

<p> </p>

<p>Although the disease probably originated in southeast Asia, the first recording of the disease was made in 1874 in Australia, where it was observed at Eagle Farm near Brisbane</p>{CODE}

This should not happen (change the page content when no change is actually done). On big pages, it is impossible to go edit a little part of the page and then check that nothing else anywhere else was changed :-(
This has 2 main visual problems after edit-save:
* The title __Distribution__ is not ''below'' the table, it wraps on the right side.
* There is an extra line below the title __Distribution__ due to the newly appeared ~np~<p> </p>~/np~

Using version 4.3

After insertion of an image using "Insert an Image" Right clicking on the image brings up the context menu and then clicking on "Image Properties" should bring up the original settings menu.

The original settings are not in the window. The window is in fact the window for inserting a new image. Using the window puts in another image.

The only way to change the attribute settings with "Vspace" and "Hspace" or the size of the picture is delete the current picture and put in a new one.

"Insert an Image" is part of the WYSIWYG system.

With the WYSIWYG editor enabled (but html not checked in the wiki settings), I am unable to use wiki syntax in the normal editor when I save or preview. That is, the wiki markup shows up as text on the page.

It switches back to WYSIWYG after pressing preview as well.

If I enter html in the Normal editor it works fine.

Wysiwyg editor in tiki-editpage.php narrower in IE7 than in other browsers. It is not taking u p the full width of that middle column. This is the case in 3 column layout (did not try in other layouts). This is irritating as it causes toolbar buttons to wrap.

{syntax type="tiki" editor="plain"}
I have a problem, i dont know how fix it
In tiki4.2 in wiki pages (others doesn’t show this error) editor wysiwyg, does insert an image but it change the code with this code
{…}, (I know cos I saw it , in the html view)
But when I save it doesn’t recognize the image, If I return to the html editor and change the {…} With <…>, it works

Somebody can help me??
(:wink:)

When using wysiwyg, a link such as:

~np~[Etiquette|Etiquette&Guidelines]~/np~

results in a link which displays as:

Etiquette &amp; Guidelines (i.e. the ampersand gets encoded)

Try typing in an email address while using wysiwyg. It becomes something like

{CODE()}
ript language="Javascript" type="text/javascript">document.write('someone'+unescape('@')+'somewhere.com');
{CODE}

When editing a wiki page using the FCKEditor, trying to upload an image gives problems. I receive a successful upload message, and when browseing the server at /domain.org/img/wiki_up/image.gif get an error message which states,
"Error creating folder /home/jsullinger/domain.org/html/mytiki2/mytiki2/img/image/, permission denied". Permissions on folder are chmod 777."

I checked some of the previous trackers, and it looks like perhaps it is felt this issue has been fixed? This is a very important feature with respect to WYSIWYG editor, and would be greatly appreciated if this could be looked at. Let me know what additional information you need.

While editing a wiki page i can set and upload an image.

Clicking on the picture image i get to the image properties windows.
In the tab "Image Info" i choose "browse server" and from there shows up the FCKeditor ressources browser.

I choose to create a folder, input name and upload picture.
Then the picture is available and i can choose it and validate it back throught the "Image Properties" windows where the image url show:
/tikiwiki10/img/wiki_up/image/test/tv.png

The picture image is broken
It keeps broken after wiki page save

When i reedit the page and open for this picture the "image properties" it shows as image url:
http://mydomain.com/tikiwiki10/img/wiki_up/image/test/tv.png

The image is not there of course, it have been installed in a folder test 3 step up from the root of my website !

Meaning that path should have been : /var/www/sites/xxx/xxx.com/subdomains/www/html/tikiwiki10/img/wiki_up/test

and the folder test has been in fact created here:
/var/www/sites/xxx/xxx.com/subdoma/tikiwiki10/img/wiki_up/test


And that... is not good at all :)
But it is not over.


If i upload manualy the picture and edit the wiki page i can add in the "image properties" the direct url to the picture after clicking the ok button it show nice in the preview page.

If i save the page the image link is changed for something like:
http://xxx.com/tikiwiki10/show_image.php?id=5

And there again... no picture shows on the saved wiki page.

{syntax type="tiki" editor="plain"}
Cannot use wysiwyg editor in blog if we want also to use excerpt feature.

If any temporary or fixed solution can be found...

Many many thanks

external links are being "cleaned up" on subsequent changes in the wysiwyg (when I first save I get the external link icon and target _blank but when I reload the article in the editor, the icon is gone, and also target=_blank).

After checking out 1.10 from svn and enabling FCKEditor, attempts to use the editor fail with an error claiming the tikiwiki toolbar does not exist. More specifically, FCKEditor loads, but there are no toolbars.

This bug is seen by our IE 8 clients. 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.

When our users are editing in the CKEditor WYSIWYG and try the File option in the toolbar there is a Javascript error for lib/jquery_tiki/tiki-jquery.js at line 808 char 4. What is happening after the error is thrown is that no new window is opened (as expected) but the File selection fields are now under the WYSIWYG Editor. This wouldnt be an issue, but there is no OK button to select the file so our users can not like to a file in the File Gallery.

If I try using the File option in FF then it opens a new window and I can select the file just fine.

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

Thanks,
Tim

Editing a WYSIWYG section in a page may leave the semaphore on the page after saving or cancelling the edit, due to a session bug exposed. This can be worked around by waiting the lock's expiration, or by editing the full page and using Cancel Edit.

The bug seems to occur only when session_storage is set to Database. File-based storage apparently does not trigger. When 2 concurrent AJAX requests are processed, changes to the session made by the first can be lost by the second request. Presumably, this is only true because the first request completes after the second one starts but before it ends.

The scenario where the WYSIWYG plugin exposes is that initiating an edit causes 3 AJAX calls to SemaphoreController:
# one to is_set
# one to set
# one to tohtml

Request 2 modifies $_SESSION to add a key storing a UNIX timestamp (on the pre-last line of action_set()). On a wiki page named "TestWYSIWYGPluginNoHTML", that key would be 'semaphore_TestWYSIWYGPluginNoHTML_ wiki_page'.

~np~When cancelling (for instance), 2 requests are made. The problematic one is the call to unset. The call to $this->table->delete() in unset() fails because $lock is empty. $lock is empty because $_SESSION[$this->getSessionId($input)] evaluates to null.~/np~

This affects revision 65380 of trunk.