Extension talk:WYSIWYG/2016

• archive of pre lqt talk

Show RichTextEditor doesn't do anything

Hi there!

I just installed WYSIWYG but when I click on the "Show RichTextEditor" string nothing happens. I have comment out from LocalSetting.php the whole section about SemanticForms as I get a Server Error 500 if it is enabled. This is due to the fact that SemanticMediaWiki is not installed. Is this the problem?

Also, can I use directly the SemanticForms and WikiEditor extensions bundled with WYSIWYG or should I install these extensions separately and then overwrite some of their files as suggested in the git documentation?

Thank you! manu3d (talk) 23:58, 28 January 2016 (UTC)

Further on this: I have now installed SemanticMediaWiki and according to the tests recommended on its website it is fully functional. The page Special:Version also seems to confirm SemanticForms is up and running.

I still do not get the WYSIWYG editor, only the WikiEditor. Depending on preferences/configuration sometimes I am able to get a clickable "Show RichTextEditor" string showing over the TextInput field, but when I click on it nothing happens and hovering on it displays "javascript:void(0)".

Any sugestions? manu3d (talk) 14:53, 29 January 2016 (UTC)

You do not have to install extensions SemanticForms or SemanticMediaWiki if you just want to use wysiwyg to edit MW pages. WYSIWYG is anyway not fully compatible with these extensions. Just leave related sample lines of LocalSettings.php commented out or remove them completely. You can use WYSIWYG and WikiEditor extensions directly from github download. If you use WikiEditor from some other source, it is not compatible with WYSIWYG. Riparap (talk) 19:00, 6 February 2016 (UTC)

Pre-fetching of images and categories does not work anymore

Hello all.

After upgrading to MW1.26.2 the WYSIWYG Editor still works. VisualEditor is not really an option if you use wiki inside a company. The FCKEditor implementation is still the best to handle a mediawiki which is not full of special coding extensions and has the scope of being as user-friendly as possible towards non-it employees.

In the past if you click on the image icon or the category icon there was a popup which displays all images/categories you currently have. When you start searching the results get continiously adjusted. In MW1.26.2 this does not work anymore (for me). It remains "searching..." ... I have no idea how this pre-fetching works, but maybe a simple URL rewrite rule, or a change to path could fix it. If someone could point me into the right direction? Would be great!

Thanks, Oliver 85.233.12.166 (talk) 12:15, 3 February 2016 (UTC)

What is your environment (php, mysql, wysiwyg) and what browser and version are you using?

Are you sure WYSIWYG works with MW1.26.2, because when I try it, I can only open wikipage one time in WYSIWYG with Chrome and FireFox. Second time will not open the page in WYSIWYG anymore, html code is opened in wikieditor. IE11 seems to work little better.

Source button and toggle link works one time in direction wysiwyg => wikieditor. When mode is tried to change back from source view to wysiwyg mode, editor will not open anymore and it is showing text "page is loading..." but it will never finish.

Problems are mainy caused by the fact that in MW1.26 all javascripts are now loaded asynchronically. It may happen that js module is not loaded when some function related to it is already called causing loading of page fail. Riparap (talk) 18:38, 6 February 2016 (UTC)

You should try latest version of WYSIWYG with 1.26.x f.ex Version 1.5.6_0 [B551+30.04.2016] (version should be at least >= "Version 1.5.6_0 [B551++27.03.2016]"). Riparap (talk) 12:54, 28 March 2016 (UTC)

Help with WYSIWYG editor for MW 1.26

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hi Can someone please assist me. I am having a hard time figuring out which WYSIWYG editor to use with my new mw install. I am running the latest version (as per last week) on a Windows environment. MW is working fine, but i dont know how to get the editor working.

I tried to install visual editor, but it needs parsoid etc. So followed this Parsoid/Developer Setup#Windows setup

But no matter what i try the command npm install contextify always bombs out. So i can never get further.

Any tips? 82.71.195.60 (talk) 11:57, 15 February 2016 (UTC)

