Extension talk:WYSIWYG/LQT Archive 1

Paste image from clipboard
The image displays fine inside the edit area. But after hitting save or preview, the image is gone. The page only shows


 * I've opened an Issue 15629 to track this --Ridmi 08:05, 12 September 2011 (UTC)

Paste from Word
Note: "Paste from Word" does not work. Copy/Paste from a website does not work. "Paste as plain text" does work. If you install this on your site, I recommend making your users aware they cant copy/paste from word. I am looking for a solution to this and will post if I find one.

Hi We have released bug fix release on Feb 4th 2011 which supports copy and paste from MS Word, MS Excel and web pages. See it by yourself in the sandbox Wiki here: SMW+ sandbox Wiki.

regards

--DanielHansch 09:33, 11 February 2011 (UTC)


 * Is this fix in version 1.5.6? I'm having problems pasting from Excel using WYSIWYG 1.5.6 and Mediawiki 1.16.1 with compatability mode turned off in Internet Explorer 8

Ready for production website?
Hi, sorry if this question might sound a bit impertinent (and sorry for my limited English)... but is this extension ready for a production website? Well, I mean: are there still important known bugs that need to be fixed? Is there a page where I could see these known bugs? I'm running a wiki that is being used by very young children. I have been using the FCKeditor extension for two years and I'm quite satisfied... but there are still a few bugs that need to be fixed and it looks like its devs are not very active anymore. Thank you very much for your honest answer! :-) Laurent

Hello Laurent,

the WYSIWYG extension is a mature software and definitely ready for production. There is an active team of software engineers developing new features and fixing bugs in a regular bug cycle. This means that all bugs possibly relevant for your application will be fixed with our next release in 4 weeks at the latest. Find the currently proceeding bug fixes here. You can also refer to the WYSIWYG documentation and our support forum to get help.

regards

--C niemann 14:13, 18 February 2011 (UTC)

A Related Question My site has the latest 1.17.0 MediaWiki release. The site is also internationalized. I would dearly love to add this extension, but need to find out if it works with the latest MediaWiki release as well as with other languages. And if it's not ready, does anyone know the timeframe when it may be ready? If someone could advise, it would be appreciated.

--LWells 18:27, 27 July 2011 (UTC)

Answer: Hi LWells. We are working right now on migrating WYSIWYG to MediaWiki 1.17. It is planned that the next version 1.5.7 will work with MediaWiki 1.17. As for internationalization - WYSIWYG officially supports only English and German languages. --Ridmi 08:17, 9 September 2011 (UTC)

Lack of functionalities
Hello, to my mind, CKEditor lacks too important functionalities to be at the level of the old FCKEditor. There is no button for including the page in a category, and for adding citations (which was possible with the Extension:Cite). I was eager to upgrade to so-called Extension:WYSIWYG, thinking it could only be an improvement, but I know realise I still have to use FCKeditor... Yet, I was ready to tweak and find a workaround, but I spend too much time searching the web. For those who could be interested, all I could find was this page. Domino


 * I'd like to echo Domino's comments, and request that buttons for adding Categories and References be integrated into this extension, if at all possible. --Dvd3141 15:16, 12 August 2011 (UTC)

No link on the pictures
Hi, in your sandbox there are no links on the pictures (they are not clickable). Does it have something to do with the editor? Thank your for your answer!

Answer:

No, this is not related to the editor. You can check this on several other pages, e.g. http://smwdemo.ontoprise.com/index.php?title=SMW%2B_1.5. Pictures on this page are clickable and lead for example to a full resolution view or a definable link. If you have the Rich Media extension installed you can also use appealing overlays to present pictures and any other type of media.

regards

--C niemann 14:21, 18 February 2011 (UTC)

WYSIWYG editor lost after preview
Hi, I tried your sandbox and after clicking the "preview" button I couldn't see the WYSIWYG editor anymore (Firefox 3.6.13). Thank you for feedback!

Answer:

Your description is somewhat unspecific. Can you please refer to the corresponging SMWforum page and report/formalize your problem there? Thank you!

