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

{syntax type="tiki" editor="plain"}
Hello Devs,

I did upgrade a site to 7.1 this weekend.

Using WYSIWYG/CKE I have the following prblem:

In some features of the Tiki 7.1 the output the editor is just the plain
HTML Source.

That means, not in Wikipages, but in the articles and in the calendar
events, there is not a nice text with formatting bold, italic, colors
and pictures etc, but only the plain HTML source code visible to the
website user/visitor.

The WYSIWYG/CKE editor works normal and I can see the content just
normal like ever, being in the editing mode. But when I save, I can just
see the source code, like it would be in codeplugin.

This affects as said articles and calendar (perhabs more, I will hope to
find out) but it does not affect wikipages by now.

And it affects existing articles and events aswell as newly edited.

(worked well in 6.x before)

Thx for reply and wish a nice sunday to all,
cheers
Torsten

On a wiki page if you set a Tiki Plugin with a very big content (pictures in a slider) it is displayed all over the page under (or over) the rest of the wiki page content.

{img type="fileId" fileId="304" thumb="y" height="25%" width="25%" noDrawIcon="n"}

Toolbar setting done on Tiki-admin_toolbar.php are not applied on wiki page.

Go to http://demo.tiki.org/11x/tiki-admin_toolbars.php
I have removed on purpose "B" (bold) button on global wysiwyg.

Create or edit a page it is still in place.

~~#F00:Note: ~~It in the db the tiki-preferences got a field "toolbar_global" and the value reflect the changes i made. Still they are not applied.

WYSIWYG toolbar for the text_area field is not working if field is set to multilingual.

Check the instance: http://bsfez-11581-5068.show.tikiwiki.org/tiki-list_trackers.php

I have set 3 trackers.

One with 2 text area and 2 with a single text area (one set multilingual yes, one with multilingual no).
Only the single one with multilingual = no work properly.

Since the 14.2 release, any page I have with a row of images, containing links to URL's, do not line up properly.

All are displayed correctly inside the wysiwyg editor, as shown here:
{img fileId="1034" thumb="box"}

In v13.0 and previous versions, my live page looked the same as above, however, in 14.2 all images are displayed on a new line, so my page looks like this:

{img fileId="1035" thumb="box"}

My page code looks like this:
~np~
---
__Social and Online Media__
{img fileId="26" width="48" link="https://www.facebook.com/"}{img fileId="28" width="48" link="https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CDoQFjAA&url=https://plus.google.com"}{img fileId="27" width="48" link="https://uk.linkedin.com/"}{img fileId="29" width="48" link="https://twitter.com/"}{img fileId="17" width="48" link="http://www.lovefilm.com/"}{img fileId="30" width="48" link="http://www.youtube.com/"}
~/np~

What has gone wrong?

r46077
In a tracker, when i set a field "text area" to use toolbar and wysiwyg i will have a lot of Unwanted alert "You are about to leave this page". Go at :[http://dev.tiki.org/tracker5] Click on the button "View Items".

http://dev.tiki.org/tracker5

{syntax type="tiki" editor="plain"}
My "was just fine with Tiki29" tracker forms have now extra space added after a text Area tracker field.

{img fileId="3263" thumb="box"}

Hi there,

it is very unhandy to attach files or include images in wiki pages, articles or any other content a user provides. Until now, there are means like:

a) Upload a file to a file gallery and reference it manually using the link given.
b) Upload a file to a wiki page and reference it manually.
c) Try using the WYSIWYG editor and realize it does not upload the image.

Well, what I did is I added some quicktags to your code that opens a custom upload file dialog with a preselected file gallery. The user can browse, upload and add the file into his content in one step. Basically it uploads the file and appends the wiki code at the cursor position.

I will attach you all my environment...there is a file itb_readme.txt in the root which describes in chapter 3 all the changes I do...maybe somebody of your development team assesses this as an important feature and can leverage some code...

Regards,