Problem may be that at this moment wysiwyg does not seem to work with MW1.26.x. Just out of curiosity, could you try some earlier version of MW (f.ex. 1.25.x)? Riparap (talk) 16:49, 19 February 2016 (UTC)

This has been fixed, see topic WYSIWYG 1.5.6_0 [B551+29.11.2015] is having problems on mediawiki 1.26.x (fixed in 1.5.6_0 [B551+26.03.2016]). Riparap (talk) 10:33, 26 March 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

WYSIWYG is turning relative links into text, when subpage feature of MediaWiki is used

Just installed the extension to try it out on an existing wiki.

My wiki has many links like this:

LinkText

When I click edit on a page with such a link it does not render them as links, it renders them as a textual representation, which in source looks like this:

[[../SomePage|LinkText]]

Even worse, when saving the page I find that it did in fact replace all the links with this text version.

WYSIWYG_EDITOR_VERSION: 1.5.6_0 [B551+18.04.2016]

CKEDITOR_VERSION: CKEditor 4.5.4 (revision d4677a3)

MediaWiki 1.25.2

Not using WikiEditor

Not using SemanticMediaWiki

Not using SemanticForms Real struggle (talk) 18:33, 21 April 2016 (UTC)

was able to post today! yay Real struggle (talk) 18:33, 21 April 2016 (UTC)

In case it wasn't obvious, non-relative links work fine.

[[BaseDir/SomePage|LinkText]]

will render as a link to the right page with the right link text. Real struggle (talk) 22:41, 21 April 2016 (UTC)

Seems that wysiwyg does not understand that.

This may be stupid question, but this kind of link is new to me :).. and it is not listed here Help:Links . Is your link pointing to wiki page or external file which is stored somewhere? Riparap (talk) 14:20, 23 April 2016 (UTC)

MW1.26 shows LinkText as text and does not convert it to link (if edited with wikieditor)....so is this how it works in your wiki too?

I did modification which is available in branch wysiwyg_mw126_rsl458, where I removed conversion of characters [ and ] (in direction wysiwyg=>wikitext). I am not sure if it will help you because your example does not work in same way with my wiki (MW1.26) and it sounds like you had problem in other direction (when opening page and doing wikitext=>wysiwyg conversion).

If you want to test this, you have to select branch wysiwyg_mw126_rsl458 manually, because it is not default branch in github. Branch also contains updated CKeditor (vers. 4.5.8). Riparap (talk) 14:35, 23 April 2016 (UTC)

Are you sure they don't work on MW? I just played around in the MW sandbox and they seem to be supported fine - seems like the same full relative link support as is documented on the wikipedia relative link page, not sure why it's not documented on the mediawiki page, but it works fine on the sandbox (which is probably getting wiped very very quickly)

https://www.mediawiki.org/wiki/Project:Sandbox/sub01

[[Project:Sandbox/sub01]] [[../sub01|sub01]]</code> [[Project:Sandbox/sub02]] [[../sub02|sub02]] [[Project:Sandbox/sub01/sub11]] [[/sub11|sub11]] [[Project:Sandbox/sub01/sub12]] [[/sub12|sub12]] [[Project:Sandbox/sub02/sub21]] [[../sub02/sub21|sub21]] [[Project:Sandbox/sub02/sub22]] [[../sub02/sub22|sub22]] Real struggle (talk) 14:33, 25 April 2016 (UTC)

Update: I've been able to make it work with some minor changes to the WM files that the visual editor is using to get HTML versions of the page.

Title::secureAndSplit()

Title::newFromText

and

CKeditorParser::replaceInternalLinks( $text ) # purely to handle case with no piped text Real struggle (talk) 23:32, 25 April 2016 (UTC)

So... there are two possible different problems: first one was that wysiwyg converted character strings [[ and ]] in wrong way. I am not sure anymore if my modification with these characters were right. Second problem is your relative links.