regards

--C niemann 14:31, 18 February 2011 (UTC)

Image insert doens't work with IE 8
Hi.

Ich have Mediawiki 1.16.2 running on Ubuntu, using WYSIWYS extension 1.4.0_3. Runs fine with Firefox, but IE6 and IE8 both cannot open the image dialog. There are multiple javascript errors when loading ckeditor, all in ckeditor.js, line 52: 'type' is null or no object.

Is there a fix?

I also got antoher problem (sometimes also in firefox: when saving a page, sometimes ckeditor completly empties the page, all content is lost. Anyone an idea?

Regards --83.236.214.98 13:26, 3 March 2011 (UTC)

Answer: Hi there, you are right, we have an issue with IE8 (ref. ) which prevents using the image picker. While we are fixing this with the next release you can use this workaround: click on the "Show WikiTextEditor" switch and enter the link to the image manually, e.g.. Kind regards --DanielHansch 10:35, 4 March 2011 (UTC)

Links are broken after edition
Hello,

our mediawiki is 'ru' localized version. After edition the text by WYSIWYG editor links to special pages(as well as to User, Image, File and other namespaces) are broken. For example: UserName is transformed to something like this UserName This is also true for links to internal pages written by russian words: Методы is transformed to Методы How I can fix this?

Answer:

Hi there,

this is most likely an encoding issue that needs some more precise testing. Can you please report this to our tracking system? We will find a solution for you if you do so!

regards

--C niemann 16:39, 21 March 2011 (UTC)

Thanks for reply! the bug was submitted (14000) 95.84.190.156 16:53, 21 March 2011 (UTC)

Hide WYSIWYG Editor for special Namespaces
Hi there, First thanks for the extension and the progress in MW + Rich Text Editing! One question: Is it possible to hide the Editor in special Namespaces, for example in Widget, Property etc? I've seen, that it is working for the Template namespace by adding:

but it does not work for other namespaces - the same problem like in the FCKeditor extension.

Thanks for support --Filburt 11:47, 19 April 2011 (UTC)

Answer: You may use the global variable $wgFCKEditorExcludedNamespaces to disable namespaces being edited with the WYSIWYG extension. However this cannot be changed in the user preferences. To disable the Template and Property namespace use: I added a feature request in our bugzilla #14574 that checks for all custom namespaces in user preferences. At the moment this is not possible. --Stero 12:58, 6 May 2011 (UTC)

WYSIWYG Editor (1.4.1) not working on MediaWiki 1.16.4
After installation and configuration I do get a 'Show RichTextEditor' link but it leads nowhere. Following the link has no effect at all. Have not been able to find a solution. Suggestions would be most welcome!

--Ruud Schouwenaar 21:06, 4 May 2011 (UTC)

Answer:

Hi Ruud,

Unfortunately I can't reproduce this error on my installation, also running MW 1.16.4. Do you maybe have an URL where I can see this error?

--Stero 13:11, 6 May 2011 (UTC)


 * Hi Stero,
 * Thanks for your reply. I can't seem to reproduce it anymore, after installing and de-installing various extensions.
 * If the problem returns I'll get back to you :-)
 * --Ruud Schouwenaar 12:09, 11 May 2011 (UTC)

Additional:

Hey Stero, I can show you a URL of our staging site where I am receiving the same problem as Ruud. Could you please contact me at jon@twg.ca? Appreciate it.

--Jon Lim 15:48, 10 May 2011 (EST)

Answer: Hey Jon, can you please file in a bugreport in our Bugzilla? What we need is the setup of your wiki (e.g. the output of Special:Version) and the content of the page that causes the trouble. If the wiki is public for reading please send an URL. I can copy the wiki source to an installation of mine to reproduce the bug. --Stero 16:02, 16 May 2011 (UTC)

WYSIWYG Editor (1.4.1) Image Picker on MediaWiki 1.16.2 and IE 8
Hi.

On Internet Explorer 8, the Image Dialog now opens (wasn't the case on 1.4.0_3). You can select an image, it is inserted into the document - but it doesn't close afterwards. In fact, the dialog never closes until reloading the page, discarding all changes to the document.

And another issue: Only under IE 8, the "source code" button to switch to the original MW-syntax doesn't work either - you just got a blank page, the content is all erased.

Under Firefox, everthing works fine. Can you tell me when there could be a version running bugfree under IE8?

Thanks for support. --83.236.214.98 07:25, 5 May 2011 (UTC)

Answer:

Hi,

For your first bug I created a bug report in our bugzilla: #14575 We will have a look on this.

When the "source button" leaves an empty window then there is something in the content of the page that breaks the IE when transfering the html into wikitext. We try to fix these errors but need more details. Can you please reproduce the error and maybe open a bug report with the page content when this happens? --Stero 13:07, 6 May 2011 (UTC)

Update: I can't reproduce the IE8 error with the image dialogue. Can you make sure that you do not run the IE8 in compatibility mode? Also can you maybe add more details of your installation if the problem still persists? --Stero 13:34, 6 May 2011 (UTC)

Hm, I think I have to apologize. It seems to be the compatibility mode. It was an intranet site, per default the IE seems to use compat mode for all intranet sites. Disabling it makes it working. Thx for your help!

IE7 breaks as well
I have narrowed it down to bulleted and numbered lists. You can reproduce the error like this: * bullet * bullet and press 'Source' or switch back to original editor or and press 'Source' or switch back to original editor.
 * 1) one
 * 2) two