Maic

Serious problem with IE8 since it is still a major browser for many users ie they haven't generally upgraded PCs for a while and are still running XP so cannot use IE9 and may not be allowed to use another browser.

An error occurs for lots of individual plugins - eg BOX, FILE, IFRAME, INCLUDE etc., etc., when trying to open the plugin editor in the wysiwyg edit screen.

The simple IE8 debugger says:

/lib/ckeditor_tiki/tikiplugins/plugin.js?t=D3NA, line 37 character 6

Error: 'null' is null or not an object


Plugin editor opens OK when accessed direct from the wiki page using the edit icon.

FIXED

{syntax type="tiki" editor="plain"}
Please see the result of the diff:
{flash type="url" movie="display291" width="579" height="545"}

http://demo.tiki.org/wysiwyg-wiki/tiki-pagehistory.php?page=ffffffff&history_offset=1&diff_style=sidediff&show_all_versions=y&compare=Compare&newver=0&oldver=10&paginate=on&history_pagesize=24&bothver_idx=10

{syntax type="tiki" editor="plain"}
WYSIWYG editor is displaying theme background inside of edit box using darkshine. This results in the red and red stripe background behind your editing, but this background does not appear behind the wiki page when viewed (displayed on white, as is desired)

the SORT plugin works perfectly when set up using the standard wiki editor eg

~np~{SORT(sort="asc")}~/np~
rabbits
cats
dogs
tigers
zebras
pigs
lions
horses
~np~{SORT}~/np~

produces:
{SORT(sort="asc")}
rabbits
cats
dogs
tigers
zebras
pigs
lions
horses
{SORT}

But if the same 'code' is set up in the wysiwyg editor it does 'sort' the list but does not display the result on separate lines ie it produces:

cats
dogs horses lions pigs rabbits tigers
zebras

Create a page using the wysiwyg editor and make some page links.

Then create the page from one of these wanted links.

The wanted links are not converted back to normal wiki links (still look like wanted links)

