Formatting is stripped from heading and break tags

[seankurth]

When I type

<h3 style="font-size:16pt; font-weight=bolder; color=purple;">Title</h3>

it returns a simple level 3 heading "=== Title ===" and strips all the formatting. Same goes for

<hr style="color:purple; width=50%; align=center;"> 

rather than returning a half width purple thematic break in the center of the page, it just gives me a plain, black, left-aligned "----."

[riparap]

If you have this kind of problems I would suggest that you create new empty page and input your text there. Doing that will eliminate effect of other texts on page with the issue you have.

1. I can input level 3 heading "Title" where "itl" is underlined and with italic and format stays when page is saved and reopened for editing. Saved code in wikitext mode seems to be like this:

=== T<u>i''tl''</u>e === 

It seems not to convert all formats in wikitext but it seems to work.

2. Have you inserted the line with "Insert Horizontal Line" button of wysiwyg? In my wiki it gives this in wikitext:

----

....or how have you created input in wysiwyg?

Could you provide wikitext code here with formats you would like to have within it in final text, so I could test it.

[seankurth]

I did provide the wikitext, but the 4 spaces for code thing didn't work, and I ended up with a title and horizontal line. If only markdown had an escape tag...

EDIT: Turns out, the github flavor does. The code is there now.

All my issues seem to occur when loading a template from the preloader extension. Maybe it should be added to the list of incompatible extensions until WYSIWYG can parse all the style tags right?

[riparap]

No problem, please feel free to do that. At this moment I do not know how to fix this.

[seankurth]

OK, will do.

[riparap]

I am not familar with preloader extension and I do not understand relation of it to wysiwyg :) What format pages created for it have, are they in plain wikitext code or do they include also html code. Is it possible to create those template pages using wysiwyg, then you would not have compatibility problems, because you would only use formatting which wysiwyg understands? ...Could you explain briefly how it works.

[seankurth]

What it does is it assigns a different boilerplate template page to each namespace in LocalSettings.php, then preloads that template into every page in that namespace. So if I define the Foobar: namespace, set it as a content namespace, and assign it Template:Boilerplatefoobar in LocalSettings.php, the contents of Template:Boilerplatefoobar will be transcluded into the page creation form of every new page in Foobar:. You can put anything you want in the templates, although they are wikitext only (unless you have an XML or HTML parser extension, which I don't).

The problem is that because Preloader works in the template namespace, which WYSIWYG doesn't support, there's no way to know whether your boilerplate has WYSIWYG compatible markup until you've already created hundreds of broken pages. So preloader is very good at revealing small but annoying bugs in any non-default parser, including WYSIWYG. I've posted what noteworthy one I've found.

[seankurth]

As far as a possible fix, I would suggest making WYSIWYG treat h2 and h3 as regular formatting tags. Kind of like how div style= syntax yields formatted text instead of an actual div enclosure. For the bulleted lists issue, I would suggest a hard coded $"*"=$_REQUEST["* "] conditionally when there's an asterik above and below, text above and asterik below, or text below and asterik above. The same could be done with the "#" symbol. I know its PHP pseudocode, but as far as I know you can hook between PHP and javascript. Its probably bad practice, but I do things like prompt(<?php ?>); to convert input all the time.

Since WYSIWYG, from what I see, works by converting the wikitext into HTML then back into wikitext (I could be wrong, I can't do much more with javascript than process forms and embed things, most of what I know is PHP and html, and what javascript I do use does nothing but hook into PHP mail and upload scripts), I don't see why it couldn't just be told to leave wikitext that looks like html as is. You already do that with some XML tags anyway, right?

[riparap]

Thank you for more detailed explanation. As I said in other thread here I am newbie with javascript and php programming and 99,9 % of the code of wyisywg has been created by much more experienced programmers than what I am :). This issue sounds rather challenging to me. I can try to test this when I have time but I can not promise any fast fix. Help is always highly appreciated :).

I think that original idea of this wysiwyg version has been to work as converter between wikitext and html formats. yet it is not 100% succesfull with it.

I was just wondering if HTML Tags -extension would be helpfull in this case. It isolates html strings within htmltag -tags, which should then produce special -element in wysiwyg and can be edited by tag -dialog. There may be some issues with tag dialog depending on how complicated html string one would like to enter there, but they will be rather easy to fix.