On my installation of MW1.26.2 (no extra plugins than wysiwyg) result of relative link is like in picture Relative_link.png (page has been edited with wikieditor). As soon as link text begins with two dots, my installation of mediawiki does not display it as link, it is displayed as text. After my latest modification with wysiwyg I can also edit page using wysiwyg and that line of text containing two dots can be saved without problems.

Is it so that you have enabled subpage feature in your wiki in case relative links work in your system? ... this is enabled only with some namespaces by default, see Subpage feature and Relative links. It seems like subpages are somehow stored in different way than "normal" pages in MW. If I create pages startting with "/", then I can get relative links to these pages work with MW. It looks like wysiwyg can not handle this kind of links properly and treats it as text.

I do not quite understand what you mean... are you saying that you have modified some files of mediawiki in order to make relative link work in your system or have you made some changes with files of extension wysiwyg? If you have made changes with files of wysiwyg, could you please post your changes so that I can try to learn from them and merge possible valid fix into wysiwyg extension.

To understand you better, please use shorthands "MW" if you are referring to mediawiki, "wysiwyg" if you are referring to extension wysiwyg, "wikieditor" if you referring to extension wikieditor (text based editor of mediawiki), visual editor if you are referring to mediawiki extension visual editor, which is completely different way to edit wiki pages and has nothing to do with extension "wysiwyg". Riparap (talk) 19:30, 26 April 2016 (UTC)

subpages enabled via:

LocalSettings.php

$wgNamespacesWithSubpages[NS_MAIN] = true;

As for changes, yes, I 'made it work' via changes to the MW code and a change to the WYSIWYG code. Perhaps not the best way to fix it, but a start.

change to MW Title.php

- super hacky : in secureAndSplit() these relative links throw MalformedTitleException and are caught and return false. I just edited the catch to test if the $dbkey starts with ../

if It does, then I set the mTextform to $dbkey and return true.

This is a really poor fix, but a start.

Change to WYSIWYG CKeditorParser.body.php

replaceInternalLinks( $text )

- I commented out the first $text.replace because it was changing [[../link]] to [[../link|../link]] Real struggle (talk) 16:32, 27 April 2016 (UTC)

Thank you...

I will not modify files of MW because of this. This should be fixed with wysiwyg files only. I located the place were links are handled but I could not yet make it work properly. I will try to test this more when I have time... Riparap (talk) 17:52, 27 April 2016 (UTC)

I have made modification with this in branch "wysiwyg_mw126_rsl548". Version 1.5.6_0 [B551+03.05.2016]. Riparap (talk) 14:30, 30 April 2016 (UTC)

I have a similar problem. I am new to mediawiki, just installed a clean version 1.29 and installed the latest wysiwyg version.

When I save a page with a link, then the html code for the link is shown as text in the page

Aslo the preview tabs keeps loading (and displays nothing) Robwikinow (talk) 18:04, 19 July 2017 (UTC)

Apparently there is a differentce between the PUBLISH button on the top and and SAVE CHANGES on the bottom

The PUBLISH converts the links to plain text Robwikinow (talk) 18:07, 19 July 2017 (UTC)

How to add CodeSnippet plugin

I would like to add the CodeSnippet Plugin to the toolbar and cannot figure out how to enable this.

Is there any documentation on how to add a plugin in to the WYSIWYG extension?

Thanks,

Mike Mikelagase (talk) 21:05, 22 April 2016 (UTC)

I updated the following to include codesnippet

var extraPlugins = "mediawiki,mwtemplate,tableresize,textselection,texttransform,codesnippet";   //08.09.14 RL

Under the config.toolbar_Wiki I added this

['MWTextTags', 'MWSpecialTags', 'MWTemplate', 'MWSignature', 'CodeSnippet', 'qiButton', 'wsButton', 'rmButton' ],

Is this the correct way to add this as it doesn't show on the toolbar. Mikelagase (talk) 21:55, 22 April 2016 (UTC)

In order to activate plugin you must download it from ckeditor, install it under ckeditor plugins directory, check that file permissions are properly set (in case with Linux) and edit config.js to include name of new plugin. Your edits seem to be right with that file.

