Awesome, sounds good. I'll implement the changes on my wiki and look forward to finding out whether the subsection fix would be easy. If it isn't, I'll see if I can dig in to changing it myself. Does SF have a bug reporting system for me to list this bug in?

Thanks once more for all the responses!

On Wed, Nov 20, 2013 at 3:25 PM, Yaron Koren <> wrote:
Hi Ben,

Well, maybe it's not surprising that the first person to use the "section" tag is a new user. You have a blank canvas for your data!

You should be able to tell people to use "{{!}}", yes.

Escaping and un-escaping pipes would be difficult, actually - there are various complications, like that the form can't know for sure what the intended variant was, and that (contrary to what I said before) sometimes pipes *are* allowed - if you have a parser function like "{{#if:...", I think pipes within there are fine. (That is, they're fine for template calls - SF fails on them, I believe.) Semantic Forms' handling could definitely be improved, but I don't think it'll ever be perfect.


On Wed, Nov 20, 2013 at 5:41 PM, Benjamin Pelletier <> wrote:
Ah, nice, I didn't realize the "section" feature was that recent -- I just discovered Semantic a week or two ago and the process is just beautiful (I'm not yet finished with it). I'll let you guys take a look [at the subsection parsing thing] first since it would take me a fair amount of effort to spool up my understanding of how everything works. But if it turns out to be difficult then maybe I can give it a shot because I'd really like to have subsections work with the section feature. Thanks for the code line pointer -- I'll take a look at that for background regardless.

The separate Introduction input makes sense -- that seems like a pretty reasonable hack and I think I'll adopt that approach. I should be able to instruct my users to use {{!}} instead of | in the Introduction and everything will work, right? (I already have the ! Template defined)

I think I understand the benefits and drawbacks to property-izing the content and you're correct, I don't want to do that. I'm a little surprised about the | issue though -- on the one hand, I understand why that could cause problems. But on the other hand, wouldn't it be possible to sanitize and desanitize the content? Or do extensions dynamically generate wiki code rather than HTML code? (I'm not familiar with MediaWiki's architecture)

Thanks again!

On Wed, Nov 20, 2013 at 2:23 PM, Yaron Koren <> wrote:
Hi Ben,

Wow, great! I believe this is the first real-world usage that I've seen of the new "section" feature in Semantic Forms. (It was added in version 2.6, about a month ago.) Unfortunately, it's accompanied by the first-ever bug report. :) Your diagnosis is correct - the subsections within that section are messing up the parsing. I guess we didn't think about the possibility of users adding subsections when we planned this feature. We'll look into this - maybe there's an easy fix. If you want to look into it yourself, I think the relevant code is around lines 1415-1450 of /includes/SF_FormPrinter.php.

To answer your other question: you can make an output like that, via a hack: make the top introductory text be another field within the main template, and then have the template display that field by itself, above the infobox table.

(You could also, in theory, take that same approach for all the page sections below the infobox - and some people have done that - although that's an even bigger hack, and it leads to various problems, most notably that parsing gets messed up if there's a "|" anywhere in the text.)


On Wed, Nov 20, 2013 at 4:43 PM, Benjamin Pelletier <> wrote:
Issue 1:
I have a category of pages called Canyons and I've designed my Semantic Form to allow entering a bunch of simple data followed by a number of pre-determined sections. This is great for creating pages, but SF seems to choke when parsing the page content back into the pre-determined sections if subsections (=== subsection ===) are used.

For example, this page works fine -- view the form to see all the content placed into the correct section boxes:

But, this page is hopelessly mangled -- view the form to see content placed all over the place (and partially duplicated!):
As you can see, the Approach content is truncated at the subsection marker, the rest of the Approach content is put into Free text, the Descent section is also put into Free text (!) but also duplicated in Descent, the Exit info is appended to Descent, etc, etc

Is there already a known bug for dealing with this problem? Is there anything I can do differently to get things to work properly (other than not using subsections -- that's not an acceptable solution)?

Issue 2:
What I'd really like to do is to not have a section header for Introduction so that the text in that box gets placed above the table of contents. Basically, I want the result to look like this:

Is it possible to define a section-headerless page section in a Semantic Form and also have Free text at the end (or where ever)?

Where in the SF code should I go to find the routine that parses current page content into a form to see how it works?

Thanks, and thanks for creating such a great product!

Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
Semediawiki-devel mailing list

WikiWorks MediaWiki Consulting

WikiWorks MediaWiki Consulting