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

the button "insert internal link" (on the WYSIWYG-editor) doesn't work.

it opens a new window "local.php not found -- This is normal if you have not run the tiki installer yet".


(but i run the tiki installer)

the button "insert internal link" (on the WYSIWYG-editor) doesn't work.

it opens a new window "local.php not found — This is normal if you have not run the tiki installer yet".


(but i run the tiki installer)

Contributors

If a user uses CTRL-Z on a page that they are editing to undo a change, they will break all internal wiki links on the page on the next save.
This appears to only happen when editing with firefox.

The edit button (and switch to wysiwyg) link to nowhere (except back to homepage.)

This appears to be an ajax related problem many buttons/links do not work.

verified on my site and 110.tikiwiki.org

edit button links to:
http://sitename.com/#


switch to wysiwyg does not work, navigation buttons in list-pages,

After creating a new blogpost and saving it, the post shows a lot of empty lines at the beginning of the post.
Looking at the html result, there are about 9 <br/> entries before the actual text.

The branch is downloaded on wednesday, 25th of June 2008 8AM GMT.

A 1.10b1 release of about a month ago did not show this behaviour.

Contributors

Contributors

Once saved, style changes (such as setting the font size or centering text) results in pages displaying like these:

My test starts here. Not much of yle="font-size: larger">interest going on though!
AND
yle="text-align: center">Home Page Test

Clicking to insert an image: dialog is displayed buyt clicking on the Browse server button results in the error "Error creating folder "" (Can't create directory)". Manually entering an image in source view mode (<img src="blah-blah">) and saving results in: img src=/home/lib/fckeditor/editor/blah-blah height=30 width=28 (surrounded by curely brackets)

Both related to parsing the html from the WSYWIG editor?

Clicking "Insert/Edit an internal wiki link" shows the "Insert Internal Link" popup but no content is displayed. The dialog briefly shows a cancel button and then the "wait squares" but nothing more.

Found with clean installs of 2.0RC4 on Windows Server 2003 x32 and also server 2008 x64. PHP 5.2.6 (x32); MySQL 5.0.51b (x32 and x64); Apache 2.2.9 (x32)