Tested with IE7 on:
 * MediaWiki 1.16.4, PHP 5.2.17 with WYSIWYG 1.4.1_0[B2] and
 * MediaWiki 1.16.5, PHP 5.3.5 with WYSIWYG 1.4.0_3[B268]

This is really a deal breaker for us as our organization will not switch to Firefox or Chrome anytime soon :-(

Hopefully this information helps you slaying this bug :-)

--Ruud Schouwenaar 08:24, 12 May 2011 (UTC)

Addition Tested with IE9, no problem. IE9 in compatability mode, no surprise, does break.

--Ruud Schouwenaar 22:01, 12 May 2011 (UTC)

Addition Unfortunately we will not support IE7, which (after IE9 was release) is also rather outdated. What mostly works in FF and Chrome sometimes causes trouble in IE. We take the effort to support IE8 and also IE9 but will not do it for any previous release of the IE. Sorry about that. --Stero 15:58, 16 May 2011 (UTC)

WYSIWYG Editor (1.4.1) not working on MediaWiki 1.16.5
I've followed the install directions, but I don't see the editor or a link for it, on the edit page in my wiki. Has it been tested with 1.16.5 yet?

Answer

I'm running 1.4.1 on 1.16.5, no problems except one, see

--Ruud Schouwenaar 20:44, 13 May 2011 (UTC)

Answer

We didn't test with MW 1.16.5 yet. I filed in a bug in our Bugzilla #14659 to test this configuration. --Stero 16:32, 16 May 2011 (UTC)

WYSIWYG 1.4.0_3 / CKEditor 3.4.2, Semantic Forms (Version 2.2-alpha), MediaWiki 1.16.5
We tested WYSIWYG and MediaWiki 1.16.5 in normal edit mode and found no problem but as soon as we tested Semantic Forms (Version 2.2-alpha) (r88513) and WYSIWYG (Version 1.4.0_3 [B268], CKEditor 3.4.2 (revision 6041)) together with settings (in LocalSettings.php) $wgDefaultUserOptions['riched_start_disabled'] = true; $wgDefaultUserOptions['riched_toggle_remember_state'] = true; an error Fatal error: Class 'FCKeditorParserOptions' not found in ...extensions\SemanticForms\includes\SF_FormUtils.php on line 399 occurs.

Testing environment: MediaWiki	1.16.5, PHP	5.2.13 (apache2handler), MySQL	5.1.44-community --MWJames 12:28, 21 May 2011 (UTC)

