Name | Type |
---|---|
"Advanced" tables altered when "Use Wiki syntax in WYSIWYG" (wysiwyg_htmltowiki) is enabled | tracker item |
"internal link" button doesn't work -- "local.php not found" | tracker item |
"internal link" button doesn't work -- "local.php not found"
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) |
tracker item |
[] Leads to an Ajax Error in Wysiwyg Mode | tracker item |
12.x html code embedded in a tracker item field text-area-with-wysiwyg lost after edition | tracker item |
12.x: accents not shown properly in forum posts when wysiwyg-html is on | tracker item |
12.x: page alias links lost if full wysiwyg and wiki syntax | tracker item |
12.x: wysiwyg editor in mobile never ends to load in article body | tracker item |
Caldrac
Contributors |
tracker item |
Using CTRL-Z while editing a page with wysiwyg will break all wiki links on the page
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. |
tracker item |
edit button does not work in latest 1.10
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, |
tracker item |
New blogpost using wysiwyg editor adds a lot of empty lines to the beginning.
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. |
tracker item |
Humphrey
Contributors |
tracker item |
jonnybradley
Contributors |
tracker item |
fckeditor bugs in style, images and wiki-li 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) |
tracker item |
Editing / Saving themes CSS causes "strange" code in some commands.
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 |
tracker item |
daniam
Contributors |
tracker item |
WYSIWYG doesn't create tables with Wiki syntax
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! |
tracker item |
Calendar doesn't display WYSIWYG. Displays w/html code
In displaying a calendar event it doesn't display as written in the edit window using WYSIWYG. Instead it displays with the HTML code. |
tracker item |
HTML comments in WYSIWYG editor
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. |
tracker item |
4.0: changing newsletter editor from wysiwyg to normal produces blank page
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. |
tracker item |
5 RC-1 Cannot Paste Text in WYSIWYG Editor
! 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. |
tracker item |
7x Dev : Wysiwig help error in sizes of shapes and window + [enh]
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. |
tracker item |
Admin templates uses WYSIWYG editor even if WYSIWYG was not enabled
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. |
tracker item |
Admin toolbars should be available from WYSIWYG, like it is from Wiki | tracker item |
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)