Extension talk:WYSIWYG/Archive

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 [[File:]]

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. [1]) 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. [[Image:Trafficlight.png|center|65px|Trafficlight.png]].
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:

[[User:UserName|UserName]]

is transformed to something like this

[[ㇰႽ躺UserName|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:

$wgDefaultUserOptions['riched_disable_ns_template'] = 1;

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:

$wgFCKEditorExcludedNamespaces = array(NS_TEMPLATE, NS_PROPERTY);

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)

Found a solution (tested with WYSIWYG 1.5.6_10): The namespaces are handled correctly but SMW has its own namespace-names, i.e. SMW_NS_PROPERTY, SF_NS_FORM instead of NS_PROPERTY etc. --Filburt 15:37, 14 October 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

# one
# two

and press 'Source' or switch back to original editor.

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 #IE7 breaks as well
--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 <imagemap> 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

Updated

Noticed that when pasting a table in from Excel into Firefox and selecting a cell then the bottom of the editor says "body table tbody tr td". When I paste the same table into internet explorer 8 it says "body p table tbody tr td". Selecting the p for paragraph selects all the cells in the table.

Answer:
I've opened issue 15655 in bugzilla to track this problem.
The fix will be on trunk in a few minutes.
Thank you, RichyL!
--Ridmi 13:22, 14 September 2011 (UTC)

Reply

Just donwloaded version 1.5.6_10 but I'm still getting the same issue. Any ideas? --RichyL 10:41 21 September 2011

Answer:

Hi RichyL. The first thing to do would be to clear your browser cache to make sure it doesn't use it's own copy of old scripts instead of new ones.
Then if you still have this problem - please verify it on our test installation and reopen the issue 15655.
Thanks,
--Ridmi 11:56, 21 September 2011 (UTC)

Reply

Thanks for the reply. I checked I'd installed the correct version of the extension and then restarted apache. On IE 8 I cleared out all Temporary Internet Files and then tried it again. Same issue. I can't seem to create pages on the test wiki you sent me a link to so that I could try and recreate the problem. I made a user account called RichyL and tried to create a page for my userid but when I try and create a page I get an error message saying

You do not have permission to edit this page, for the following reasons: 
*You are not allowed to execute the action you have requested.
*You do not have permission to create new pages.

It does the same if I try to create a page from scratch or edit an existing page. --RichyL 18:00, 25 September 2011 (UTC)

Answer:
Yep, on this test installation we had a wrong default settings for user access control list.
I've just changed that and I hope it will stay this way tomorrow morning after the rebuild.
Please login again and create a page where I could verify this issue.
Thank you!
--Ridmi 08:16, 26 September 2011 (UTC)

Reply

Thanks for that. I've created the page http://halo-smw.ontoprise.com/smw156/index.php/Issue_15655 and on your installation it works OK. I've looked again on my install and I still get "body p table tbody tr td" when clicking in a cell. When i went to help in the editor I was using CK Editor 3.6 (revision 6902). I donwnloaded the file wysiwyg-1.5.6_10.zip and I'm using mediawiki 1.16.1. Any ideas of things I can check my end at all? RichyL

Answer:
Hi there.

"body p table tbody tr td" looks absolutely fine to me. A

tags surrounding a table shouldn't cause a problem.
I would suggest to update the WYSIWYG extension to the latest one (1.5.6_15).
If that wouldn't solve this problem, then at least you would be in sync with our test installation and we could reproduce this more easily.

--Ridmi 07:51, 27 September 2011 (UTC)

Reply

Thanks very much for all your help with this issue. One last question. Where can I get version 1.5.6_15? On the extension page the download link is to 1.5.6_10.

Regards, Rich --RichyL 21:49, 3 October 2011 (UTC)

Answer:
Please use DeploymentFramework extension for upgrading WYSIWYG to the latest version
--Ridmi 08:46, 4 October 2011 (UTC)

Reply:

I used the deployment framework - updated it and this issue was fixed. Thanks for all your help. --RichyL 11:30, 10 November 2011 (UTC)

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

Reply:
I am experiencing the same problem, and "$wgDefaultUserOptions['riched_load_semantic_toolbar'] = 0;" in WYSIWYG.php doesn't work. Any Idea?

Answer:
Hi.
Wich versions of WYSIWYG and MediaWiki are you using?
Please note that the latest stable release of WYSIWYG 1.5.6_12 supports MediaWiki up to version 1.16.4.
WYSIWYG 1.6 which supports MediaWiki 1.17.0 will be released in couple of month.
--Ridmi 08:05, 22 September 2011 (UTC)

Update
This notice doesn't suppose to stop WYSIWYG from working.
If WYSIWYG works you might also consider to configure your php error reporting to show only fatal errors and ignore the rest.
--Ridmi 08:42, 22 September 2011 (UTC)

Reply:
I am administrating 2 mediawikis. The one is v1.17 (i'll wait for the new version), but the other one is 1.16.0 and it does the same as 1.17 - If you click to open WYSIWYG instead of the normal wiki-editor, the editor disappears but no other editor is shown. You cannot get back to the normal editor too.

Answer:
Can I access this wiki to verify this issue?
I still don't have all the details needed to identify the problem.
--Ridmi 07:26, 23 September 2011 (UTC)

Reply:
No sorry, because it is an internal company-wiki. Which Details would you need? The WYSIWYG Version is (Version 1.5.6_10 [B639], CKEditor 3.6 (revision 6902)) Edit:
Now it is also working in 1.17 -> Compatibility Mode for Intranet-Pages :-) But now i've a new issue. When switching from Wysiwig to Wikitext and back to Wysiwyg the formatting is gone

Answer:
Hi there.
Are we talking about table formatting or all the formatting vanishes leaving just a plain text?
--Ridmi 07:40, 27 September 2011 (UTC)

Reply:
Hi! All the formatting disappears. For Example, the headings appear correct at the first switch, but after the second switch you have the wikitext in the wysiwyg-editor. it seems that wysiwyg renders the wikitext only at first switch. i cannot upload pictures here so i can't show you exactly what i mean.

Answer:
Please file a bug in our bugzilla and just copy and paste the wikitext which is not rendered into the bug description so I could try to reproduce this.
--Ridmi 09:43, 27 September 2011 (UTC)

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 [[de:Hauptseite]], after saving the page it will be changed to [[De:de:Hauptseite|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:

$wgWYSIWYGExtensionSpecialTags = array ( 'list', 'of', 'custom', 'tags' );

before you require_once WYSIWYG In the file CKeditorSajax.body.php, there is a function called

wfSajaxSearchSpecialTagCKeditor( $empty )

Find the code which looks like (search for getTags() if you cannot find it easily via. looking):

$wgParser->firstCallInit();
  foreach( $wgParser->getTags() as $h ) {
    if( !in_array( $h, array( 'pre', 'math', 'ref', 'references' )) ) {
      $ret .= $h . "\n";
    }
  }

and make it look like:

$wgParser->firstCallInit();
  foreach( $wgParser->getTags() as $h ) {
    if( !in_array( $h, array( 'pre', 'math', 'ref', 'references' ), $wgWYSIWYGExtensionSpecialTags) ) {
      $ret .= $h . "\n";
    }
  }

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

Underscores in Links

Is it possible to change any setting to remove the underscore that automatically appears in the display link? For example, when I go to the link dialogue I can find the page "My Page" but the wikitext it displays is

[[My_Page|My_Page]]

and not

[[My_Page|My Page]]

It is possible to go back into the page and remove the underscore in the display link to leave a link of

[[My_Page|My Page]]

I was wondering if it is possible to get this behaviour by default as, to me, it looks more intuitive.

Answer:
Hi.
This one I was able to verify by myself.
I've created an issue 15689 to track this.
Thank you,
--Ridmi 12:36, 21 September 2011 (UTC)

line spacing lost in existing pages after installing WYSIWYG

After installing WYSIWYG to an existing wiki and enabling the rich-text editor, I have noticed that all my previous line spacing is no longer preserved. Instead, all the text is contiguous. Is this expected behavior or a bug? If expected, it is proving to be a bit unusable for existing wikis.

[MW 1.17, PHP 5.2.17, MySQL 5.0.92, SMW 1.6.1, SF 2.2.1]

Answer: Hi.
Are we talking about line breaks or spaces between lines?
The WYSIWYG is supposed to convert wiki markup to html and vice versa without any loss of formatting (unless it's not supported by wiki markup).
So it would rather be a bug than an expected behavior.
Please file a bug in our Bugzilla with screenshots or, even better, link to a page when this issue can be verified.
Thanks,
--Ridmi 12:17, 21 September 2011 (UTC)

It seems as though it happens for text that are within <noinclude> and <includeonly> tags. I will submit a bug report. Thanks for your response!

Category button for wiki without Semantic MediaWiki

Hello, I would like to request the addition of a Category add/edit button for MediaWiki sites that don't use the Semantic MediaWiki extension. Fiddling through the code I noticed that extended Semantic-only functionality can be activated upon detection of the extension, so it stands to reason that a Category button could be made to appear when it is absent.

This is one blocker feature that is keeping me away from WYSIWYG and sticking to the now-defunct FCKEditor.

142.137.217.164 16:48, 30 September 2011 (UTC)

Answer:
Hi.
Are you talking about Semantic Toolbar? (this is the only place I can think of that has a Categoty add/edit buttons)
Then this is part of SMWHalo extension which heavily depends on Sematic MediaWiki extension and at this moment would not work without it.
I'm probably missing something here but could you explain why would you want to add Categories to your wiki if you don't have the semantic features enabled?
--Ridmi 17:38, 30 September 2011 (UTC)

Reply:
Hi there, many of my sites that currently have FCKeditor set up are fairly small and don't benefit from semantic analysis/lookup. Most of the categories are used for CategoryTree displays on certain key pages. I'm not sure some of those sites would survive a semantic MediaWiki setup, which is why I limited category use to very few categories.

The category button on FCKeditor is mostly used to automatically generate Category wiki code. That's pretty much my only request: Having a dedicated button that avoids the need to enter the article's source when a category is needed, whether Semantic MediaWiki is present or not.

Thanks again,

142.137.223.175 22:46, 3 October 2011 (UTC)

Answer:
Hi.
I knew I was missing something. Thank you for filling my blanks about CategoryTree extension.
Unfortunately SMWHalo is our main business, so adding a feature which will prevent potential customers from using SMWHalo extension can not be considered.
--Ridmi 08:39, 4 October 2011 (UTC)

I don't think that including a simple "Add Category" button to this extension would prevent potential customers from upgrading to SMWHalo. (Surely the advantages of SMWHalo are bigger than that!) I would say that the "Upload media" button is a much more powerful tool, and that is included in this free extension. When I enter a category manually in the wiki source then switch back to Rich Editor mode, the Rich Editor automatically detects the category code and formats it with a nice 'C' image, so we know the Rich Editor can detect categories. It would be useful to be able to add them with the Rich Editor too, so I support the above request to include a simple "Add category" pop-up box in this extension. Would you reconsider your position? :)

--Dvd3141 03:25, 28 October 2011 (UTC)

Problem when resizing a picture

Hello,
I inserted a picture in WYSIWYG editor, resize it and save the page. When I look the page, all is fine and the picture have the good size. If I try to modify the page, the picture back to the normal picture size (not resized) in the WYSIWYG editor. If I look the Wikitext, I see that there is a parameter for the size, so should be fine. If I save the page with the picture not resized, the page looks good. So, the only problem I have is to show the picture with resized size on edition with WYSIWYG editor.
Do you have any ideas to solve this problem ?
Thanks
Mediawiki : 1.16.5

Answer:
I've opened a bug 15765 to track this issue.
Thank you for reporting this.
--Ridmi 06:53, 5 October 2011 (UTC)

Additional:
The problem only happens if we resized the picture to bigger one. If we resize the picture for a smaller one, there is no problem.
Thanks --Ebernier 17:30, 5 October 2011 (UTC)

Problem when resizing a picture with mouse in IE8

Hello,
I have the problem in IE8, but not in Firefox. If I insert a picture in WYSIWYG editor and try to resize it with the mouse, instead of changing size in image properties, the dimensions are not saved correctly. The original size is used. If I do the same thing in Firefox, all works fine. The only way the change the size in IE8 is the enter it manually in image properties.
Other point : When I insert a picture in IE8, it is automatically aligned to the right. I have to change it in image properties too.
Do you have any ideas to solve these problems ?
Thanks

Mediawiki : 1.16.5
IE8: I didn't tried with other version.
--Ebernier 17:43, 5 October 2011 (UTC)

Answer:
Hi,
thank you for reporting this.
I've added your observations to the issue description in bugzilla.
I'll get it fixed as soon as I can. --Ridmi 15:17, 6 October 2011 (UTC)

Rendering Problem when using the toggle

Hi,

First thanks for the latest update (1.5.6_10), it improves the copy and paste of HTML code. I have another issue: When I use the toggle or the source button and switch from the rich edit mode in the wikitext edit mode everything works fine. But when I switch back I see the wikitext in the rich editor. I can save it and the page is rendered correctly. But if I edit the page again I have the wikitext in the rich editor from the beginning.

Tested in FF, Chrome and Opera.

Any idea? Thanks for support. --Filburt 15:54, 6 October 2011 (UTC)

Answer:
Hi there.
Please post here (in nowiki tags) the wikitext which causes the problem so I'll be able to reproduce this behavior.
Thanks.
--Ridmi 16:42, 6 October 2011 (UTC)

Hi, thanks for the fast answer. It was my mistake. I created a custom tag and forgot to insert some changes in the plugin.js, i.e. to add the tag in

   var dataWithTags=...

Thanks a lot for the great extension.

--Filburt 18:15, 6 October 2011 (UTC)

Problem when creating a link to a file

Hi,
I uploaded an PDF file using Upload media button. The file was uploaded succesfully. Now, I would like to create a link in the page to let user download it or take a look to this PDF. I used button Link to put a link to my PDF file. When I save the page, my link is changed for Pdf:test pdf file.pdf. When I come back editing the page and take a look to source (wikitext source), I see : [ [File:Test pdf file.pdf|PDF file example] ] (I put space between [ [ and ] ] to let you see my case). Normally, this syntax work in wikitext... Why my link doesn't work ?

Thanks
--Ebernier 14:11, 14 October 2011 (UTC)

Additional:
I have the same problem with other extension files like mp3. To make it works, I have to change view to see Source (wikitext source) and replace File: or Audio: for media:. Why I have to change it manually ?

Thanks
--Ebernier 14:22, 14 October 2011 (UTC)

Answer:
Hi Ebernier.
Please file a bug in our Bugzilla.
We will look at it as soon as we can.
--Ridmi 08:40, 18 November 2011 (UTC)

Missing table captions

If I insert a table with a caption usung the WYSIWYG extension, the caption is omitted from the wikitext. The extension also removes any existing table captions. Tested with version 1.5.6.0 & 1.5.6.10.
--Njknh 11:38, 30 October 2011 (UTC)

Answer:
Hi Njknh.
Please file a bug in our Bugzilla.
We will look at it as soon as we can.
--Ridmi 08:40, 18 November 2011 (UTC)

Corrupted citations

If I try and edit a page that has Extensions:Cite citations using the WYSIWYG extension version 1.5.6.10, the wikitext gets seriously corrupted. The same problem doesnt seem to occur with version 1.5.6.0 that I was using previously.
--Njknh 11:50, 30 October 2011 (UTC)

Answer:
Thank for reporting this, Njknh. Please file a bug in Bugzilla so it would be easier for everybody to track and discuss
--Ridmi 08:47, 18 November 2011 (UTC)

Internal link search capability lost in newer versions of extension

In version 1.5.6.0 you could, when entering an internal link, search for the page or upload name by typing in the first few characters of the name and then selecting the relevant entry from the list of matches. This functionality seems to have disapperared in version 1.5.6.10 which is inconvenient when adding internal links. Not tested the intervening versions as I dont have access to those.
--Njknh 12:18, 30 October 2011 (UTC)

A similar problem occurs when inserting images with 1.5.6.10 - again no facility for search images uploaded to the wiki. I also seem to get an image preview box that contains latin text.
--Njknh 17:46, 30 October 2011 (UTC)

Answer:
Hi.
It seems that the link and image dialogs you are describing are ckeditor original dialogs.
The dialogs with autocomplete function are available in WYSIWYG after you install SMWHalo extension.
--Ridmi 08:37, 18 November 2011 (UTC)

Quotation mark breaks wiki links

Hi.

I have the latest version installed (.10) on top of MediaWiki 1.16.0 (with SMWHalo) and I encountered this bug:

Wiki links with " (a quotation mark) disappear and the rest of the text is shown as a link. The value breaks upon saving, of course.

This is really problematic - my Wiki is in Hebrew, and we have a lot of usage for quotation marks.

Please help.

Thanks. --79.179.185.162 19:01, 10 November 2011 (UTC)

Answer:
Hi.
I filed a bug Issue 16141 - Quotation mark breaks wiki links.
We will have a look at this.
Thanks for reporting.
--Ridmi 08:29, 18 November 2011 (UTC)

Update:
This was an issue of CKEditor. The fix is already in svn. --Ridmi 09:56, 18 November 2011 (UTC)

Unable to browse local file

Hi,
I having problem during attach the uploaded image with the WYSIWYG - image feature.
When I click the Image icon of the rich text editor, there are no browse function for me to choose the file which already uploaded to my wiki.
Version installed:
WYSIWYG : 1.5.6-1 | Mediawiki : 1.17.0 | PHP : 5.3.8 | Apache : 2.2.21 | MySQL : 5.5.16
Anyone know how to fix it?
Please help.
Thank you.
--Lala.luv 06:29, 17 November 2011 (UTC)

Answer:
Hi.
The is no need for browse button.
Just start typing the name of the image you have uploaded in the "Image file name or URL" box.
This will trigger autocompletion mechanism which will list all available options in the listbox below.
--Ridmi 08:16, 18 November 2011 (UTC)

Reply:
Hi, Ridmi.
Thank you for your answer.
I have tried to type the name of the uploaded image in the "URL" box, but no listbox to list down all available options.
Any setting required to enable the trigger autocompletion mechanism? Please help.
Thank you.
--Lala.luv 02:57, 25 November 2011 (UTC)

Answer:
Hi Lala.luv.
Those are the 2 different kinds of image dialogs in WYSIWYG. The first one uses autocompletion mechanism and the second one has a Browse button:

WYSIWYG image dialog. This is how it looks like when you have SMWHalo extension installed

CKEditor original image dialog. This is how it looks like when you DON'T have SMWHalo extension installed

If you have some third option then this is probably an unexpected behavior caused by the fact that WYSIWYG 1.5.6-1 doesn't yet support Mediawiki 1.17.0.
Hope that helps.
--Ridmi 07:44, 26 November 2011 (UTC)

Customize the Link popup

Hi, I' moved from the old fckeditor extension to WYSIWYG, and I have a question on the link button. I have a link popup similar to this image. How can I customize it ? I would like the popup showed on your demo page Using MW 1.17 CKEditor 3.6 (revision 6902)

Answer:
Hi there.
WYSIWYG uses different dialogs depending on whether you have SMWHalo extension installed or not. When you install SMW+ package you get WYSIWYG and SMWHalo extension both.
So the first dialog you're describing is ckeditor original dialog and the second one is customized by us and AFAIK none of them is customizable by the end user.
So there are 2 ways of getting the reduced link dialog:

1. Install MW 1.6.4 and SMW+ 1.5.6
2. Wait for SMW+ 1.6 which supports MW 1.17

--Ridmi 08:07, 18 November 2011 (UTC)

External image insertion bug

When I insert an external image it shows up in the editor but after I save/preview, it shows up as a link in this form: "http://URL &nbsp"
The wiki syntax shows: [http://URL &nbsp http://URL &nbsp];
I am using the extension's latest vsersion (1.5.6-1) with Mediawiki 1.17. Any idea what's wrong? -- Mak 19:26, 23 November 2011 (UTC)

Answer:
Hi Mak. It looks like you don't have $wgAllowExternalImages set to true in your LocalSettings.php.
Besides that FYI version 1.5.6-1 of WYSIWYG supports Mediawiki up to 1.16.4 so with 1.17 it might behave in unexpected way from time to time.
Hope that helps.
--Ridmi 15:21, 25 November 2011 (UTC)

• thanks! that was very helpful. It fixed most of the images but some indented images or horizontally adjacent images still didn't showed up right (They appear as "http://URL &nbsp"), which could be, as you mentioned, a problem with the version of mediawiki that I have. Thanks again -- Mak 00:09, 26 November 2011 (UTC)

Cool and fruity!

Thanks to Ontoprise developer team: I have installed the extension on MediaWiki 1.17 and everything just works. I'm so glad, the editor looks just awesome! Incredibly done, many-many thanks to you!--Katkov Yury 07:02, 26 November 2011 (UTC)

Answer:
That's great!
Thanks for good words Yury.
--Ridmi 07:50, 26 November 2011 (UTC)

Subscribe! Thanks a lot for this extension! Maybe I can contribute some features to this extension in the near future. --Filburt 11:26, 1 December 2011 (UTC)

Trouble with indents in version 1.7.0_1

Dear supp, Our environment :MediaWiki version:1.19.2,WYSIWYG extension (Version 1.7.0_1 [B5]) When we input the below data in WIKITEXT:

:My thoughts are:
:*Thought number one
:*Thought number two

After switching to the rich editor it displays fine as

My thoughts are:

• Thought number one
• Thought number two

but switching back to WIKITEXT changes the above to:

undefined:My thoughts are:
undefined*Thought number one
undefined*Thought number two

Seems the indent is not supported properly. Can you help to advise is this fixed in a later version and if so which would be the best version to use which is compatible with our MediaWiki version? thanks very much.