Images that are added using the wiki editor (anyway the normal editor, I didn't check the wysiwyg editor yet) don't have a default class. This is the simple case of no containing box or anything added along with the image. Therefore it isn't possible for them to have a default style such as margin or border unless it is added manually by the page author. Or if it is specified by the stylesheet (.postbody img or .wikitext img, etc.) then ''all'' images in those divs get the treatment, including smileys and external link icons, etc.

I suggest adding a default class like "contentimage" to enable a default style. Page authors can always add a second class if needed.

The wysiwyg_wiki_parsed preference influences WYSIWYG edition, [https://tiki.org/forumthread67421|even if it was not supposed to]. When it is enabled, what one sees in the WYSIWYG HTML (wysiwyg_htmltowiki disabled) editor is not necessarily what one gets. For example, if one enters ~np~"__Text__"~/np~, "Text" will be displayed in bold after parsing, the underscores parsed as if the page contained wiki syntax.

This issue persists in trunk as of r65130. Moreover, following r30245 (2010-10-23), this behavior is "specified" by the editor's help. So fixing this may be considered as a semantic change for existing data. A simple fix without data conversion could disappoint user expectations. Plus, HTML WYSIWYG does not have equivalents to some wiki features, such as plugins.

[https://dev.tiki.org/item6532|Ticket #6532] reports a corresponding bug when wysiwyg_htmltowiki is enabled.

The WYSIWYG wiki editor (feature_wysiwyg enabled) allows typing HTML tags. But if "Use Wiki syntax in WYSIWYG" (wysiwyg_htmltowiki) is enabled, this HTML is not interpreted, just displayed literally.

This does not work however. As soon as the editor switches to Source, or saves the page, an attempt to convert all HTML markup to Tiki markup is done. This conversion is lossy and loss is quiet. For example, if I have...
{CODE(colors="htmlmixed" theme="default")}<table><caption>Title</caption><tr><td>Value</td></tr></table>{CODE}
...it will be converted to...
{CODE(colors="tiki" theme="default")}||TitleValue||{CODE}
Unsupported tags are apparently just removed.

Strangely, if one copies a string with HTML in the WYSIWYG textarea and pastes it in the same area, the paste shows the result of interpretation (the HTML tags are no longer displayed literally).

[https://dev.tiki.org/item6523|Ticket #6523] reports a corresponding bug when wysiwyg_htmltowiki is disabled.

Text boxes do not save in WYSIWYG mode. Even switching from WYSIWYG to Source and back will remove much of the formatting. I have turned this feature off for the time being because formatting is automatically removed when you go to edit a wiki.

This is mitigated by a warning in edit help:
{QUOTE()}The conversion process is not entirely transparent, meaning that you may notice differences between the look of a page in different modes.
This will improve in future updates but as the two systems have significant differences in what they can do it is unlikely to ever be totally transparent.{QUOTE}

Renaming a page does not change links in pages created using the wysiwyg editor

{syntax type="tiki" editor="plain"}
In edit mode, if I do

{CODE()}
((
{CODE}


(and maybe a few letters), an auto-complete should appear, like the quick_edit module. This list should be WYSIWYCA.


This would also be useful in some plugins, when a parameter is wiki=

The most important is ((doc:PluginInclude)), because the main goal of the plugin is to include other pages, which you may not know the exact name.

When in plugin edit mode, an auto-complete could be done with jQuery (ask LPH for details)

Related:
{wish id=480}

__problem __with Russian (and, as I understood, any non-English character language) wiki-links in CKE Editor (and plugins):
1. Let's create wiki page named "Фичи" (copy-paste, hope it'll be work)
2. Create page with any name e.g. test with wiki-link to a first page ("Фичи").
3. Link is broken. becouse on the stage of convertation from wiki-link to CKE URL something goes wrong and if You click on this link and choose "Edit Link" you'll see "tiki-index.php?page=Фичи"
3.1 Yes, link is broken:
Page not found
äøÃÂø
----
Hint: without WYSIWYG editor all will be ok. No broken links with any symbols.

__Why priority is high?__
-becouse we can't create ANY wiki-links from CKE-editor if wiki page named with non-Latin leters.

p.s.
double-checked here http://php.opensourcecms.com/scripts/details.php?scriptid=63
with WYSIWYG_6x profile.

tags: utf-8, russian, link, wiki

{syntax type="tiki" editor="plain"}
When I create a link to a Wiki page, the editor changes the reference of the link until the fourth time when I edit the page, but this is not a problem. The problem occurs when the link points to a wiki that has a special character, for example - cabeçalho - which means header (in Portuguese from Brazil), since the editor corrupts the link and it crashes.

Here I have an example.

The link should point to the wiki - Projeto de Pesquisa Social: Quem somos nós ? Proeja 2010 - is corrupted by the editor and points for - Projeto+Pesquisa+Social:+Quem+somos+n%C3%83%C3%83%C3%83%C3%83%C3%83%C3%82%C2%B3s?+Proeja+2010 -


Here we have a wiki page as an example:
http://www.biblioteca.ifc-camboriu.edu.br/criacitec/tiki-index.php?page=Example

{syntax type="tiki" editor="plain"}
This seems solved in Tiki 5.

''type content'' : Problem, way to go around and may be a quick way to go to a solution

Hy,
4.0, 4.1

I test all functions including those that are not finalized.

The problems occurs with Firefox 3.5 not with IE8 (other ie not tested neither opera, google etc...)

In WISIWIG text editing WIKI obtained in circumstances that I can not confirm the background color of textarea is black when you scroll to the end of long text (the text is more long than the height of textarea).
The content text exist and you can see it if you select it and change the text background color.
The problem is the scroll with the background property color (in strasa css #F3FCFE color)

''Complements''
*Problems occurs in wysiwyg mode (not in view source mode)
*If you change the background color of the text you can see it
*The problem is directly linked to scroll, when you change the textarea size (for example go to "fullscreen" edit), the black background appears at the bottom just one line after beginning to scroll down



I hope to have provided informations to go straight to the bug.

Best regards

I have a strange problem on Tiki 2.0RC2:

I have two similar TikiWiki-installations. One just for testing on my Linux-Server and the second on a WinNT-Server. The Windows-Server is the one we want to/have to use for our Wiki :-(

On my Linux-Server works everything.

On the Win-Server don’t work wysiwyg-editor’s “Insert/Edit an internal wiki link”-button. The “window” opens but it shows only this animated waiting-bar. (See the picture)
Any other button works fine!

--I was originally having a smaller wysiwyg bug on my tiki 12 instance, but I'm not sure what is going on with it anymore after testing with a fresh instance.

On the current instance created for this ticket, the formatting bars (Format, styles, font, size, etc) are not showing up for WYSIWYG, and going to the toolbar admin and changing things doesn't change the toolbars for the WYSIWYG, but changing things for "Wiki only" added them to the WYSIWYG too.

It seems to be acting really weird, and "link" and "unlink" show up when you go to the editor toolbar admin, but don't show up in the editor (feature is enabled).

user: admin
password: 12345

update: looks like maybe WYSIWYG only shows the "visual wiki" toolbar, but I'm not too familiar with how that works. Hopefully this is user error, but I've customized editor toolbars in tiki wiki before, and this seems to be working strangely.--

!!Here is a more concise explanation of what is going on. Ignore Above

Turns out it was in fact mostly user error + confusingness, though there is a bug.

bug:
Setting the toolbar selection mode to "WYSIWYG Only", and then adding an icon to the toolbar adds the icon for all editors instead of just WYSIWYG. This is present in tiki 11 also, but I can't seem to destroy the instance and test other versions (tried from multiple browsers).

Possible bug:
"Link" icon tiki WYSIWYG does not set link element class to "wiki" by default, resulting in possible css/styling inconsistencies. Links created with square bracket tiki syntax always have class="wiki external". I think that links from both should be generated with same class so css can apply to both without having to set css for all anchors just to cover links generated by "Link" (but I'm not a CSS guru, so I don't really know css best practices. Seems inconsistent though).

Discussion/What I thought was a bug:

I had previously talked about the lack of formatting bars (Format, styles, font, size, etc) in wysiwyg being a bug, but this is not really bug. In tiki 12, the "Use Wiki syntax in WYSIWYG" perference's description says "Using wiki syntax in wysiwyg mode will limit toolbar to Wiki tools", which would make it so that only the visual wiki toolbar shows up when you are in the wysiwyg editor, and you don't get any WYSIWYG toolbar icons (as I understand it).

When you enable WYSIWYG, the "Use Wiki syntax in WYSIWYG" preference is enabled along with it by default, meaning that by default WYSIWYG does not actually have any WYSIWYG toolbar functionality, and is really tiki toolbar icons with a wysiwyg text interface.

The reason I thought this was a bug was because I did not understand the implications of "Use Wiki syntax in WYSIWYG", and in tiki 11.0, with "Use Wiki syntax in WYSIWYG" enabled, the toolbars were still usable. The description still stated "Using wiki syntax in wysiwyg mode will limit toolbar to Wiki tools" however, suggesting that perhaps in tiki 11.0, the fact that the formatting bars still worked was itself a bug. However, if that can happen through a bug maybe that is something that should happen intentionally? Seems like a big loss that if you enable "Use Wiki syntax in WYSIWYG" you lose the entire WYSWIWYG toolbar, and you don't get a hybrid toolbar. Anyway, just throwing that out there/explaining confusion.

On the admin page for the WYSIWYG editor it would be handy to have a text box available to set the default upload directory used by fckEditor so that we could select (and enforce) a suitable location on the server (such as C:\TikiWiki\img).