What version of MW and Wysiwyg you use?...If you use MW1.26 and/or the latest version of wysiwyg I would quess that problem may be async loading of javascripts which prevents new plugin to load because new plugin is not included in minified version of ckeditor and MW does not know that it should be loaded separatedly. In order to test plugin you could perhaps try source setup of wysiwyg, which bypasses resourceloader. However, this setup is intended to be used only for test and debug purposes, it is not ment to be used in normal use of wiki.

I created new minified ckeditor bundle where codesnippet plugin was included. Using this bundle of CKeditor I was able to make codesnippet active when wikipage was opened in wysiwyg. But it seems that wysiwyg is not compatible with this plugin and page will be corrupted with parser error texts in case page is saved. To fix this is not so easy and it would anyway mean that extra html code would be saved with wikipage when this plugin is used.

Did you notice that wysiwyg already supports editing code snippets on page: have you tried "Special Text" button of wysiwyg. It supports syntaxhighlight tag of MW and does the similar thing what you are trying with codesnippet plugin. Only difference is that this does not color text in edit mode. Output is displayed on page on grey background and it can be edited directly on page. In order to activate this feature your LocalSettings.php has to have these lines:

$wgFCKEditorSpecialElementWithPreTag = 0;

$wgFCKEditorSpecialElementWithTextTags = 0;

You write text on page, select textblock you want to mark as "code" and press button "SpecialTexts". On dialog you have to select "SyntaxHighlight" and define programming language as "Value of attribute" and press Ok => selected text block will be formatted as pre-syntaxhighlight- block in edit mode. When you save the page, codeblock will be highlighted with colors. Riparap (talk) 14:03, 23 April 2016 (UTC)

This is great!! Thank you for this as this does exactly what I want... Mikelagase (talk) 23:09, 7 June 2016 (UTC)

Yw... thank you for your feedback. Riparap (talk) 16:29, 11 June 2016 (UTC)

1.5.6_0 [B551+01.05.2016], CKEditor 4.5.8 (revision c1fc9a9) and 1.26.2 not working