(sorry if these aren't sufficiently related and should be in separate bug reports)

Hello,

sorry for my bad English, but I´m from Germany and I´ve got my last lesson at school - nearly 20 years ago...

So I hope that you will understand me, here my problem :

I use Tiki 2.0 RC4 with the "andreas08"-Theme. It works quite good, but this bug (maybe ?) happens when I try to edit and save the Theme-CSS via the Admin-Menu :

Some command lines will be added with a "x" (included by tag-brackets) and the instruction given by this command will be ignored - cause it´s "rubbish" than.
( I can´t show you an example, i tried it, but here the "X" in the brackets not appears after saving this thread. )

This strange "effect" also happens by editing or formatting an text by the wysiwyg-editor, so that the text appears with some "rubbish" code-tiles instead of the formatted styles. (Text-Color, Size, Justify, etc.)

I´m not sure - is it a bug, or is this a failure caused by myself ?

Thanks for any answers or comments an greeting form Germany.

Hofnarr

Contributors

If I create a table using the WYSIWYG Editor and click on the __Source__ button, the generated code is using HTML code like this:

<table>
<tbody>
<tr>
<td></td>
</tr>
</tbody>
</table>

Instead of the real Wiki Syntax for tables ([http://doc.tiki.org/Wiki-Syntax+Tables]).

I guess a "HTML->Wiki Syntax Translation" setting must be missing.

As an example, I found out a MediaWiki WYSIWYG CKEditor that does this same translation just fine. Maybe you could check out the code:

[http://www.mediawiki.org/wiki/Extension:WYSIWYG|Extension Homepage]
[http://sourceforge.net/projects/halo-extension/files/SMWHalo%201.5.3_b36/MediaWiki%20extensions/wysiwyg-1.4.1_3.zip/download|Download]
[http://smwdemo.ontoprise.com/index.php/WYSIWYG_Sandbox|Online demo]

Thanks a lot!

In displaying a calendar event it doesn't display as written in the edit window using WYSIWYG. Instead it displays with the HTML code.

The WYSIWYG editor should have a button to create HTML comments that will only be visible in edit mode, and not in read mode.

As with all HTML, the comment tags should not be visible in WYSIWYG mode. The commented text should be a different color; perhaps grayed out.

This feature would enable editing discussion to happen right within the page being edited. Editors could more easily reference the text under discussion, since it would be right next to the comments. Discussing pages separately in the forum would no longer be needed, or would be optional.

I created a test newsletter on a new tiki 4.x (using recent svn, similar to tiki4rc1)

* Switched editor to wysiwyg
* copied some content from this page: http://en.wikipedia.org/wiki/Paul_R._Ehrlich (from the title "Paul R. Ehrlich" until the title "other activites" (so that, it's including also a few images available on the internet, in case it matters)
* cliked on the switch editor button (to go back to a normal editor showing wiki syntax)
* a blank page is produced, after 10-15 seconds.

! Update to below, see attached screenshot. Just discovered a pop-up application for pasting text. Very weird to see after decades of pasting text the old fashioned way ;-)

!!WYSIWYG Editor Tiki 5 RC-1
fresh from svn

__Cannot paste text into editor __
*anything pasted just disappears
*tried wiki and blog post
*tried 5 Alive and The News themes
*tried Mac Safari and Chrome


__Cannot paste text__
TW 4.1: Edit a wiki page with WYSIWYG editor:

#Can type & use formatting tools.
#Cannot paste text. When Text is pasted, the desired text appears very briefly, sort of flashes on the screen, then disappears. Saving at this point saves any typed or formatting changes, but the pasted text does not appear.
#Can switch to Wiki Editor, paste text, switch back to WYSIWYG and format it from there.

Hi,

Into the wysiwyg help on plugins, the height of the scroll list of plugins is superior to the eight of the popup. So the bottom of the list and scroll commands are not accessible.

The height is calculated from the height of the popup with is resizable.

[enhance] request : set a button into "plugin" to select the suitable plugin.

May be change tooltip of help to Help "Help on wysiwig syntax and plugins" rather than "Wysiswig"

The plugin manager should include the "help plugin which is into help", after the choice of plugin the manager help to fill it and include it.

I imagine that's the working is doing but I just add may be my view of this part of the Wysiwyg implementation.

Since r19838, Admin templates uses the WYSIWYG editor even if WYSIWYG was not enabled. The root of this problem is usage of the Smarty wysiwyg variable, which is not always set since r9595.

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

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.

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

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

"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.

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

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 ~np~((Page 1))~/np~ in the WYSIWYG mode and save
-> ~np~((Page 1))~/np~
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 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.

Contributors

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

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.

Just pretty inconsistent behavior depending on the browser. Images get converted to HTML images, sometimes the tiki_plugin div disappears etc.....

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

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}

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.

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.

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

Not totally sure if this is feature request, bug, or lack of knowledge. Basically I need some way of supporting maketoc with WYSIWYG pages.

If you click on an Edit Section button, the Switch Editor button is not available when you are editing.

Hi,

Using Wysiwyg, I upload a image then it is stored in like .../wiki-up/image/xxx.jpg.
Under MutiTiki environment by domain name, this page does not show the uploaded image.
The source of the page shows that ".../wiki-up~~#FF0000:/domain_name~~/image/xxx.jpg" while that image was stored in .../wiki-up/image/.

So I guess that FCKEditor has to store a image into NOT .../wiki-up/image/ but into .../wiki-up/~~#FF0000:domain_nmme~~/image/ under ===MutiTikiwiki environment===.
(How to know for FCKEditor that the site is under MutlTikiwki, I don't know)

Thanks and Best Regards,
Shigeru Serizawa (Japan)

In IE7, after double clicking an image to get the image plugin editor and making changes, a new image is created at the top of the page instead of editing the image plugin.

In IE8, the same attempt appears to make no changes to the plugin, but no new image appears either.

This works in Firefox.

adding pref will "fix" this. However, for IE, there is an additioal CKEditor bug that still needs to be fixed: [http://dev.ckeditor.com/ticket/4208]

Critical Usability Problem With WYSIWYG Editor

Version 4.3

"Insert an Image" does properly put an image in the Web page but the editor does not preserve the "Vspace" and "Hspace" attributes in the source code. It is not possible to do spacing around an image in a Wiki page.

The editor properly shows the spacing around the image after inserting from file gallery and before preview. Looking at the source inside the editor before a preview or save shows only this example:

"{img src=/tiki-download_file.php?fileId=1&display height=211 width=200 imalign=left}"

While the editor properly shows the spacing (inside the editor), the source code is not set to save the spacing.

It is not possible to manually enter the "Vspace" and "Hspace" into the source and save or preview successfully; the "Vspace" and "Hspace" are deleted.

It looks like the source code is simply using the original Tiki text approach. This would be a deal-breaker for my users.

I just recently installed TikiWiki on my Ubuntu server by copying all the files in the .ZIP package into /var/www/html/wiki/. This makes the site run at wiki.mysite.com. Now, when I go to edit a page and try to add an image, go to Browse Server, I get an error message saying: "Error creating folder "/var/www/html/wiki/wiki/img/wiki_up/image/" (Permission denied)"
The path seems to be wrong. There is /wiki/wiki/img when it should be just /wiki/img. There shouldn't be any permission problems if the path was correct like: /var/www/html/wiki/img/wiki_up/image/

This is hard to explain. To reproduce, create below a page like this:

Link1
Link2

Link3
Link4

Paragraph formatting is on, so each line is on it's own paragraph. Take care NOT to press enter at the end of Link4 for now. There is no blank space before Link1 which is on the first line

Note the blank line between Link2 and Link3.

Now do the following test:
1) Select Link1 taking care to select only the text and not the start of line or end of line around it, click on Insert Wiki Link. You get Link1, all good

2) Select Link1 aggressively, dragging the mouse cursor to the left of the Link1 before the start of line, or alternatively to the right of the end of line. You will get Link1Link2Link3 picked up.

3) Now add an enter at the end of Link4 (the end of the text)

4) Now repeat step 2 above, you will find that instead if Link1Link2Link3 you will now pick up Link1Link2Link3Link4

5) Now another problem: If you highlight Link3 "accidentally" capturing the br above it (the blank line), and then click Insert Wiki Link, you get nothing.

6) Now select from beyond the end of line of Link4 back but only "nk4". You will get a garbage.

