Extension talk:NamespaceHTML

Mixing html with mediawiki variables

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 thanks for writing extensions. I've been exploring the SecureHtml extension, but have hit a wall since it's not possible to use mediawiki variables inside the secure html tags. My understanding is that raw html tags allow this possibility (see:https://www.mediawiki.org/wiki/Project%3ASupport%20desk/Flow/2014/01#h-%5BRESOLVED%5D_template_variables_within_html_tags-2014-01-28T13%3A13%3A00.000Z)

Anyways was wondering if your extension can allow this possibilty in the same way. All the best Christharp (talk) 19:56, 11 July 2014 (UTC)

The extension basically does the same thing as the normal $wgRawHtml setting, except that it applies it to specific namespaces. So the answer to your question is that if it works with $wgRawHtml = true; then it will almost certainly work with this extension. And if you find that it works, you may want to add a line or two to the documentation. It seems like a nifty idea! Ike @ WikiWorks 20:22, 11 July 2014 (UTC)

I'll be testing it this weekend. Will add to docs if it works. All the best to you. Christharp (talk) 20:50, 11 July 2014 (UTC)

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

Testing as a tag function

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

As per my earlier comment I've been testing this extension as tag function. Example of the test:

{{#tag:html| <form action="mailto:{{{email}}}" enctype="text/plain" method="post"> <p>Name: <input name="Name" type="text" id="Name" size="40"></p> <p>E-mail address: <input name="E-mail" type="text" id="E-mail" size="40"></p> <p>{{{Name}}}:</p> <p><textarea name="Comment" cols="55" rows="5" id="Comment"></textarea></p> <p><input type="submit" name="Submit" value="Submit"></p> </form>}}

So far using it as a tag functions seems to work just fine, which makes it possible to use MW variables inside the html tags. After I run a lot more tests I'll add a note on the front on doing it.

Having a secondary issue that I can't seem to get the extension to function in more then one namespace. Any thoughts on that? All the best Christharp (talk) 22:14, 12 July 2014 (UTC)

Good to hear that you're having success with it. What code are you using in LocalSettings? Ike @ WikiWorks 04:42, 13 July 2014 (UTC)

Tried several settings in LocalSettings, but no matter what I tried I couldn't get more then one Namsspace to work.

On a different note, anyway to re-code the extension so it could work when something is tranincluded from one namespace to another, but without allowing the use of raw html in the Namespace it's tranincluded into? (except, of course, for the html transincluded) Ideally this would make it possible to restrict editing to the Template Namespace, with raw html enabled, but allow end users access to wiki variables inside that html. Christharp (talk) 17:05, 14 July 2014 (UTC)

I just tested it in two namespaces successfully. Your LocalSettings.php should look something like this (after extension inclusion):

 $wgRawHtmlNamespaces = array( NS_MAIN, NS_PROJECT );

Transclusion is something I've been wondering about. Right now you cannot transclude from a raw-enabled namespace to a "normal" namespace. I was worried about the security implications, but I don't think that it's the right decision. Any code in a raw-enabled namespace is already presumably secure, so what's the harm in including it somewhere else?

I don't understand your particular use-case. But if transclusion was enabled would it help you? Ike @ WikiWorks 18:15, 14 July 2014 (UTC)

Yes it would be great if transinclusion was possible. The user case is like I was describing in the first thread. Using the tag function wiki variables can be used with html, which opens up the possibility of templates where the user could set the variable, but not be able to add raw html themselves. In my case I operate a wiki that has the yellow pages data of the United States and by allowing the end users to set the variables I could add html to let them embed their Instragram, Pinterest, etc., per listing. Additionally I could pre-design forms in html, like a Contact page, Employment Application, etc., where the person editing the page could actually change the questions (have the questions set as wiki variable) and then present to the end reading user a form to fill out (kinda of like a form designing system seen on sites like Wufoo).

So, not to get long winded, transinclusion would be awesome, great and most, most helpful.

I'll try the settings you suggested and see if it solves the problem of only operating in One Naemspace. I thought I did have my code the way you show, but maybe I make a small syntax error. All the best and thanks again for the work. Christharp (talk) 19:33, 14 July 2014 (UTC)

Version 0.2 is now available and supports transclusion. Ike @ WikiWorks 21:13, 14 July 2014 (UTC)

Tested version 2 and it's great. Thanks.

Additionally I've got the wiki variables working inside a template with the html. I can add some examples on the front page if you desire, or as sub-pages underneath the main extension page. All the best. Christharp (talk) 04:23, 17 July 2014 (UTC)

I think it just needs a line or two. I'll add it one of these days. Thanks. Ike @ WikiWorks 19:52, 17 July 2014 (UTC)

Whatever you think is best. But I thnk I should mention a possibility that maybe you haven't considered, which is: that since the tag function can be used to mix html & mediawiki variables it's then possible for this extension to take over, or be used as an alternative to the Widgets, and the Widgetframework extensions. As a test I quickly templated out the code for youtube setting the id as a mediawiki variable -- it worked great. Anyways, I think, that your extension would allow for much faster creation of all sorts of "widgets" then the two I mentioned. A whole library of "widgets" etc., could be listed on subpages to the extension's parent page.

Anyways just a thought. All the best to you & thanks for creating this great extension. Christharp (talk) 23:45, 17 July 2014 (UTC)

I have thought of it. But I don't see why this extension is any faster or better than Widgets. And I still worry that maybe there's some way to inject nasty code into a template using this extension. (I haven't been able to in my tests, which is why I enabled passing parameters.) Widgets has tools for escaping user input. Ike @ WikiWorks 23:57, 17 July 2014 (UTC)

Just a thought. The only reason, I think, it would be faster and easier to use then Widgets is it would allow users to just grab the embed code from most sites and by a minor modification allow a wikitext variable. No screwing around with smarty templates, etc., -- just the embed code from whatever site and a minor change to setting mediawiki variable. Of course with greater freedom there is a greater chance for security issues to arise. But it still seems it would encourage more "widget" creation -- my bet is that the library of possible widgets with this extension would exceed the Widget website within a month.

Anyways that's my half cent opinion. Once again all the best to you. Thanks Christharp (talk) 00:16, 18 July 2014 (UTC)

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

Added subpage on how to add Pinterest

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, I hope you don't mind, but I added a subpage on how to use this extension to embed a Pinterest feed, button, etc.Also added link on the extension page itself. If you don't want the extension known for these types of embeds please feel free to delete away. Christharp (talk) 23:21, 14 August 2014 (UTC)

Looks good. The only thing you might want to clarify is that the {{#tag:html|... code goes in an allowed namespace and is transcluded to another page.

Thanks. Ike @ WikiWorks 06:41, 15 August 2014 (UTC)

will do... Christharp (talk) 00:28, 16 August 2014 (UTC)

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

Doesn't working with NS_FORM

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, it seems $wgRawHtmlNamespaces= array( NS_FORM ); isn't working. (I have set define("NS_FORM", 106); and NS_FORM is recognised in other calls.) Varlin (talk) 13:00, 1 November 2019 (UTC)

EDIT : in fact, even with $wgRawHtml = true;, html is not processed in Forms definition apparently. Varlin (talk) 13:09, 1 November 2019 (UTC)

This sounds like an issue with PageForms then. Pinging @Yaron Koren Ike Hecht 14:10, 12 November 2019 (UTC)

Right, we already talked about this on the Page Forms talk page, here. Yaron Koren (talk) 16:32, 12 November 2019 (UTC)

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