Extension talk:Page Forms/Archive July 2011

Dropdown doesn't autopopulate when editing a page & Foreign letters in values

There is an old unsolved question dating back to 2008 which describes perfectly what i am encountering right now.

For example, if I have a template with parameters A, B and C. If A and B are text boxes, and C is a dropdown. On the form, I put in values for A, B and C. If I then Edit using form, based on what I just made, it seems to erase entered C and makes it blank again, but A and B retain their values.

This is true if the value that gets blanked contains a foreign-language letter (e.g. ä/ö/ü etc.)
In my case i have city names in field C. e.g. 'Berlin' and 'München'. When Berlin was saved and i edit with form everything works well. If i saved München before the field gets blanked. The values are populated from properties.
Dating back to May there was a question/bug that had problems with fields popolated from categories with umlauts. Is this problem also true for dropdown inputs using Properties as source?
Is this issue already fixed? The version i must keep using is Version 1.3.6 cause due to Company regulations i may not touch even a single line of code. Is there any workaround for such a issue?
-- Regards Christian Tasler 195.88.117.31 14:35, 1 July 2011 (UTC)

Well, your company's regulations make no sense - there are known bugs, including security bugs, in the version of SF that you're using; it's in no way better than the current version. But to answer your question - no, I don't know of a workaround. Yaron Koren 03:05, 3 July 2011 (UTC)

Yeah, but thats not mine to change. As it is used internally only the security risc was evaluated and accepted by our it-security department. What a pity you dont have a workaround, so i have to cope with that bug till i get a version where it is fixed. By the way, as you didnt say anything about it, it is fixed in the more current versions, isnt it? -- Christian Tasler 84.168.124.250 22:25, 6 July 2011 (UTC)

I don't know - I assume it has, since the bug was reported three years ago... Yaron Koren 03:01, 7 July 2011 (UTC)

I fear it correlates to a bug dating May2011 (No.2 in May-June 2011 archive) "Bug with non-english letters in category-selector?". My only difference is that I am populating the values from properties, not categories. Thats why i keep coming back. -- Christian Tasler 84.169.192.183 12:24, 8 July 2011 (UTC)

I don't know - I still think it's been fixed. Either way, I think you should upgrade. Yaron Koren 17:14, 8 July 2011 (UTC)

I really wish i could. All i can do is wait till it gets done some day. I kinda found a workaround: 7bit encoding of the values (ü=ue, etc.)while selecting and recoding in all templates *yikes*. I hope i get rid of this when company finally upgrades. -- Christian Tasler 84.169.192.183 00:45, 9 July 2011 (UTC)

Minor edit setting not processed using Edit with Form, if FCKeditor is enabled

Just upgraded to 2.1.2. Very nice that NORICHEDITOR is parsed now, among other good things.

Seems that the flag for the user setting to mark an edit as minor per default is not processed when FCKEditor is enabled (tested on fckeditor 2.6.6 and 2.6.4, running MW 1.15) if you use 'edit with form' and have a freetextfield, and fckeditor enabled.

Maybe you could take a look at in for upcoming versions. I hacked it by adding an if ($wgUser->getOption('minordefault')) and 'checked'= clause in SF_FormUtils.php, but alas I'm no mediawiki wiz, so I wont be submitting that ;-)

--Ovoned 11:06, 2 July 2011 (UTC)

I can't reproduce that problem - maybe it's been fixed in SF 2.2 already (to be released soon); or maybe it's only a problem with MW < 1.16 - in either of those cases, I'm not worried about it. Yaron Koren 03:02, 4 July 2011 (UTC)

-OK, I checked out 2.2 today and see that this has indeed been fixed in SVN.

Though I cannot get SF 2.2 to work on MW 1.15.3 /SMW 1.4.3. I get: Fatal error: Class 'Html' not found in C:\xampp\htdocs\mediawiki\extensions\SemanticForms\includes\SF_FormInputs.php on line 798. Seems to be the call to Html::Hidden at the end of getHTML function. Any ideas? Nevermind, I switched html::hidden to xml:hidden, that solved it --Ovoned 08:37, 4 July 2011 (UTC)

Thanks for pointing out that MW 1.15 incompatibility - I fixed it in the code that's now in SVN. (Though that doesn't change the fact that you should upgrade your versions of both MW and SMW. :) ) Yaron Koren 02:03, 6 July 2011 (UTC)

Fancybox upload form redirects to plain form

Hey, I'm having the same problem as mentioned in this thread in the archives, when I click on the 'upload file' link in a semantic form, an empty fancybox comes up and then finally redirects to the plain uploadwindow form.