Answer: Can you please make a post on the smwuser list at: semediawiki-user@lists.sourceforge.net as you did for the other issues that you reported? This seems to be an error in the SemanticForms extension. Thank you. --Stero 12:47, 23 May 2011 (UTC)
 * Well, the error message is gone now but their is a notice from one of the SF developer. Well, this is half-fixed now - I believe the error messages are gone, although SF still doesn't support the WYSIWYG extension - for that, you'd have to talk to the authors of the extension. Yaron Koren 22:24, 24 May 2011 (UTC)REF 1

Question: Is there any readme on how to implement CKEditor 3.X in my MediaWiki? Can't find a tutorial on how to do it and FCK is not working very well...

Internal link to an image or a file of other types
Copying and Pasting from MS Word feature is great. Good work!. However there is a problem with Internal links. I used the link button and it was no possible to make internal links like
 * [[media:example.jpg]]
 * [[media:example.pdf]]

Enviroment
 * MediaWiki 	1.16.5
 * PHP 	5.3.2 (apache2handler)
 * MySQL 	5.1.52
 * Extension 1.4.0_3

--Miltongallegos 14:52, 20 May 2011 (UTC)

Answer: Please can you describe ore in detail what exactly you are trying to do. I can create links to internal files (using the link dialogue). There is a problem that for some user input there are no proposals even though there should be some in the Media namespace. I created a bug report for that (#14739). You can always type the complete page name e.g. Media:example.jpg into the inputfield and the link is created correctly. --Stero 13:09, 23 May 2011 (UTC)

Additional: These are the steps to redroduce the bug:
 * 1) Click in Edit
 * 2) Change any text in the article (no the internal links)
 * 3) Click in Show Preview or Save page

After that, the internal links don't work. I noticed the namespace "Media:" had dissapeared automatically

Error with imagemap extension
We have here MW 1.16.5 with WYSIWYG-Extension. Additionally Imagemap-Extension is installed.

If the wiki text contains &lt;imagemap&gt; tags an error is displayed: "Fehler: Bild ist ungültig oder nicht vorhanden" and the imagemap content replaced by the error message.

Answer: I filed a bug report on this issue so that we check this bug #15112. --Stero 17:06, 30 June 2011 (UTC)

Problem with IE8,IE9 table rendering
Hi all, I've noticed this issue with specific pages that include tables. What happens is that IE8,IE9 (With or without compatibility mode, with or without script debugging enabled from advanced options) blanks that problematic page wikitext when you do an edit, then hit save or when you just switch from editor view to wikitext view.

NOTES:
 * 1) Everything works perfectly OK from Mozilla as well as Chrome. Although I would appreciate to see what exactly happens behind the scenes with IE to cause that rendering (i assume) issue.
 * 2) Part of the table code is as follows: class="FCK__ShowTableBorders" style="border: 1px solid rgb(221, 221, 221);  margin: 1.2em 0px 6px;  width: 1163px;  background: none repeat scroll 0% 0% rgb(249, 249, 249)"
 * 3) I had  previously installed and created pages with a differenet editor before I re-install WYSIWYG.

Please let me know what you think about this.

Update: The problem is solved→ Auto - Compatibility view for IE8, IE9 was causing the problem (Need to disable from Advanced Internet Options→ Browsing section. Also, need to un-check from Compatibility view settings the following:
 * 1) "Display intranet sites in Compatibility View".
 * 2) "Display all websites in Compatibility View".


 * # I am using wysiwyg 1.5.6 and mediawiki 1.16.1 and in Internet Explorer 8 (with compatability view turned off) when I paste from excel into a page all the text in the page is deleted. I've turned off compatability view as described above but still have the same problem. Any ideas? - User:RichyL 12 September 2011

Answer: Hi RichyL. I can't reproduce this issue on my local installation. Can you post here the table you are trying to copy? It would be even better if I could access your wiki to see what's wrong and do some tests. --Ridmi 16:54, 12 September 2011 (UTC)

--Reply

Hi Ridmi,