The above tests were done in Firefox.

In Safari, 5) is reproducable, but the rest can't really be reproduced except note that if you select Link2 accidentally capturing the blank line below, you get Link2Link3 or Link2Link3Link4 depending on whether there is a blank line at the end of the text.

In IE (IE8 and in IE7 compatibility mode), you don't get any text whatever you do. IN IE8 compatibility mode you get a "scroll bars appearing in the popup" which is a separate problem I suppose.

When inserting an 'internal link' the objects offered are limited to Wiki objects only. (WYSIWYG editor). It would be good to have other objects included also.

Hello,

I just install the version 7.2, and here is the php info: http://grip.umich.edu/tikiwiki/tiki-phpinfo.php. When I switched to the WYSIWYG editor (I tested all WYSIWYG editors), I could create content and sometimes could save it, but when I edited it the editor could not load the existing content.

Installed new site using v7.1. WYSIWYG editor was working OK (not perfect, but could at lease copy and paste Word documents with 85% accuracy, switching between source and WYSIWYG worked, tables worked, inserted HTML tags worked).

After upgrade to 7.2 WYSIWYG has become unusable. The following problems have been seen (there may be others):
#Toggling between source and WYSIWYG (using the SOURCE button) gives mixed results. Wiki syntax in source is correct but in WYSIWYG it displays wrong (most notable is bold not parsed). WYSIWYG will display page semi correctly in the editor window with some of the formatting, e.g. auto numbering is correct, but when displayed in preview (or saved page) wiki syntax is ignored and is display as one long line (no cr or formating).
#Editing a table in Source will cause any other table to break by changing the wiki syntax by adding a carriage return after each cell and the cell delimiter.
#Can not post text copied from a Word document any more. Comes out as HTML code unparsed, then on save displays as one long string of HTML code.
#When inserting HTML code using {CODE()}{HTML()}...{HTML}{CODE} to change styles, save sometimes drops first two character, changes first > to HTML {CODE()}& gt;{CODE} and drops closing HTML tag, at other times will add {CODE()}< x >{CODE} at third character. Can not correct using any editing method in the WYSIWYG editor.

Standard editor works fine.

When trying to create a Wiki Link using the WYSIWYG, the auto page find doesn't work anymore making it almost impossible to link to another wiki page without knowing exaclty the page name

{img src="https://img.skitch.com/20111124-r2ai2a29x2xyriua1mu3a3996h.jpg"}

How to reproduce:

Using WYSIWYG, edit a page which has a link to a wiki page which has an accented character and the link will change from accentué to accentu�


Workaround:

* Avoid non-English characters (éàç) in page names

Android browser on Tiki8: It just says "Loading..." forever


[http://cksource.com/blog/CKEditor_3.6.2_released|Recent iPads and iPhones should be OK]

If browser is not supported, should Tiki revert to entering text (or manual HTML?)

We have links to external pages using file:// because the pages are internal to our system. This type of link worked in version 3.0 and now doesn't. The links work within a browser so we know it isn't an address error. This type of link uses the protocol (other) within the WYSIWIG editor.

This is a minor issue, and not sure if it something for tiki or google to fix. However I try to push Chrome as the default browser in my school because we use Google apps and it works better for that.
I don’t want to have to tell my users they need to switch browsers to insert an image. This will not get tiki accepted very fast.

I have tested this on a fresh install of 8.3, svn pre8.4, and svn pre9.0

I am on a windows 7 system with Chrome 18, Firefox 11 and IE9.
In wiki syntax mode the file galary image selector works fine.

In WYSIWYG mode the image slector works fine in Firefox and IE, in Chrome I have a new window that tries to open. The window is listed in the task bar but I cannot access it.

I have turned off pop up blockers and disabled all extensions while testing with the same result.

I have also tried from different computers.

When you insert a Code plugin {CODE(caption="such as this")}printf("i write everything in only one line");
{CODE}
the line breaks.

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.

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.

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]

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.

Features Classification

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.

Contributors

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

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.

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

In WYSIWYG, I introduce a table (4 rows, 2cols, 1st row is header). This is html. There is no Allow HTML checkbox in this editor, but the page is saved correctly with emphasis on the first row.
I edit the page with the normal editor. There is only one cell left in the first row (text of the two original cells concatenated). I cut the cell again in two with "|". Emphasis is lost. Now there is an Allow html checkbox, I check it and save.
Going back to the WYSIWYG editor, I restore the emphasis on the first row (again html seen in the source) and I save.
Back in normal editor, Allow HTML is lost again and the table gets the same defects.

For WiKi pages I use the WYSIWYG (FCKEditor) but this is not an option for Articles. There you can only use the simpel Text Area and Quicktags. It's must better if you can use the WYSIWYG (FCKEditor) for every text input.