A page where this happens would be this page. I've tried the vector skin just to make sure that ain't related to the gumaxdd skin we're using. I'm on REL_1.16, revision 91358 for MW and the latest trunk of SemanticForms.

There was just a note added about this to the documentation recently - this can be caused by having "$wgBreakFrames = true" in LocalSettings.php. Is it possible that you have that? Yaron Koren 03:07, 3 July 2011 (UTC)

Multiple instance templates and radio buttons

I just noticed when using multiple instance templates which includes a field with a radiobutton input type it will only accept ONE entry. I am finding it a little hard to explain in detail, but I made an example here. If you notice, when you select an option from the second set of radio button field the selections from the first set dissappears. I hope this helps. --Dgennaro 20:11, 5 July 2011 (UTC)

Hi - I can't reproduce this, not even on IE... everything seems to work fine. What's the exact set of steps you go through on that form before the problem happens? Yaron Koren 02:12, 6 July 2011 (UTC)

So strange. What version of IE are you testing with? Poop, it is probably an IE7 thing. No special steps, just having a radio button reoccur using a multiple instance template. --Dgennaro 14:40, 6 July 2011 (UTC)

Ah, that must be it! I was testing with IE8. I did a web search, and it looks like this might be the issue - dynamically-inserted radio buttons aren't checkable. If that's the problem, it turns out that there's a Javascript workaround for it; but of course it's easier for me to recommend to just use dropdowns instead. :) Yaron Koren 14:53, 6 July 2011 (UTC)

That is my plan. Thanks for working this through with me. --Dgennaro 15:26, 6 July 2011 (UTC)

Possible Solution to: Info tooltip does not work in multiple instance templates

This entry just moved to the archives: Extension_talk:Semantic_Forms/Archive_May_to_June_2011#Info_tooltip_does_not_work_in_multiple_instance_templates