my wiki is used internally where I work. I pasted in from Excel 2010. I made a table that just consisted of 1, 2,3 in the first column and a,b,c in the second. Nothing special as I just wanted to test it. All compatability view is turned off (also turned off 'Display Intranet Sites in Compatability View'). Any help you can offer is really appreciated. I can paste in as plain text. I also ran the patch and that did not seem to help either. --RichyL 10:56 13 September 2011

Signature
Hey there - just one question - I can't find a signature-button .... is there one? --Fxk2 18:26, 28 June 2011 (UTC)

Answer: There is a signature button since version 1.4.1. The button is in the upper line of the toolbar, the 7th buitton from the right. --Stero 17:00, 30 June 2011 (UTC)

Undefined index
Hi. I tried to install WYSIWYG following the installation manual on SMW+ site. But now when I go to my mediawiki and try to edit a page, it shows an error: Notice: Undefined index: riched_load_semantic_toolbar in E:\xampp\htdocs\wiki\extensions\WYSIWYG\CKeditor.body.php on line 422

I tried everything I could but still no sucess. On SMW it works fine. I have Windows 7 and the latest MediaWiki version. What am I doing wrong?

Answer: Please add "$wgDefaultUserOptions['riched_load_semantic_toolbar'] = 0;" in WYSIWYG.php for Defaults for new preferences options section

Strict Standards

 * --TDeeming 13:05, 17 July 2011 (UTC) I installed MW 1.17.1 and WYSIWYG and I get the same message mentioned above displayed at the top of the page when I open a page for editing.
 * In the initial mainpage, there is also a message displayed in the body Strict Standards: Declaration of CKeditorParserOptions::getSkin should be compatible with that of ParserOptions::getSkin in E:\xampp\htdocs\wiki\extensions\WYSIWYG\CKeditorParserOptions.body.php on line 3.
 * Please advise.
 * --TDeeming 12:35, 19 July 2011 (UTC) Additional information. I also tried with earlier versions of Mediawiki (1.65 and 1.61) with similar results. Please note that the WYSIWG works... there is just a lot of error messages being displayed.
 * Question: Is there some other extensions that need to be installed first?

Answer: Hi TDeeming. It looks like a php error reporting configuration issue. What version of php are you using and how your error reporting is configured? If everything works I would suggest to set error_reporting = E_ERROR in php.ini to just display critical errors and ignore everything else. --Ridmi 08:58, 9 September 2011 (UTC)

Interwiki problems
Hi, at first thanks for this nice extension. But I have a little problem. I am using interwikis in my wiki and after every edit which is done with the WYSIWYG editor it changes the interwiki. So, if the interwiki is Hauptseite, after saving the page it will be changed to de:Hauptseite. Does anyone have an idea how I could fix this? Kind regards, --Lukas9950 00:22, 3 August 2011 (UTC)

Answer: Hi Lukas9950. I can't reproduce this on my installation. Can you please file a bug in our Bugzilla and provide your setup details. Thanks. --Ridmi 09:09, 9 September 2011 (UTC)

Strict Standards
I'm getting a "Strict Standards: Declaration of Image::newFromTitle should be compatible with that of LocalFile::newFromTitle in C:\xampp\htdocs\wiki\includes\filerepo\Image.php on line 74" error as soon as an Image is in the wiki text.

Question: What's wrong here?

Answer: It's really hard to tell without knowing your setup details. If there are no functionality issues then it looks like php error reporting configuration issue (see this post). Hope that helps. --Ridmi 09:18, 9 September 2011 (UTC)

Add custom tags for the parser to ignore (Patch)
The WYSIWYG back-end CKeditor will parse custom tags as plain HTML and break your custom extension tags.

A workaround to this is to add a line to your LocalSettings.php like this:  before you require_once WYSIWYG

In the file CKeditorSajax.body.php, there is a function called Find the code which looks like (search for getTags if you cannot find it easily via. looking): and make it look like:

It makes these tags show up in the editor window as 'special' and it does not attempt to render them.