if i set $wgResourceLoaderDebug = true; i get the text area, but WYSIWYG is not displaying anything (still see <p> and ''')

if i do not set the wgResourceLoaderDebug i do not get the text area at all.

no errors on apache error log. 31.168.225.146 (talk) 06:40, 2 May 2016 (UTC)

You have to set $wgWYSIWYGSourceMode = true; and $wgResourceLoaderDebug = true in LocalSettings.php; if you want to use debug mode. In normal operation they should be set to false.

Have you updated your LocalSettings.php and Preferences=>Editing (your account settings of MediWiki) like is descriped in readme.md of github repository?

You can also try to disable WikiEditor or you can try updated WikiEditor of WYSIWYG bundle (Version 1.5.6_0 [B551+03.05.2016].).

After you have downloaded and installed wysiwyg, modify owner and file permissions based on your system (linux).

In my system (centos 6.7, mw 1.26, xampp 1.8.3-4, PHP 5.5.11, mysql 5.6.16) wysiwyg version 1.5.6_0 [B551+03.05.2016] works after it was extracted from zipfile of github. Zipfile does not include required settings of LocalSettings.PHP, they must be applied manually. Riparap (talk) 19:59, 3 May 2016 (UTC)

Exclude Namespace Issue

I have tried to use the namespace NS_SPECIAL to block the WYSIWYG from the special namespace. I am running IntraACL extension and it causes it to not work. Any insight on disallowing the WYSIWYG on the Special namespace?

$wgFCKEditorExcludedNamespaces[] = NS_SPECIAL;

The address I am trying to get at is Special:IntraACL but nothing is loading. 0x539 nero (talk) 21:29, 2 June 2016 (UTC)

Sounds little like you have problems with IntraACL in case you can not access special pages related to it.

In order to exclude namespaces from WYSIWYG, definition "$wgFCKEditorExcludedNamespaces[] = NS_SPECIAL;" in LocalSettings.php is right. These lines should be placed after command which enables WYSIWYG extension. Also all definitons related to WYSIWYG should be the last ones in your LocalSettings.php.

If you think WYSIWYG is causing problems with IntraACl, have you tried to disable WYSIWYG completely so that you edit wiki pages using wikieditor... that way you should be able to find out if you have problems with configuration of IntraACL. If IntraACL works properly without WYSIWYG, then you can try to enable WYSIWYG. If you then can not open any pages for editing using WYSIWYG, then there may be some compatible issue with IntraACL and WYSIWYG extensions. Riparap (talk) 15:57, 4 June 2016 (UTC)

I found the fix.

In WYSIWIG.php change:

$wgResourceModules = array(

to

$wgResourceModules += array(

This will allow IntraACL to work properly. 0x539 nero (talk) 21:45, 6 June 2016 (UTC)

This has been included in Version 1.5.6_0 [B551+11.06.2016]. Riparap (talk) 16:30, 11 June 2016 (UTC)

Sounds good, hopefully this helps you.

This also allows Mobile Front end extension to work as well. 0x539 nero (talk) 19:29, 14 June 2016 (UTC)

Add MSUpload to CKEditor

I have the WYSIWYG editor setup and would love to add the ability to include the msupload extension to upload multiple files to the Mediawiki site. Versions I am using are below.

MediaWiki - 1.25.5

PHP - 5.6.22

WYSIWYG - 1.5.6_0 [B551+18.04.2016], CKEditor 4.5.4 (revision d4677a3)

MSUpload - 10.0

I've searched but could not find any information on how to easily add a new button on the menu or to enable MSUpload in the interface. Has anyone done this before and if so are there steps out there that I could use to get this enabled?

Thanks,

Mike Mikelagase (talk) 23:00, 7 June 2016 (UTC)

Because MSUpload is not a plugin of CKeditor and based on the nature of that plugin, I am not sure if adding just a button for MSUpload in wysiwyg would be enough. It may require additonal modifications with wysiwyg too.

File ckeditor/config.js contains definitions of buttons for plugins of ckeditor. Some of the buttons related to wysiwyg are defined in ckeditor\plugins\mediawiki\plugin.js. Riparap (talk) 16:40, 11 June 2016 (UTC)

Resource loader of MW: using other extension WikiEditor with Wysiwyg

Should js- modules of WikiEditor be defined together with modules of Wysiwyg for resourceloader.... can anybody give me exact information about how I should define module of "external" extension WikiEditor to be loaded when wysiwyg starts? ...can 'dependencies' of $wgResourceModules be used? Riparap (talk) 09:00, 29 June 2016 (UTC)

MW 1.27 and Wysiwyg (versions >= 1.5.6_0 [B551+02.07.2016])

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Branch wysiwyg_mv127 contains latest modifications.

Extension can be activated using wfLoadExtension- method (MW>=1.25).

This bundle is compatible with MW1.27. It should also work with some of the earlier versions of MW too. Riparap (talk) 17:38, 1 July 2016 (UTC)

See: Unknown dependency: ext.wikiEditor.toolbar Awatkins1966 (talk) 13:44, 14 July 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Unknown dependency: ext.wikiEditor.toolbar

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I upgraded from MW 1.25.5 to 1.27 and downloaded wysiwyg_mv127, but I am not seeing the WYSIWYG/CKeditor appear at all. No errors on Apache 2.4 server.

I think it is not loading any of the code, since on the Firefox Console->JS I see "Error: Unknown dependency: ext.wikiEditor.toolbar"

To be honest I am not seeing any of WYSIWYG js routines in console of Firefox, but I do know that WYSIWYG/files are being accessed by the browser (apache server logs).

Thanks Awatkins1966 (talk) 20:33, 14 July 2016 (UTC)

Just add the following line before loading the editor.

require_once( "$IP/extensions/WikiEditor/WikiEditor.php" ); A-Kint (talk) 17:47, 17 July 2016 (UTC)

Spot on. Cheers Awatkins1966 (talk) 15:34, 18 July 2016 (UTC)

Do you mean that setting "wfLoadExtension( 'WYSIWYG' );" in your LocalSettings.php did not work at all or was it so that you did not add any lines in your LocalSettings.php at first? If you tried "require_once( "$IP/extensions/WikiEditor/WikiEditor.php" );" and that worked ok, can you also try to test "wfLoadExtension( 'WYSIWYG' );" ....does it work properly or not ? Riparap (talk) 23:05, 18 July 2016 (UTC)

Yes, setting "wfLoadExtension( 'WYSIWYG' );" did not work for me. I did try require_once( "$IP/extensions/WikiEditor/WikiEditor.php" ); after the above and that failed. The solution was I had to have both and in the correct order:

"require_once( "$IP/extensions/WikiEditor/WikiEditor.php" );" and then

"wfLoadExtension( 'WYSIWYG' );".

(Version was wysiwyg_mw127 1.5.6_0 [B551+08.07.2016], will look at latest version later) Awatkins1966 (talk) 16:31, 21 July 2016 (UTC)

Edit_1:

WikiEditor of Wysiwyg bundle uses method wfLoadExtension( ... ); to start WikiEditor.

There seems to be problem with WikiEditor setup in Wysiwyg. Wysiwyg tries to load javascript module of WikiEditor, even when WikiEditor is not enabled. So after you enabled WikiEditor, Wysiwyg started succesfully. Advantage of having WikiEditor is that now you have little better text based wikitext editor, in case you use source- button or toggle link of editing mode.

This is not big issue, because WikiEditor is included with bundle, I will anyway try to check if I can fix this somehow...

Edit_2:

It seems to be so that I can not disable WikiEditor. Reason is that I do not know if conditional declaration of modules for resource loader is possible in file extension.json. This means that in LocalSettings.php both extensions Wysiwyg and WikiEditor have to be enabled as you already noticed. Riparap (talk) 18:02, 21 July 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Branch wysiwyg_mw127_459:widgets, change of dataprocessor (versions >= 1.5.6_0 [B551+20.07.2016])

This branch has 3 major modifications to Wysiwyg- extensions (Version 1.5.6_0 [B551+20.07.2016]):

*CKeditor 4.5.9 + widget plugin

*Custom dataprocessor of Wysiwyg has been replaced by standard dataprocessor of CKeditor.

*Refences (ref- and references- tags) are now using widgets (support drag and drop of elements).

See description here. Riparap (talk) 21:34, 19 July 2016 (UTC)

Category picker loop

Categorys are categorys of themselves or link to other categorys that sub category link back, create a infinite loop of the wfSajaxSearchCategoryChildrenCKeditor function that breaks the add/editor category feature, i've mitigated the issue on my wiki by limiting the loop.

In CKeditorSajax.body.php

line 295

$sub = explode( "\n", wfSajaxSearchCategoryChildrenCKeditor( $row->title, 0 ) );

wfSajaxSearchCategoryChildrenCKeditor function

function wfSajaxSearchCategoryChildrenCKeditor( $m_root, $i ){
          $limit = 50;
          $ns = NS_CATEGORY;
          $dbr = wfGetDB( DB_SLAVE );
          /// @todo FIXME: should use Database class
          $sql = "SELECT tmpSelectCatPage.page_title AS title FROM ".$dbr->tableName('categorylinks')." AS tmpSelectCat ".
                          "LEFT JOIN ".$dbr->tableName('page')." AS tmpSelectCatPage ON tmpSelectCat.cl_from = tmpSelectCatPage.page_id ".
                          "WHERE tmpSelectCat.cl_to LIKE ".$dbr->addQuotes($m_root)." AND tmpSelectCatPage.page_namespace = $ns";
  
  
  
          $res = $dbr->query( $sql, __METHOD__ );
          $ret = '';''
          //$i = 0;
          while ( ( $row = $dbr->fetchObject( $res ) ) && ( $i <= $limit ) ) {
                  $ret .= $row->title . "\n";
                  $i++;
                  $sub = explode( "\n", wfSajaxSearchCategoryChildrenCKeditor( $row->title, $i ) );
                  foreach( $sub as $subrow )
                          if( strlen( $subrow ) > 0 )
                                  $ret.= ' ' . $subrow . "\n";
          }
  
          return $ret;
  
  
  }

HellToupee1 (talk) 00:50, 28 July 2016 (UTC)

Getting PHP uninitialized string error when editing

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The editor works correctly but errors show up in the apache logs and on the wiki page being edited.

[Fri Aug 05 08:57:19.214228 2016] [:error] [pid 18279] [client 192.168.100.1:52783] PHP Notice:  Uninitialized string offset: 0 in /var/www/mediawiki-1.27.0/extensions/WYSIWYG/CKeditorParser.body.php on line 1324, referer: http://192.168.100.20/mediawiki/index.php/Partition

CentOS 7, Mediawiki 1.27, PHP 7.0.9, WYSIWYG mw127_459 71.183.230.25 (talk) 13:09, 5 August 2016 (UTC)

Name of the branch does not identify version of WYSIWYG. What version of WYSIWYG are you using?

If you are using the latest version of WYSIWYG, then function where line 1324 is has not been changed by latest major modifications. Is it possible for you to try to strip the contents of the page so that it will only contain the wikitext code that causes the error and could you then post that wikitext here, so that I could test it more.

Problem may perhaps be solved by changing test ' ' == $t{0} to ( !empty($t) and ' ' == $t{0} ) on that line. Riparap (talk) 17:48, 7 August 2016 (UTC)

Thanks a ton @Riparap, the change in the code worked to fix the error. 71.183.230.25 (talk) 02:53, 9 August 2016 (UTC)

This fix has been included in Version 1.5.6_0 [B551+09.08.2016]. Riparap (talk) 07:12, 10 August 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Using TreeAndMenu extension with WYSIWYG

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The text in my wiki page for TreeAndMenu changes with WYSIWYG from

{{#tree:

*Item

**Sub-item link

**sub-item

}}

to this after I use WYSIWYG editor

{{#tree: *Item **Sub-item link **Another sub-item }}

The TreeAndMenu is listed in the our wiki Special Pages as one of the extensions used. 104.129.198.111 (talk) 21:37, 18 August 2016 (UTC)

Is there problem only with the line feeds.... If you save the page, does that syntax still work or does wysiwyg somehow corrupt it so that extension does not do what it is supposed to do when wikipage is viewed. Riparap (talk) 07:01, 19 August 2016 (UTC)

It does not work when viewed. It bundles everything together so before wysiwyg is invovled the text looks like this

+Parent item

+Parent item

and expanding looks like this

-Parent item

Child item

Child item

-Parent item

Child item

Child item

After hitting "Show Preview" the text looks like this:

Parent item **Child item **Child item *Parent item **Child item **Child item 104.129.198.115 (talk) 14:41, 19 August 2016 (UTC)

I should add that I am using the latest version of WYSIWYG with MediaWiki 1.27 104.129.198.115 (talk) 14:52, 19 August 2016 (UTC)

Seems like that plugin is sensitive to missing linefeeds of bulleted lists. Linefeeds should now be kept with those definitions in wysiwyg versions >= 1.5.6_0 [B551+19.08.2016]. Riparap (talk) 10:29, 21 August 2016 (UTC)

I tested the new release and now the tree menu appears on first save but if I edit the page again the tree disappears.

Thanks a lot for the work you have put in. 104.129.198.114 (talk) 20:36, 22 August 2016 (UTC)

I tested again and it works now. I don't know why it did not work initially. Thanks so much. You are a genius 104.129.198.114 (talk) 20:55, 22 August 2016 (UTC)

Nice to hear that it works :). Problem with your first test may have been caused by browser cache issue. If wysiwyg bundle is updated, it would be good to empty cache of browser before doing any tests. Riparap (talk) 06:18, 23 August 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Minor issue with ckeditor

Great extension but I notice it always gives <html> at the end of the document after editing. Using the latest version for mediawiki and the ckeditor. 14.100.135.35 (talk) 11:22, 20 August 2016 (UTC)

I can not reproduce this with version 1.5.6_0 [B551+16.08.2016] of wysiwyg. I created new page with few text lines and saved the page. It was saved properly without any extra html-tag in the end of page.

Can you test it bit more and perhaps post you failed wikitext code here, so I could try it too. Riparap (talk) 08:54, 21 August 2016 (UTC)

Experiment help

Hi I'm currently designing a widget to add the CkEditor to Semantic Forms via a CDN. I already have a working model, but the problem is the editor produces HTML, not wiki syntax. This lead me to finding this extension, which I didn't know about. Anyways before I go hunting through the code I'm wondering if anyone can point me to the files that they found were absolutely necessary to convert the editor from a HTML editor to one that handles wiki syntax. According to what I've read I can create local plugins to hook into the editor from the cdn files (hopefully that makes sense), which has lead trying to find code to do before I attempt to do all the work. Thanks for any help anyone can give. Christharp (talk) 21:39, 13 October 2016 (UTC)

Wysiwyg is partly using mediawiki to convert wikitext to html, except with some special elements which wysiwyg is using (event editor.on( 'toHtml' => conv_toHtml in ckeditor/plugins/mediawiki/plugin,js).

Convertion from html to wikitext mode is done by method _AppendNode of ckeditor/plugins/mediawiki/plugin,js. Action is started by editor.on('toDataformat'...) event which is using method conv_toDataFormat and so on.

At some point earlier this branch of wysiwyg has also partly supported semantic forms plugin, it has not been fully compatible though (COMMENT of readme.md: 27.03.14  Integration of WYSIWYG with SemanticForms 2.7 (SF) (and SemanticMediaWiki (SMW)) as editor of free text block for SF (experimental version) TOPIC: What's the latest on Semantic Mediawiki Forms integration). There were some modifications required also with Semantic Forms plugin, which is included with this bundle.I have not tested if it is still working with latest version of wysiwyg. As far as I know, nobody has been using this with wysiwyg. At the time I was playing with it I was just curious to find out if I had enough knowledge to integrate it with wysiwyg. Riparap (talk) 14:35, 16 October 2016 (UTC)

Headers are changed with editor

WYSIWYG editor changes headers initially created in wikitext.  For example, it converts

“=== TEXT ===”

 

to

“=== &nbsp; === TEXT”

TEXT in this case is:

<div style="border: 1px solid rgb(163, 191, 177); background-color: rgb(221, 221, 221);">[[:Category:Documentation:AD_and_LDAP|AD and LDAP]]</div> <div style="float: left;"> 165.225.34.135 (talk) 16:18, 10 November 2016 (UTC)

Your text is not in wikitext format. It is mixed html and wikitext. These are known to be problematic for wysiwyg, they may or may not work depending on contents. I'll try to test this when I have time... Riparap (talk) 22:17, 16 November 2016 (UTC)

We changed the text to wikitext and it works so much better now. Thanks for the heads up. 165.225.34.129 (talk) 00:35, 18 November 2016 (UTC)

Brand new installation

Just downloaded and installed MW yesterday. Today I'm adding your WYSIWYG bundle#6 to our wiki and I read:

"**Preferences=>Editing (your account settings of MediWiki):**

Make sure that settings in your Preferences=>Editing are valid.

>DO NOT select these:

- Show WikiTextEditor

- Open rich editor in a popup"

Should it be safer to edit the preferences php file and "hide" these options permanently then? 213.148.204.109 (talk) 09:32, 22 November 2016 (UTC)

"Show WikiEditor" does what it says and disables wysiwyg in case user wants it, so I guess it is not necessary to take this away.

"Popup" feature is currently unsupported. Code related to popups has been kept because I have not wanted to delete it in case somebody finds popups usefull and is willing to do something about it. Riparap (talk) 08:48, 23 November 2016 (UTC)