Hi Shirl, I also stumbled upon this problem with {{#info:tooltip text}} in multiple-instance templates using Semantic Forms (Version 1.9) and found that I had erroneously declared the templates as partial forms when trying to fix something else. When I removed the {{{info|partial form|edit title=...}}} part from the beginning of the multiple-instance forms the problem was solved. --Achimbode 07:26, 6 July 2011 (UTC)

Error in IE 7 when pressing "Add another" button

I repeatedly get errors when pressing the button "Weitere hinzufügen" (Add another?) of multiple-instance forms (Error message: Localized: Das Objekt unterstützt diese Aktion nicht, Unlocalized: Object doesn't support this action, on line 2572). The line of code reads if (children[x].type == 'select-one') in function addInstance() - and no form appears.

Funnily the line above says // to get around a bug in IE. There is another error indicated already when loading the page which reads Object required (Localized: Objekt erforderlich) which points to <div class="page_name_auto_complete" id="div_6"></div> some random line of HTML code (different lines somewhere in the HTML part of the page each time after changing the content of the form).

I have another form with multiple-instance forms in the same wiki which works fine - and even the broken version works fine in Firefox... Does anyone happen to have encountered this before?

Context: Internet Explorer Version 7 (IE 7.0) / Semantic Forms (Version 1.9) / Semantic MediaWiki (Version 1.5.0) -- Achimbode 08:54, 6 July 2011 (UTC)

You can probably guess my response, but: you should upgrade your version of SF. Yaron Koren 10:46, 6 July 2011 (UTC)

I know - sometimes not that easy ;) in this case: they are working on it... -- Thanks nevertheless! Achimbode 11:34, 6 July 2011 (UTC)

Internal links disappearing

I'm now using the latest verson of SF and noticed that internal links which were formerly visible to editors using the form have disappeared all of a sudden. I'm not sure of this is a SF issue or something else, since I couldn't reproduce the problem on referata. Cavila 12:22, 6 July 2011 (UTC)

It's a bug in version 2.1.2, but not in earlier versions, or in 2.2 - which is hopefully coming out very soon... Yaron Koren 14:35, 6 July 2011 (UTC)

Don't worry, it's always to good to know that the problem wasn't me (meaning that I don't need to re-check everything). Cavila 09:25, 7 July 2011 (UTC)

Not a perfect solution but a work around is to use a hardcoded external link pointing to the internal page

Autocomplete, Hebrew and categories

I'm trying to have a field combobox with autocompletion from a category, in a wiki using MW 1.16.5/PHP 5. Semantic forms version is 2.1.2, and semantic MW 1.5.5.

The combobox with auto completion works, but it's not populated by values from the given category. I tried dropping the input type, and nothing happens either. The form does not autocomplete at all. So I think that something is wrong with the "values from category" attribute. Could this have something to do with me using a Hebrew language wiki?

This is the field definition

 {{{field|team|values from category=teams|input type=combobox}}} 

and the original in hebrew

 {{{field|קבוצה|values from category=מועדוני_כדורגל|input type=combobox}}} 

89.139.166.172 19:10, 6 July 2011 (UTC)

Hi - this definitely sounds like a bug. Is there any way you could reproduce this problem on a public wiki, like http://scratchpad.referata.com ? Yaron Koren 21:06, 6 July 2011 (UTC)

Thank you Yaron. I tried to reproduce it here http://scratchpad.referata.com/wiki/Special:RunQuery/APITest but it seems to produce results as expected. Perhaps this bug something to do with MW 1.16 bug, I see that referata wiki uses 1.17. Any thoughts? 89.139.166.172 21:42, 6 July 2011 (UTC)

Thanks for trying to reproduce it. It could be the MW version, or the SMW version, or the SF version - Referata is also using SF 2.2, which is planned to be released in the next few days. (Or it could be something like the database encoding.) I guess I would recommend to try upgrading all of them, and see if that fixes the problem. Yaron Koren 22:11, 6 July 2011 (UTC)

FYI - I did a quick and dirty test on MW 1.17.0 with SMW 1.5.6, same as referata (still with SF 2.1.2, last released version). Problem still persists 89.139.166.172 08:02, 7 July 2011 (UTC)

Well, I've upgraded SF and SMW as you suggested, and nothing changed. I think there's something basic that's wrong. I tried running the code from here [1] demonstrating the "show on select" feature of a field, and even that did not work. The field on the RunQuery page was simply displayed without the dropdown list. Since I'm using MW 1.16.5 which should be compatible, then the only thing that's left as the source of the problem is what? MySQL? I'm at a loss here. Any suggestion would be appreciated. Thank you 89.139.177.43 19:40, 10 July 2011 (UTC)

My guess is that there's a Javascript error on the page - maybe because of interference from some other extension, or from the skin. Try looking at the form page with Firefox, with the "Firebug" plugin installed - that's my preferred debugging tool - and see if there are any Javascript errors at the bottom. Yaron Koren 01:39, 11 July 2011 (UTC)

I tried disabling all other extensions and reload the page, but this did not improve anything. I then installed firebug, and indeed there are several dozens of javascript errors when I load a RunQuery page, some of them from the semantic extensions. No errors though, and anyway the warnings are deep inside the code. If I find a way to save the log from firebug, would you be willing to take a look at teh warnings?

Sure, yeah. Yaron Koren 00:34, 18 July 2011 (UTC)

Pass values dynamically to RunQuery

I apologize if this is a question that has been asked before, but being a newbie to SemanticForms I could not figure it out from the instructions.

Is it somehow possible to pass values to a RunQuery page dynamically (I guess you might say this is Ajax-like)? I want to have a query who creates the response content dynamically, so it contains links to the same query with other parameters. I should point out that the data is retrieved from an external DB (i.e. the data is not pages in my wiki, that can somehow be categorized etc.).

An illustrative example would be a form in which I can ask to list all employees. The form filler can ask to view the list of female/male/all employees. The response would also contain links to all lists, one to a list of all male employees, and another link to the list of female ones, etc.

Ideally these links would simply be directly to the query page, with the field already filled so the query can be executed. I did not figure out a way to do so, and would greatly appreciate help on this matter. I hope I made myself clear 89.139.180.229 22:40, 7 July 2011 (UTC)

Quoting Yaron's email, This is already possible, with an undocumented feature: add "wgRunQuery=true" to the query string. Here's an example. This has been now added to standard documentation.

Thanks, this looks like what I was looking for. But it seems I can't create a wiki link with this syntax. I'd like to have something like

[[Special:RunQuery/Item_query?ItemQuerier[author]=A&ItemQuerier[source]=New&wpRunQuery=true|Here's an example]]

To appear as a regular internal link. But the parser does not accept this, probably because the '[]' characters get parsed as wiki markup somewhere along the way. Is there a way around this? 89.139.180.229 08:17, 8 July 2011 (UTC)

You might want to try the following solution while the second example uses <span class="plainlinks"> to hide the fact that it is an external link.

[{{fullurl:Special:RunQuery/Item_query|wpRunQuery=true&ItemQuerier%5Bauthor%5D=A}} Here's an example]

<span class="plainlinks">[{{fullurl:Special:RunQuery/Item_query|wpRunQuery=true&ItemQuerier%5Bauthor%5D=A}} Here's an example]</span>

Worked like a charm. Thank you for your help

This can also be done more simply by changing [ and ] in the URL to &#91; and &#93;, respectively. By the way, I mistyped it before: it should be "wpRunQuery", not "wgRunQuery". Yaron Koren 17:11, 8 July 2011 (UTC)

Could we have fields in forms 'without' properties?

I find the autocomplete-functions very nifty, and have set up fields (lets call them "helpers") in some of my forms which sole purpsoses are to help the user to find links and templates using the autocomplete. The properties of these helpers doesnt contain any data of interest after the forms have been submitted, though.

An example of how I use these helpers is to autocompletes on a concept which contains all content articles on the site: the user will get a list of all current articles, and easily makes a copy-paste operation or such to insert to article link in the freetext field.

My question if it would be possible, in a future release, to have fields that works without actually transmitting property values into the article, when the form is submitted? Such as it is today, I use dummyproperties in my forms, but the downside of that is that my pages contains extrafluous data, and also that these dummyproperties of course are picked up by SF on subsequent edits with form, and my users have to clear out the previous helpers data when they make a new edit.

So it's basically a feature request to

1. using a sf-field without submitting the property value
2. a field which is always empty when you edit with form

To say this is a bit outside the scope of SF may not be wrong ;-) Anyway, SF is pretty flexible, maybe there are more out there who has done or thought somthing similar...?

--Ovoned 21:02, 8 July 2011 (UTC)

Hmm I missed that I can remove the property assignments from the templates to avoid adding s

emantic data. To clear an existing form field value when you edit with form seems impossible though. Maybe another field option, something like "alwaysreset" or "forcedefault=", so the value is overwritten when you make another edit with form? --Ovoned 21:26, 8 July 2011 (UTC)

That's an interesting problem. The cleanest solution to this might be simply a "do not store this field in the page" option - that doesn't exist either, but maybe it should. Yaron Koren 13:54, 10 July 2011 (UTC)

It would be nice to see it in a future version. I'm think there are many other users that take advantage of SF to do similar things. --Ovoned 09:30, 11 July 2011 (UTC)

Just do something like this: {{{field| |values from category=event|input type=combobox}}}

It will not be saved and consequently will show up empty on every edit.

--F.trott 08:05, 12 July 2011 (UTC)

Ooh - I hadn't thought of that! The one downside of hacks like this is that there's no guarantee that they'll work with future versions of the software - but still, that's clever. Yaron Koren 13:24, 12 July 2011 (UTC)

Nice catch. Thanks! --Ovoned 21:28, 13 July 2011 (UTC)

Text Property and character limit

Is the text property supposed to be unlimited? It seems to cause an internal server error for me when it gets beyond about 4000 characters... though I guess that could be a limit in MySql perhaps?

Just thought I'd mention it here in case it is a bug.

Keep up the great work with Semantic Forms. Cheers

125.237.124.157 03:36, 9 July 2011 (UTC)

It does sound like a MySQL problem - but in any case, this is probably an issue for Semantic MediaWiki, not Semantic Forms (unless saving those same values works via the normal "edit" tab). Yaron Koren 13:57, 10 July 2011 (UTC)

Standard Input Saving Large Text Issue

Hello: When using Semantic Forms to save a large amount of text data, it fails to save. The below code works nicely when field ArticleText has minimal data (ie less than about 300 characters). But when more text is entered (ie over 350 characters), it fails with the message:

(20024)The given path is misformatted or contained invalid characters: Cannot map GET /wiki/Special:FormEdit/Article/Article0000003 HTTP/1.1 to file, referer: http://cody/wiki/Article0000003
(20024)The given path is misformatted or contained invalid characters: Cannot map POST /wiki/Special:FormEdit/Article/Article0000003 HTTP/1.1 to file, referer: http://cody/wiki/Special:FormEdit/Article/Article0000003

Form Code:
{{{info|page name=Article<unique number;start=0000001>}}}
{{{for template|Article}}}
{{{field|ArticleText|rows=10|cols=100|autogrow}}}
{{{end template}}}
{{{standard input|save|label=Save Article}}}

I have tested with LocalSettings.php $wgArticlePath = $wgScriptPath.'/index.php?title=$1' and with $wgArticlePath = "/wiki/$1" ie to eliminate the short URLs and colons as a problem. In both cases, MediaWiki hangs, and the page is not saved.

Installation details: Semantic Forms (v2.1.2), Semantic MediaWiki (v1.5.6), MediaWiki (v1.16.5), PHP (v5.2.17), MySQL (v5.5.13), Windows Vista (SP2, 64bit)

Thank you for developing and supporting Semantic Forms

A quick web search reveals that this seems to be a bug for Apache running on Windows, having to do with the colon in the URL. But it appears that that error isn't a fatal one - in other words, though you're seeing that message, that's not what's actually causing the save to fail. Could it be something else, like going over the PHP memory limit? Yaron Koren 18:30, 12 July 2011 (UTC)

I appreciate your thought about the Apache bug, but I don't believe this is the issue. Here's why: When editing a page directly (ie not through a Semantic Form), the error occurs when supplying large text to a property (ArticleText is defined as - This is a property of type Has type::Text.) But when supplying the same large text to the page outside the template, it works without issue. Something fishy is occurring with the Semantic Property. See below for clarity.

{{Article
|ArticleText=...350 chars fails here...
}}
...350 chars works here...

Template:Article
[[ArticleText::{{{ArticleText|}}}]]

I have tried changing the php.ini memory_limit and .htaccess php_value memory_limit, but with no positive effect. My term of "large text" might be misleading, as it is only 350 chars, so I don't believe this is a server memory issue. Maybe this is a Semantic MediaWiki issue? Are there array bounds or other processing of properties that contain limits?

Thank you for your great assistance.

Ah - it sounds like you're having the same issue as the person in the section above this one. And yes, it sounds like a Semantic MediaWiki issue. Yaron Koren 02:20, 14 July 2011 (UTC)

Combox values with quotes

I want to have a combobox where some of the options contain quotes. However, there is a weird error. When query is run with such an option selected, on return the combobox appears with the selected option cut off. I was able to reproduce the error in the referata wiki, see here. Is there a solution? Thank you 89.139.187.127 19:50, 13 July 2011 (UTC)

Hi - that page you linked to actually seems to work for me, across various browsers. What's the specific problem you're seeing? Yaron Koren 03:06, 14 July 2011 (UTC)

Try to select to first option which contains quota, and hit Run Query. On return, the select box appears with that option selected, but all the text after the quote sign is gone.

Tried it on FF3.6, IE8.

Did you see the problem? 46.116.251.244 20:00, 17 July 2011 (UTC)

Hi - yes, I saw the issue (I forgot to actually try hitting "Run query" :) ). I think I just fixed it in SVN, and on Referata. Yaron Koren 20:45, 17 July 2011 (UTC)

My fix before wasn't very good, but I think I fixed it correctly now... Yaron Koren 00:33, 18 July 2011 (UTC)

Yep, whatever you did seems to solve it, in both browsers. Notice though that (at least for me) there is a small noticeable delay until the selected option is actually displayed in the list after the query is run. But that's a minor issue. I'll try it soon on my development wiki. Thanks!

SMW not recognizing property declarations by Semantic Forms

Rather than the content of text properties being displayed in my template it shows [[my property::my contents]] and that instance of the property isn't showing up in Special:Properties. I had edited the form after creating it with Create a class so I assumed I'd messed up the form, but the thing is that sometimes it creates a property and shows properly in the template and sometimes it doesn't. When I manually enter a property into the template it works, but otherwise there doesn't seem to be any pattern to whether it will or not. I've got one property that's only worked once, but generally I just get 3 or 4 random properties (out of 18) on each page that have this problem. Thoughts? I'm converting the content from a Word document, could there be special characters or formatting or something that it doesn't like?

Thanks,

Bteed 02:05, 16 July 2011 (UTC)

Sorry, I don't understand what you're talking about here. Could this be the issue? If not, I would try reproducing this problem on a public wiki, like http://scratchpad.referata.com. Yaron Koren 12:56, 17 July 2011 (UTC)

Looks like that was it. I didn't have any links, but there were places where something like "agree[d]" was written and using parentheses instead of square brackets seems to have fixed it. Thanks. Bteed 23:49, 17 July 2011 (UTC)

Form edit insistence on appending

Any thoughts on changing SF so that it no longer insists on appending an article thereby displacing any text that was placed on the top moving it to the bottom? Thanks    Thorncrag   21:22, 18 July 2011 (UTC)

Sorry, I don't understand - are you talking about the placement of free text vs. templates? Yaron Koren 22:20, 18 July 2011 (UTC)

Indeed that's more or less what I'm referring to, let's say you put a stub template on the top of a page that's has an attached form, the next time you form-edit it it moves the stub template to the bottom. As far as I can tell this isn't a problem with my configuration, but I concede that it may be... :-)    Thorncrag   16:18, 20 July 2011 (UTC)

|| disjunction

SMW's disjunction operator for calling individual pages in a query is ||. Obviously the vertical bar also has myriad other functions in Semantic Forms. How would I get an arraymap to produce a query like this [[Page1||Page2||Page3]] without the || confusing the parser?

I assumed it would be with nowiki, but when I use nowiki like so: {{{field|{{#arraymap:{{viewframeworks|}}|,|x|<no*wiki>||</no*wiki>}}|input type=listbox|values from category=Frameworks|size=28}}} (it didn't seem to like the nested nowiki tags) I get the text "input type=listbox|values from category=Frameworks|size=28}}}</nowiki>" where my listbox should be.

How do you correctly use the || operator in a form?

Thanks. Bteed 00:51, 20 July 2011 (UTC)

I don't know if you're asking about using #arraymap within a query, or within a form, but in both cases my guess is that it's not possible. Yaron Koren 02:31, 20 July 2011 (UTC)

Limited nested form capability

Hello. I posted a few months back a solution (code modification, here) that was adressing the kind of situation described in this post here, when one want to have fields in a template that are themselves populated by a list of templates, and want to be able to edit that using "nested multiple forms".

Since I upgraded semantic forms to the version 2.2, I had to reinsert my custom code in SF_FormPrinter.php, and I also upgraded it to have some limited "nested multiple forms" capability. Using the example situation from here here, now it is possible to have "Mayor multiple forms" and "Event multiple forms" showing inside the main "Town form", and on submission, the content is indeed registered as below.

{{Town
|town_name=new york
|town_population= 1254
|town_description= desc
|town_mayors= {{mayor|name=bob|year=1956}} {{mayor|name=ted|year=1976}}
|town_history=history facts
|town_politics=politics facts
|town_events={{event|name=halloween|attendance=4546454}} {{event|name=new year|attendance=90054}}
|town_location=coordinates
}}

The advantage is an easier way to handle the Town template. Without this fix, the most likely way to have proper multiple forms in the right spot would be to split the Town template into multiple parts, and start a new form for each part. But then wanting to move a section in the town pages would force to refactor every split template, as well as their forms. With the fix, it's possible to keep one layout template for Towns and not have to change the forms declarations for a layout change.

I set up a temporary test instance here to show how it works: Test instance (user/pass: test/testsmf)

The patched 2.2 file is on bugzilla: https://bugzilla.wikimedia.org/show_bug.cgi?id=30011

--Meng Ly 02:34, 22 July 2011 (UTC)

This new feature looks really cool - and sorry I didn't pay enough attention to it before. I responded on the Bugzilla page. Yaron Koren 18:57, 22 July 2011 (UTC)

removing detailed examples requires people to annoy developers for basic help

This information was removed in favor of a more "concise" description:

http://www.mediawiki.org/w/index.php?title=Extension:Semantic_Forms&oldid=420937#Using_Semantic_Forms_for_file_pages_and_uploads

Concise descriptions are fine if you're the developer with a thorough understanding of every detail. Lack of helpful information is why Semantic Mediawiki is so hard to get started to use, and why developers are annoyed with people "wasting their time" asking for help, unless they can pay them huge sums of money [2].

If you're not a developer, it'll take months of dedicated study to shake off that information strangle-hold, which I am doing, and am giving back in the form of easy-to utilize documentation.

The deleted information is required to make use of the "concise" description. I insist that it remain available to help people make use of the feature without being required to understand the details of it, PARTICULARLY so they don't need to beg for help just to gain a basic understanding of how to use SMW from somebody that doesn't have free time to provide it.

If it needs to be organized on sub-pages, fine, but it must not be cleanly stripped out and replaced with cryptic programmer-speak that nobody new to SMW can possibly understand or make use of.

Badon 23:00, 25 July 2011 (UTC)

It appears that even the cryptic programmer-speak is now gone too. Be prepared to fork over $100+ per hour to have somebody do this for you now. Hope you have a rich uncle... Badon 23:04, 25 July 2011 (UTC)

Am I the only one that sees a conflict of interest with developers removing documentation AND demanding payment for their help? I feel like I'm taking crazy pills! Badon 23:23, 25 July 2011 (UTC)

More info: [3], [4] Badon 23:26, 25 July 2011 (UTC)

You probably missed it, but in place of the text you added there's now a link to that same text, elsewhere - no information lost. Now stay off the crazy pills. :) Yaron Koren 23:41, 25 July 2011 (UTC)

I don't normally get into silly movies, but Zoolander cracks me up every time I see the "crazy pills scene", and I feel honored to finally have found an opportunity to use the phrase :)

Sure, there's a link, but how is anybody ever going to find it? Semantic Forms requires a large amount of documentation, and I don't think there's any way around that. Semantic data on a file is something that should be part of the core functionality, but it's currently not, and until it is, the workaround is crucial documentation, not a "tip". It should not be buried in the text as a link to some other site, it should be a significant heading to the documentation, with details.

In fact, every facet should be documented as well as the section that's now relegated as a "tip". That is starting to look like it will require subpages. No problem! I've only just begun writing... Just don't delete stuff that gets people on their feet with a task fast.

Badon 00:01, 26 July 2011 (UTC)

Displaying data from Multiple-Instance Template form entries

Hello. I am trying to display the data that is entered in a multiple-instance template form.

Currently, the user inserts three pieces of information (three properties in text fields), clicks "Add Another...", and the next three input boxes appear beneath. This works fine. When the form is saved and the user goes to edit the page again, the data is maintained.

My problem is that I want to display this data on another page. Can someone explain to me how to query this data? Thanks so much. - Alex 199.234.68.14 14:22, 26 July 2011 (UTC)

Instead of storing the data via Semantic MediaWiki tags, you should store it with the #set_internal function, defined in the Semantic Internal Objects extension. Yaron Koren 19:28, 26 July 2011 (UTC)

Thanks for your reply, Yaron. You have done amazing work with this extension. Just so I understand, let's say my form currently looks like this:

{{{for template|Opinion|label=Opinions for this item|multiple}}}
'''Topic:''' {{{field|topic}}}
'''Position:''' {{{field|position}}}
'''Stance:''' {{{field|stance}}}
{{{end template}}}

So now I should use the Semantic Internal Objects extension. I'm having trouble integrating the two. Should I write something like this:

{{{for template|Opinion|label=Opinions for this item|multiple}}}
{{#set_internal:Opinion
|topic={{{field|topic}}}
|position={{{field|position}}}
|stance={{{field|stance}}}
}}
{{{end template}}}

Apologies for my confusion. Thanks. --Alex 199.234.68.14 13:38, 27 July 2011 (UTC)

Hi, thanks! No, I'm talking about modifying the actual template - the page in the "Template:" namespace - not the form definition. It should use #set_internal, instead of [[a::b]], etc. Yaron Koren 14:32, 27 July 2011 (UTC)

That makes more sense! That will give me a good starting point for working through this. Many thanks. --Alex 199.234.68.14 14:38, 27 July 2011 (UTC)

popup not working

I just noticed that the "popup" feature is no longer working. I was trying to put up an example on scratchpad referata, but it keeps telling me that I am spamming it. --Dgennaro 14:43, 26 July 2011 (UTC)

I took out that anti-spam thing - it was causing a bunch of problems - so now everything should work again. Yaron Koren 19:19, 26 July 2011 (UTC)

It is the exhibit result format that is screwing it up. --Dgennaro 19:38, 28 July 2011 (UTC)

Sorry, I don't understand. What does that have to do with spam? Yaron Koren 23:55, 28 July 2011 (UTC)

I was trying to test and/or make a sample of the popup issue on scratchpad referata, but it was telling me that I was spam. After you removed the spam proplem I figured out it was an issue that was being caused by using the exhibit result format. Sorry I was not more clear on that. I will post any additional findings. Thanks again. --Dgennaro 13:41, 1 August 2011 (UTC)

Creating pages automatically in a given namespace

I am using the "Creates pages with form" special property to automatically make pages from redlinked properties. These pages are to contain a query listing the pages mentioning the property value. The basic functionality of it works, but each page needs to be created in the "Staff:" namespace. Instead they are being created in the Main namespace, even though the info tag in the form is setting the page name to be in "Staff:". Is there some way to create them in the custom namespace instead? Here is the relevant part of the template and form:

RolesTest template:

<includeonly>

==Pages with {{SUBPAGENAME}} Type==
{{#ask: [[refers to role test::{{SUBPAGENAME}}]]
|?refers to role test
}}

</includeonly>

and the RolesTest form:

<includeonly>
{{{info | page name=Staff:RolesTest/<RolesTest[refers to role test]>}}}

<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
{{{for template|RolesTest}}}
{| class="formtable"
|}
{{{end template}}}

The "refers to role test" property contains [[Creates pages with form::RolesTest]].

Thanks, Marchesoni 16:10, 27 July 2011 (UTC)

The way I have gotten around this is to create a second property. You can create a "refers to role test page" and when you are entering that value via the first template you can enter the "Staff" namespace before the value and just hide that entry. Example: [[refers to role test page::Staff:{{{value from field|}}}| ]]. Move the [[Creates pages with form::RolesTest]] to the new property page. I hope this helps. --Dgennaro 16:20, 27 July 2011 (UTC)

Embedding Special:RunQuery in pages

No question this time round, but a tip which may possibly be worth adding to the documentation about "Querying data".

If you need to embed a query form within a page, rather than merely link to one, all you need to do is to write curly brackets as opposed to square ones. For example, if you're using a form called Form:Recipe for a template called Template:Recipe, then presumably

{{Special:RunQuery/Recipe}}

should transclude the contents of the special page. It worked for me at any rate. Cavila 14:22, 28 July 2011 (UTC)

Constructing the form name from multiple pieces of user-entered data?

Is is possible to have the user enter several pieces of info that can be validated separately, then create a form by concatenating those pieces together? For example, let's consider creating a form to record meeting minutes which could be use by any number of teams within an organization. Data items to record might be:

• team
• date
• meeting subject
• scribe
• meeting notes

I'd like to create the form name by concatenating the first 3 data items together, then have "scribe" and "meeting notes" fields entered via form. How do I get these first 3 items from the user in advance of calling the form to create the page?

Many thanks. -Jeff

Just to clarify - when you say "form name" you're really talking about the page name, i.e. the name of the page created via the form, right? Yaron Koren 02:49, 29 July 2011 (UTC)

Apologies... Yes. I want to create a page name from constituent parts, then have that page created by a form. -JK

This might be helpful, if I understood the question correctly. Yaron Koren 03:51, 31 July 2011 (UTC)

Repeating semantic data not updating until Template is resaved

Hello, Yaron and all. I am having a serious problem trying to integrate Semantic Forms and the Internal Objects extension. I have a large form which includes a multiple instance template, adding groups of data that contain 1 hidden field and 4 editable fields.

...
... some form items ...
...
{{{for template|WorshipServiceHours|multiple|add button text=Add More Hours}}}
{|
| {{{field|ForWhatChurch|property=ForWhatChurch|input type=string|default={{BASEPAGENAME}}|hidden}}}
{{{field|ServiceHoursName|property=ServiceHoursName|input type=dropdown|values=Liturgy,Mass,Worship Service}}}
{{{field|ServiceHoursDay|property=ServiceHoursDay|input type=dropdown|values=Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Daily|default=Sunday}}}
{{{field|ServiceHoursStart|property=ServiceHoursStart|input type=timepicker|size=7|disable input field|interval=10}}} to
{{{field|ServiceHoursEnd|property=ServiceHoursEnd|input type=timepicker|size=7|disable input field|interval=10}}}
|}
{{{end template}}}
|}
...
... other form items ...
...

I have a template named WorshipServiceHours that looks like this:

{{#set_internal:WorshipServiceHours
|ServiceHoursName={{{ServiceHoursName}}}
|ServiceHoursDay={{{ServiceHoursDay}}}
|ServiceHoursStart={{{ServiceHoursStart}}}
|ServiceHoursEnd={{{ServiceHoursEnd}}}
|ForWhatChurch={{{ForWhatChurch}}}
}}

When the form is saved, this ask statement then displays the repeating data inside this page template:

...
... template stuff, displaying other form items for a given page
...
{{#ask:[[WorshipServiceHours::+]] [[ForWhatChurch::{{PAGENAME}}]]
| mainlabel=-
| ?ServiceHoursDay
| ?ServiceHoursStart
| ?ServiceHoursEnd
| ?ServiceHoursName
| ?ForWhatChurch
| format=template
| link=none
| template=InfoBoxHoursDisplay
}}
... more template stuff

(I have also built the template InfoBoxHoursDisplay which cleanly displays this repeating data.) The problem is that when a user enters data into the form and saves, the data does not display on the generated page until I go back and re-save (not necessarily modify, just re-save) the page template. Obviously I am doing something seriously wrong. Is there an alternative to specifying ForWhatChurch::PAGENAME in my ask statement? Is there another way to display repeating semantic data that only matches the particular page in question? Thanks so much for your help.

As an added issue, the Semantic Forms Inputs extension doesn't allow me to click on the timepicker JavaScript when I try to Edit with Form. The first time the timepicker inputs are added via "Add Another" they work, just not on editing the form. The JavaScript error reads:

document.getElementById(this.id.replace("_button", "_tp_show")) is null

Thanks so much! --Blicarea 03:10, 30 July 2011 (UTC)

Hi - could this be the issue? Or does it definitely require a resave? As for the Semantic Forms Inputs problem - that's a separate extension; you should ask over there. Yaron Koren 04:01, 31 July 2011 (UTC)

Thank you!! Adding

$wgEnableParserCache = false;
$wgCachePages = false;

has fixed it! --Blicarea 13:02, 31 July 2011 (UTC)