[seankurth]

It looks to me like the main problem with WYSIWYG, the root cause of most of the issues, is its inability to render undefined line breaks. As in, if there's no <br> or  , it thinks everything is all on one line.I'm not entirely sure this has to be "fixed," so much as just warning users on the wiki page or readme.md page that all templates must define linebreaks or WYSIWYG will default to (what appears to be browser-based) line wrapping. A warning could also be added that formatting can't directly be applied to heading tags because WYSIWYG converts them to plain == Title ==. However, in my testing, something like == <span id="toc_item1" align="center" style="font-size: 18pt !important; color: purple;">Title</span> == produces exactly what you'd expect it would: A center-align, purple heading with a font size that can't be overridden. Because WYSIWYG detects that its already working with wikitext, it just ignores everything else and properly renders the HTML.

As far as the <hr id="" style=""> converting into plain ---- issue, I think a solution might be to just render HTML as is when the user chooses to use it instead of wikitext. Something like

if var language = html('GET', '/extensions/WYSIWYG/htmltags.txt');
{
   language.convert = false();
}

might do. Obviously this is pseudocode and the syntax is all wrong, for example I don't think you can use GET in an if loop (though I could be wrong), but something similar might work. At least that way you could just have a list of html tags rather than trying to make an if loop for each one.

[seankurth]

I've looked through ckeditor.js, and although I don't know enough to be sure (as in, I'm probably wrong), it looks like how WYSIWYG works is by loading the content of the article tag by tag, storing all the original code in memory via DOM manipulation, converting individual wikitags into HTML with an if loop array, then loading back the old wikitext, plus whatever edits you've made, converted back via another array. If you wanted to (if you don't have the knowledge to create a regex you could probably find a wikicode regex on google), you could probably simplify a bit by replacing some of those massive arrays with wikicode detecting regexes. Or alternately, moving the arrays to a separate text file and using GET.

This means that you could probably use another nested if loop (or else if, if you're so inclined, sorry I couldn't resist that bad pun) to tell it to store tags that are already HTML in memory, without converting them, and display them in WYSIWYG as is, so they aren't converted to or from. And so you didn't have to build another massive array of tags, you could basically load the entire HTML4 standard in a text file as demonstrated above. A simple regex like <("[^"]*"|'[^']*'|[^'">])*> might do the job, but you might want to add hr, h2, h3, and & and ; (to prevent unicode hexes from turning into plain text) to that list. the <, >, ', and " should catch all HTML tags, but it wouldn't hurt to add some specific ones that are causing issues. It would be unnecessary, but you can never be too careful. And of course, you'd want it in a separate text file because those quote marks might cause problems with the GET.

This way when the user chooses to write a page in a mixture of html and wikitext, everything renders and converts properly without all turning back into wikitext.

As I said, I'm a javascript noob too, I'm way better with PHP, so some of that code might have to be modified a bit before it will work (there are probably tons of mistakes that would be obvious even to you), but I think the general idea should be sound.

And on that note, I'm leaving for thanksgiving today and I'm not sure if the park has WiFi, so I might be unavailable for a few days.

[riparap]

File ckeditor.js is part of CKeditor, I think that files of CKeditor may not be modified, because changes there will make update of CKeditor impossible.

On general all this goes far beyond my skills. If tag takes care of format problem I would suggest that as workaround. It may not be that user friendly, but if it works why not use it.

[TrevorPearson]

I was able to get the "NewArticleTemplate" extension to work with WYSIWYG. It didn't work at first until I moved the "require_once(...NewArticleTemplate)" above the "require_once" for WYISIWYG in LocalSettings. Maybe that will work for this plugin.

[riparap]

You have it right, wsiwyg plugin should be the last of all plugin definitions in LocalSettings.php, because wysiwyg should know possible tag names other extensions may be using. I will include this information in short installation instructions.

However, in my opinion order of plugin definitions does not have anything to do with issue of this thread because here we have problem where html code is mixed with wikitext. This "fights" against the original desing idea of wysiwyg. But because MW is allowing html among wikitext, users are then trying same thing with wysiwyg. Some of these combinations may work, others will unfortunatedly fail.