Extension talk:Page Forms/Archive November 2010

New Pages created with forms not adding to article total?

When I create a new page it adds it to the right category but it does not add

[[Category:Category Name]]

to the end of the page so it will not add it to the article total, how do I get it to add this to each page?

Redeye 23:51, 3 November 2010 (UTC)Reply[reply]

Just add that in to the template (if I understood the question correctly). Yaron Koren 02:53, 4 November 2010 (UTC)Reply[reply]

It seems like the template already does that when you set it up but although it adds the page to the Category it does not add it to the content count? ---Redeye 05:17, 4 November 2010 (UTC)Reply[reply]

I don't know - that's weird. Yaron Koren 15:00, 7 November 2010 (UTC)Reply[reply]

Ive got the same problem on 2 installs of SF now, Dont surppose anyone knows how to fix this? the only way I can get the amout to update is to go to each page created and edit not with a form and save the page, but while at the moment the site is not live to Jo Public I can do that, once it goes live its going to be hard to do that to 100 pages a day Redeye 23:26, 9 November 2010 (UTC)Reply[reply]

That seems very odd - the saving mechanism is basically the same whether the form is used or not. SF just adds an intermediate step. Yaron Koren 00:42, 10 November 2010 (UTC)Reply[reply]

Tell me about it! It makes no sense. Is anyone else having this issue? is there a script I could run to fix the problem or something? Redeye 09:03, 10 November 2010 (UTC)Reply[reply]

Do you use the Templates which contains your Category Tag in the Pages where the Category is missing? Sounds a bit like a Template that only gets added by the Form and not without it. You could although try to rebuild you semantic index, which will clean the cache for all pages.SBachenberg 14:32, 11 November 2010 (UTC)Reply[reply]

I only use forms in these categorys, the categorys are there, I make them before testing the form. How do you rebuild the index? Redeye 01:23, 13 November 2010 (UTC)Reply[reply]

I've just updated to the latest version of From and tried to use the "default" setting on the form to add the category. That makes it add to the article list. Redeye 18:23, 13 November 2010 (UTC)Reply[reply]


  • How about using it? Is there a possibility to use it "On Mouse over" instead of "On Mouse Click"? --Martin 16:02, 4 November 2010 (UTC)Reply[reply]
Not at the moment, I don't think. If someone were to create such a thing, that would be cool - the current #info function is actually part of SMW, not SF. Yaron Koren 15:00, 7 November 2010 (UTC)Reply[reply]

Is "show on select" working in v2.0.3?

I just upgraded to Semantic Forms 2.0.3, and now I'm getting javascript errors (Object doesn't support this property of method) whenever I use "show on select". Looking for a solution, I visited the Referata Scratchpad here (created by Daniel5000 and discussed earlier in this forum), and the same issue is happening. (I'm using IE7 and Firefox 3.6.8.) --Hermhut 14:33, 5 November 2010 (UTC)Reply[reply]

The issue isn't browser dependent. It is broken in all browers (chrome included). Something is wrong with the JScripts, I think. Needless to say, it's not functioning for me either.
--mlGamble 21:53, 5 November 2010 (UTC)
Hi - thanks to both of you for pointing this out. I don't know how I let such a major error slip past me. I just fixed the problem in SVN, and it'll be in the next version, 2.0.4, which I hope to release soon. Yaron Koren 14:55, 7 November 2010 (UTC)Reply[reply]
I just installed the latest SVN files and now the "show on select" feature works, but it breaks FancyBox (if "uploadable" and "show on select" are used on the same form). Also, the "Add another" functionality is now flaky and sometimes doesn't work on pages with "show on select". I guess I'll just stick with v2.0.2 until v2.0.4 is released. Thanks. --Hermhut 16:05, 8 November 2010 (UTC)Reply[reply]
Hi Hermhut - I couldn't duplicate this, with either MW 1.16 or MW 1.17. What version of MediaWiki are you using? And could you try to duplicate the issue on a public wiki? http://scratchpad.referata.com is one possibility - it uses MW 1.16. Yaron Koren 21:01, 8 November 2010 (UTC)Reply[reply]
I created the Form:Fancy on the public wiki. You'll notice that "Add another" does not work. Edit the page, removing "show on select", and it works fine. If you can get that working, then you'll want to make sure "uploadable" works. (It doesn't work if you edit a page already created with multiple uploads, and that page contains show on select.) Thanks. --Hermhut 23:56, 8 November 2010 (UTC)Reply[reply]
Hi, thanks for reproducing that. The problem happened because you had a semicolon at the end of your "show on select" - basically the same exact problem as this; I thought I had fixed it, but apparently not completely. The problem should be fixed now, in the code in SVN. Yaron Koren 18:02, 9 November 2010 (UTC)Reply[reply]
Thanks, Yaron, it appears to be working now. --Hermhut 20:08, 9 November 2010 (UTC)Reply[reply]

2.0.3 not working!

MediaWiki internal error.

Exception caught inside exception handler

Thats the error I get when I enable the latest version of forms. I was running 2.0.1 fine but when I installed the bundle to a new website it put 2.0.3 on and my wiki is dead lol. Please help Redeye 11:40, 7 November 2010 (UTC)Reply[reply]

Hi - this could be anything. Please add the following to LocalSettings.php, so you can see the actual error: "$wgShowExceptionDetails = true;". Yaron Koren 14:59, 7 November 2010 (UTC)Reply[reply]


Hi everyone! I'm wodering if there is a way to 'feed' a combobox by means of a semantic query (e.g #ask). Or maybe to add a semantic form imput format similar to a table resulting from a #ask query but with a checkbox associated. I hope someone can give some enlightenment about this matter. Carlos Sa 14:49, 17 December 2010 (UTC)Reply[reply]

Can you guys help me and tell me why the combos from "Funcionamento" that means "Working hours" is not working properly?


I mean, it should be reading values I added in the property...


Your propertys like:
 [[Funcionamento:{{{Segunda_Inicio}}}]] as [[Funcionamento:{{{Segunda_Fim}}}]] h
should be changed to something that work (I did that for you):
[[Funcionamento::{{{Segunda_Inicio}}}]] as [[Funcionamento::{{{Segunda_Fim}}}]] h
but you should add a "|" to the end of your parameters like:
[[Funcionamento::{{{Segunda_Inicio|}}}]] as [[Funcionamento::{{{Segunda_Fim|}}}]] h
because if the parameters are Empty, you will get some errors. SBachenberg 14:49, 11 November 2010 (UTC)Reply[reply]

Styling the "Free Text" Textarea

Currently the default textarea has its width set to "auto" as applied by SemanticForms.css.

textarea.createboxInput {
	width: auto;
textarea.mandatoryField {
	width: auto;

In IE8 this results in a free text area with (estimated) 50% width. When applying my own class .formtextarea as described in your extension page using "class=formtextarea" the width setting cannot be overwritten. Is there a way to change this behaviour without altering your original CSS file to something like width:90%? I guess the "auto"-setting is there for good reason. My only solution thus far was "min-width 90%" which is not optimal and may cause problems otherwise. (Mike)

I'm not sure if I understand the full question, but you can override any extension's CSS by putting new CSS in the page "MediaWiki:Common.css". Yaron Koren 00:02, 13 November 2010 (UTC)Reply[reply]

Calling the WikiEditorModule within a Form (Free Text Area)

Is there a possibility to call the "WikiEditorModules" (UsabilityInitiative) within a form (i.e the Free Text Area)? It works in normal edits but doesn't show up within the form.

Not at the moment. Yaron Koren 00:01, 13 November 2010 (UTC)Reply[reply]

More than one default form is defined for this page

Can you guys help me resolving this issue? "More than one default form is defined for this page."

Sounds like you have assigned multiple forms to this page in either the page itself, the namespace or the category the page belongs to. You should use one "Has default form" declaration per page maximum. If you need more than one form for a page, use the "Has alternate form" property. (MIKE)
I think something else is happening... http://www.w.com.br/index.php?title=P%C3%A3o_e_Companhia_(Copacabana)&action=formedit
Hi - your wiki looks great! This might be a bug in Semantic Forms, possibly related to the fact that the wiki is in a non-English language. I would upgrade your wiki to the latest version of SF, and see if the problem is still there - if it is, please let me know, and I'll try to reproduce it locally. Yaron Koren 02:31, 17 November 2010 (UTC)Reply[reply]
Thanks Yaron! About the problem, just upgraded and still have the same issue. Hope you can help me. Thanks!
This was indeed a bug - I think I just fixed it in SVN. You can either re-get the code from SVN, or just apply this simple fix directly to your code. Yaron Koren 23:47, 19 November 2010 (UTC)Reply[reply]
Yes!!!!!!!!!!!!!! Issue solved! Thanks Yaron! Regards, Edgard!
Cool - thanks for letting me know about it. Yaron Koren 06:23, 21 November 2010 (UTC)Reply[reply]

Feature Request: Special:RunQuery as part of a Wikipage + a Bug

Hi Yaron, is it possible to have a "Special:RunQuery"-Form in an existing Wikipage ? Like a part of the Page where you can query things. That means that this Page can have a nice url / title, better than "Run query: Project search".

There although seams to be an error if you place a Fromlink in the Form used by Special:RunQuery. The RunQuery Page isn't able to search anything, because the "Run query" Button does nothing. SBachenberg 14:27, 11 November 2010 (UTC)Reply[reply]

Hi - actually, this exists already: you can put "{{RunQuery/form name}}" in any page, and it should display the query form there. Also, as of v2.0.4 you can manually set the title, using the "query title=" parameter for {{{info}}}. I don't know about that bug, though - could you reproduce it on a public wiki?` Yaron Koren 00:06, 13 November 2010 (UTC)Reply[reply]
HI Yaron, "{{RunQuery/form name}}" doesnt work :-( Maybe you could add somelines to the Manual about that? SBachenberg 12:37, 15 November 2010 (UTC)Reply[reply]
I got the Answer its "{{Special:RunQuery/form name}}" SBachenberg 15:43, 15 November 2010 (UTC)Reply[reply]
Following up on what we talked about in IRC, SBachenberg, the correct format for embedding a RunQuery form is "{{Special:RunQuery/form name}}". Misty De Meo 15:43, 15 November 2010 (UTC)Reply[reply]
Oh yeah, that makes more sense... oops. :) Yaron Koren 06:58, 17 November 2010 (UTC)Reply[reply]

Show on select and mandatory fields

Correct me if I'm wrong, but I thought that (in older versions of Semantic Forms) you could have mandatory fields within a hidden "show on select" div, and if they were empty on page save, it would be okay. If so, this is no longer working. If not, then my bad (but I would really like this feature!). --Hermhut 22:01, 11 November 2010 (UTC)Reply[reply]

Hi - actually, it's the other way around: in older versions, this didn't work, but in the latest version, 2.0.4, it does, at least in theory. Is this not working for you with 2.0.4? If so, could you try to replicate the problem on a public wiki, like scratchpad.referata.com? Yaron Koren 00:00, 13 November 2010 (UTC)Reply[reply]

Suggestion: Add further examples

I've recently asked about building "dynamic" Templates according to a certain property selection (i.e. "PageStatus) done in forms. I found absolutely no good example, so i made something of my own. I lack programming skills but i think it does the job. Wanted to share my results, maybe it's useful for the Manual of "Semantic Forms".

Example 1: If Case - Showing a "Draftbox-Template" if a certain Property value (DraftStatus) is true:

{{#ifeq: {{#show: {{PAGENAME}} | ?PageStatus}} | Draft | {{DraftBox}}| }}

Example 2: Switch Case - Based on example 1 this can also be used for several options instead of checking a string. Here's a Switch Case for a given selection of properties, chosen by Pulldown. In Result it shows an image at the desired position within your template depending on the "Type of Information" Property Value.

{{#switch: {{#show: {{PAGENAME}} | ?Type of Information}}
 | Concept = [[File:Questionmark_48.png]]
 | Manual = [[File:Navigate_48.png]]
 | General Information = [[File:Info.png]]
 | #default = [[File:Info.png]]

Both examples are used within a template that belongs to an "Article" form. Hope this is a somewhat useful example. (Mike)

Request: some examples for #forminput

Same issue as above: i'm lacking a usage example on how to properly create forms for adding new pages to the wiki. All parameters work but the query part used for subpages is hardly understandable on its own.

{{#forminput:form=Article|size=50|default value=YourToolName|button text=Suggest a new Tool|autocomplete on category=Tools|super page=Tools/}}
  1. the super page=Tools/ part is wrong here. What should be entered to add pages to a subpage as in: Tools/YourToolName or Tools/<anynameyouprovide>?
  2. is there a way to automatically (silently) add new pages to a category without the Category-Tag showing up in the default Wikitext? I want users to add pages as simple as possible, preferrably without any categories showing up at all. I just use Categories for automatic "Has default Form" assignment and for sorting / menu purposes.
-> 1. Try ... super page=Tools}} without the "/" at the end.
-> 2. An Easy Way to add a Page to Category is just make a Form, which normally uses a Template. In this Template add something like that:
SBachenberg 16:29, 12 November 2010 (UTC)Reply[reply]
1. This was the first thing i've tried it doesn't work. |super page=tools| just results in the page being posted to the Wiki Main Index.php/Thenewpage. Here's the full Code in its recent most state: {{#forminput:form=Article|size=50|default value=YourToolName|button text=Suggest a new Tool|autocomplete on category=Tools|super page=Tools}}
2. This is exactly the current "easy" way as i'm doing things atm. However - as stated above - i want to prevent users from getting easy access to the categories. A neat way would be either to hide the Category completely or provide a Form that allows a selection of certain Categories and assigns the page accordingly. This would also prevent multi-category (or no) assignment of pages. (MIKE)
Update - The text in the manual was misleading me. I already assumed something was wrong in the query string. For me to make this work i had to type "|query string=super_page=Tools}} instead of just "super_page=Tools". Now i have the problem that the "autocomplete on category" suggestions already show the subpage as well. If people would use the suggestion this could result in double-subpages generated. Is there a way to "strip" the subpages from the search field and just show the final article name?

Using multiple multiple instance templates with HeaderTabs

I have a form with a number of tabs. I can get multiple instance templates working in the last tab (by placing the headertabs tag in the article itself, not the template). I'm wondering if it is possible to put multiple instance templates in other tabs, and hence have multiple multiple instance templates, each on a different tab? - Borofkin 03:33, 20 October 2010 (UTC)Reply[reply]

Definitely. You shouldn't put any of the Header Tabs stuff directly in the article - instead, you should create small "header" and "footer" templates, with no arguments, that are responsible for just those little snippets of wiki-text, and add those to the form. Yaron Koren 12:31, 20 October 2010 (UTC)Reply[reply]
At the moment the contents of most tabs are in one template. Should I split each tab into a template of its own? Is there a publically available example of a setup like this? - Borofkin 22:16, 20 October 2010 (UTC)Reply[reply]
Should I be using partial forms? - Borofkin 22:45, 20 October 2010 (UTC)Reply[reply]
You don't need to split each tab into its own template - only where it's necessary, due to multiple-instance templates. I can't think of a public example. Yaron Koren
Okay, I've had a crack at this. I have a master template "Project", that uses two multiple instance templates: "Milestone" and "Participant", which are both on separate tabs. The problem I have is that after editing a page, the multiple instance ("Milestone" and "participant") templates are always placed immediately after the master template, pushing the Headertabs templates to the bottom. The result is that the multiple instance templates all appear on the first tab. I can edit the source of the page and manually insert the tab header templates, and it then appears correctly, but if I edit again using the form the same thing happens, i.e. the tab headers are pushed to the bottom. - Borofkin 00:22, 15 November 2010 (UTC)Reply[reply]
Hi - what you should have is another template, maybe called "Participants header", between "Milestone" and "Participants", that just contains the tab header. You can just add it in to the form, with nothing between "for template" and "end template". Yaron Koren 03:18, 15 November 2010 (UTC)Reply[reply]
Hi Yaron... this works! I was using a template for the headertabs headers already, but I wasn't using the {{{for template}}} stuff... I don't really understand SF to be honest, I just cut-and-paste. :-) However, now when I edit, the multiple instance templates are not in their tabs. Should the headertabs template be referred to twice in the form? i.e. {{{for template|participant header}}} and also {{participant header}} ?

No, just once, with "for template". If you want the form to also have a tab header in that same location, just put the actual header in there, above the "participant header" call. Yaron Koren 21:33, 15 November 2010 (UTC)Reply[reply]

Fields on first tab disappearing

I have a very bizarre problem. I have a form with data from a single template spread across multiple headertabs. If I edit a field on the first tab, it works fine. If I edit a field on any of the other tabs, all of the template parameters for the fields on the first tab disappear -- not blanked out, but actually removed from the resulting template. I can't see any obvious problem with the template, field or the article. MW 1.15.1 SMW 1.5.3 SF 2.0.4. - Borofkin 05:48, 17 November 2010 (UTC)Reply[reply]

I have no idea - could you try to replicate the problem on a public wiki like scratchpad.referata.com, and link to it here? Yaron Koren 06:56, 17 November 2010 (UTC)Reply[reply]
Hi Yaron... it's such a bizarre problem that I doubt very much that I'll be able to replicate it. I'll give it a go, but. - Borofkin 21:55, 17 November 2010 (UTC)Reply[reply]
Hi - you actually uncovered a major bug in SF 2.0.4, that's actually pretty easy to replicate... now I've seen it too. I'll try to fix it soon. Yaron Koren 15:00, 25 November 2010 (UTC)Reply[reply]

Restricted Fields not Editable by WikiSysOp

Hi Yaron, I have restricted fields in my Form and cant edit them with my Wikisysop account. What I'm doing wrong ? Wikisysop is in the group Sysops and Bureaucrats. I although tried it with a new User with Sysop rights but nothing worked. SBachenberg 08:47, 18 November 2010 (UTC)Reply[reply]

Hi - by "nothing worked", do you mean that the new sysop couldn't edit that field either? That's weird; I just tested it, and it works for me. What versions of MW, SMW and SF are you using? Yaron Koren 19:14, 19 November 2010 (UTC)Reply[reply]
Right thats realy weird and I have no idea whats the Problem :-(
My System:
MediaWiki 	1.16.0
PHP 	5.3.2 (apache2handler)
MySQL 	5.1.48-community

Admin Links (Version 0.1.2)
Replace Text (Version 0.8) 	(r76516)	
Semantic Forms (Version 2.0.4) 	(r76878)	
SphinxSearch (Version 0.7.2)	
Header Tabs (Version 0.6.6)	
ParserFunctions (Version 1.1.1)	
Semantic MediaWiki (Version 	(r76945)	
Variables (Version 1.3)
Abuse Filter 	
Semantic Result Formats (Version 1.5.0)
SimpleAntiSpam (Version 1.0)
Title Blacklist (Version 1.4.2)	
UsabilityInitiative (Version 0.1.1) 	(r72107)
Validator (Version 0.3.3)
Vector (Version 0.2.0) 	(r72107)
WikiEditor (Version 0.2.0) 	(r72107)

SBachenberg 14:17, 24 November 2010 (UTC)Reply[reply]

I found my own error, the Problem was that my Userrights got set after the SMF Extension. Now everything works fine. SBachenberg 10:34, 8 December 2010 (UTC)Reply[reply]

Free text field?

Hello. I have a field called "Info" where a user can enter a bunch of info about something. I would like this field to have the same look as the free text field (that being the user could use the WYSIWYG editor). OR is there anyway to change the name of the free text field and have that text placed somewhere in the template? thanks

Hi - unfortunately, there's no way to have a WYSIWYG editor on template fields. You could have the "free text" field be just another template field, but then it won't have a WYSIWYG editor on it either. Yaron Koren 22:50, 19 November 2010 (UTC)Reply[reply]
Hmm. So I can map the free text field to a position in a template? How? In the form I would have this for the free text:

{{{standard input|free text|rows=10}}} so then in the template would I put this or how would I tell it where to go?

{{{free text}}}

So there is no hope of this becoming possible in future versions of the extensions? Smile Lee 12:35, 21 December 2010 (UTC)Reply[reply]

Odd IE8 related Form Bugs

I've experienced some very odd bugs that only happen in IE8 but not Firefox. Unfortunately IE8 is a must-have at my company :(

Here's a list of issues:

  • The combobox dropdown buttons are not vertically aligned with the input field but shifted upwards a bit (a good 10px). This results in the whole form line being too high. Restricting the line height of the table row which contains the form part has no visible effect. The Dropdown-Button looks normal in Firefox though.
  • With "Input Type=Textarea" i experience a weird cursor behaviour. It is not possible to step trough the test using CTRL+Movement keys and my whole text gets highlighted instead. All i can do is append text. Once again, everything seems to act normal in Firefox.
Hi - I just tried IE8 (on Windows) on this page, which has both a combobox and a textarea, and I couldn't observe either of the problems you're talking about. Do you get them on that page? If so, what OS are you using? If not, what versions of MW, SMW and SF, and what skin, does your wiki have? Yaron Koren 23:04, 19 November 2010 (UTC)Reply[reply]
Really odd: Updating to SF 2.0.4 fixed the Combobox-problem in IE8. On your link it still remains, mailed you a screenshot. I could swear that last friday updating brought no change but made my "edit with form" buttons disappear - now everything in that regard is fine. However the second problem with the textarea behaviour remains. My textarea code is as follows: {{{field|UserDescription|input type=textarea|rows=4|size=200|maxlength=500}}}
Cursor always jumps to the text end in IE8, rendering edits and text highlighting impossible. Firefox seems fine. Using MW 1.16 (Vector Skin), SMW 1.5.3 and SF 2.0.4
Do you see both problems on the Discourse DB link, or just the first one? And what OS are you using? Yaron Koren 14:11, 22 November 2010 (UTC)Reply[reply]
The form acts normal on the Discourse DB link. The button visuals are shifted like in the screenshot i've sent you. On my local development server (XAMPP) the button looks normal now but the form behaviour is weird also on my colleagues computers. (IE 8.0.6001, WinXP SP3) Mike
Indeed - you found a bug in the handling of "maxlength" within textareas in IE. I just fixed the problem in SVN, and it'll go into the next release. I still don't know about the combobox thing - it would be easier if I could reproduce it myself, obviously. Yaron Koren 06:04, 24 November 2010 (UTC)Reply[reply]
Ah, awesome that i could be of any help. I'll keep you informed about any further potential bugs i stumble upon since this extension is really great so far. :) The combobox issue is gone since the update to SF 2.0.4. I don't know what changed but it could relate to the typical CSS issues that IE has. --(Mike) 07:36, 24 November 2010 (UTC)

Linking of Properties / Forms

Can someone tell me how it is possible to get the properties that have been provided by use of multiple-instance "sub"forms? I have created user pages where user can specify their Semantic data. Then i added one or multiple project involvments as sub-forms with their corresponding project-properties. The templates show correctly for each added project on an individual userpage.

However, when i "Browse Properties" for that user i don't see any of the project-related properties assigned to that user. Now i'm trying to associate users with their corresponding projects and their knowledge level in a single query but it doesn't work. Something in the terms of:

= User / Project Relations =
{{#ask: [[User:+]]
| ?ProjectName
| ?UserExperience
| format=table

The query is understoof but only lists the user and leaves the other cells empty.

You should use the Semantic Internal Objects extension to store the data. Yaron Koren 18:55, 19 November 2010 (UTC)Reply[reply]
Ah so i edit the form to add a semantic link between the additional "mulitple" form properties and the actual userpage. Thank you - and on this behalf i might also thank you for the ongoing support on this page. :) --Fennyface 11:30, 23 November 2010 (UTC) (Mike)Reply[reply]


When you use the 'has alternate form' is it possible to change the text in the Edit with Form page? If so, does anyone know where? Thanks!

Yes, definitely - same as with "Has default form", it's defined in the form definition itself, via "create title=". Yaron Koren 15:07, 24 November 2010 (UTC)Reply[reply]

Reordering multiple templates

Is it possible to reorder multiple templates using the form, or is it necessary to edit source? - Borofkin 03:47, 22 November 2010 (UTC)Reply[reply]

Unfortunately, no - you have to do it via the source text. Yaron Koren 04:40, 22 November 2010 (UTC)Reply[reply]

Setting name of uploadable files

Hello. I used the upload filename= <page name> in the form. However once the file is selected it automatically updates it to whatever the image being uploaded is. Can I make it so it stays as the value I have set it?

Ah, indeed... it looks like this was never working for MW 1.16 and higher. Thanks for letting me know about that bug. I just checked in a fix into SVN, so it works now in the latest version. By the way, the parameter is actually "default filename=", not "upload filename=" (as was incorrectly written in one place in the documentation); but you probably figured that out. Yaron Koren 05:42, 29 November 2010 (UTC)Reply[reply]
Awesome thanks, it works now. However another question: Since it sets the default filename to whatever you tell it.. the file name does not include .jpg or .png or anything. So I am getting an error that says "File extension does not match MIME type." How to resolve?
That's indeed an inherent problem - there's no programmatic fix for it, that I know of. If you don't know the file extension ahead of time, you'll have to just put in instructions for users to add it in themselves. Yaron Koren 14:04, 1 December 2010 (UTC)Reply[reply]

SF 2.0+ & GuMaxDD skin compatibility

It has been shown that in some skins (such as GuMax) some features (such as autocomplete) do not work in SF 2.0+ since the extension no longer uses YUI. The issue here is that 2 references to jQuery are inadvertently created. it has been recommended to remove the line in the skin's PHP file that includes the jQuery library reference. However, when using GuMaxDD (GuMax skin with dropdown menu bar), this will invariably break dropdown menus in all pages except for form pages. Instead (based on my experience), you would want to remove the jquery include from the extension, not the skin. This would be appropriate for wiki's that do not encourage or allow users to change skins in their user preferences. To do so, you would want to comment out the following clause (lines 202-206) in SF 2.0.4):

if ( method_exists( 'OutputPage', 'includeJQuery' ) ) { $wgOut->includeJQuery(); } else { $scripts[] = "$sfgScriptPath/libs/jquery-1.4.2.min.js"; }

You may also want to move the jQuery include line in the skin before any other jQuery plugin includes/function calls and after all CSS references. Since there may very well be a number of skins that rely on jQuery, perhaps there could be a way to store a blacklist of skins as a global variable which the extension can check before including jQuery. --Mtyeh411 21:21, 23 November 2010 (UTC)Reply[reply]

Hi - removing the jQuery call from SF itself sounds like good advice; thanks. I've really only heard of two skins that include jQuery: GuMax (or the GuMax "family" of skins), and OntoSkin. And OntoSkin comes with a package that includes its own (older) version of SF, so it's really only GuMax that's the issue. But I'll update the documentation. Yaron Koren 15:15, 24 November 2010 (UTC)Reply[reply]

Manual: Chapter for Editor help within forms

As a suggestion i'd like to propose adding a chapter in the manual describing what kind of help can be provided in terms of Wikipage editing usability. It doesn't have to be WYSIWYG, but things like the EditTools below this page would already help a lot. The #info tag itself is great when using the forms but on the con-side the editing help in the free-text area is lost. This greatly diminishes ease of use and already made a lot of my co-workers hesitate using SF and MW. Any solutions to that? On a related note - all i could think of at the moment would using forms to render the complete article structure, i.e. using multiple sub-forms to add further article paragraphs, images and categories. (Mike)

I don't know what exactly you're using SF for, but I doubt SF will be able to handle that kind of layout stuff any time soon. Maybe some of the usability initiative functionality would be a better fit for what you want. Yaron Koren 17:57, 24 November 2010 (UTC)Reply[reply]

Hide no subcategories with input type category

To hide the no subcategories line when using input type category edit MediaWiki:Categorytree-no-subcategories. Creating an empty page is not possible like mentioned in the archive. Creating the page with <nowiki></nowiki> works fine. --Planetenxin 14:16, 25 November 2010 (UTC)Reply[reply]

Lingering pointers after article deletion

The specific problem is within a form I have. In this form is a combobox with the values equivalent to the query {{#ask: [[:Concept:+]] }}. So, this field has the values of the names of all the concepts in my wiki. Great. I add a concept and it adds it to the wikidb; however, I remove a concept and it still exists in the query. This is the problem, and no this isn't caching. The solution is to go into the data base and go through a process ending with DELETE FROM smw_ids WHERE smw_id=specific id. This is tasking and tedious whenever someone makes a mistake. mlGamble

What's the tag you have to define the combobox? Yaron Koren 14:43, 25 November 2010 (UTC)Reply[reply]
In the form I have, effectively, the following:
{{field| specification | values={{#ask: [[:Concept:+]]|link=none}} | show on select={{generate div select}} }}
where the inline query has already been evaluated, and {{generate div select}} does something unrelated
Perhaps I don't understand your usage of the term 'tag' {{#tag: [...] }} or <*tag-name*> </*tag-name>, per MW definition
Neither of those appear within the form for any purpose other than to call includeonly
- mlGamble 18:46, 25 November 2010 (UTC)Reply[reply]
You answered my question - that's what I meant. So I assume you meant "dropdown", not "combobox". I don't actually know how you got this working, but in any case, you could have a true combobox, by having "|input type=combobox|autocomplete on namespace=Concept" in there instead. Unfortunately, there's no "values from namespace=" - that's coming fairly soon, though. Yaron Koren 04:10, 26 November 2010 (UTC)Reply[reply]
Pardon me. Dropbox is what I meant, then. And, it works through transclusion - but could equally accomplished through a concept. However, back to my issue. When an article is created, you insert it into the database, to be specific to what I've found, in the table swm_ids; however, when it's deleted this remains in swm_id. The effect is... I query {{#ask: [[:Concept:+]]}} and I get all the concepts, both existing and deleted.
-User:mlGamble 14:17, 26 November 2010 (UTC)Reply[reply]
Well, that sounds like a Semantic MediaWiki issue, then, not a Semantic Forms one. Yaron Koren 20:28, 26 November 2010 (UTC)Reply[reply]

Using #if function inside the forms Pagename parameter?

Is this possible? I want to customize the page name a form creates depending on if certain fields have values. Every time i try to use the #if function inside it give an error. Any ideas?

Unfortunately, I don't think this is possible via the form - I think the only way to do it is to create a small MediaWiki extension that hooks into the Semantic Forms code to do a custom name calculation. Yaron Koren 04:29, 29 November 2010 (UTC)Reply[reply]
Thanks. It says the following on the semantic form page: The "page name=" value gets parsed by the MediaWiki parser, so you can also add parser functions, pre-defined variables, etc. into the value. This makes it seem like I should be able to use #if. Or is this wrong?
Ah, I forgot about that... indeed, that looks like a bug, in either the code or the documentation. I'll look into it. Yaron Koren 14:05, 1 December 2010 (UTC)Reply[reply]
That would be awesome if that was possible. Write back on here if you find a solution! Thanks a lot.
Okay, I think this is now fixed in SVN, and the fix will also go into the next version, 2.0.8. If you're still reading this, please try it out and let me know if it works for you! Yaron Koren 14:46, 29 December 2010 (UTC)Reply[reply]
Oh seems to work good! Thanks a lot. Greatly appreciated!!

foldr or foldl

In the future, will there possibly be a foldr or foldl function, complimentary to the #arraymap function?
It would be nice to remove duplicate values from a list or reverse a list, among other valuable uses.
- 19:06, 29 November 2010 (UTC)

In general, the ArrayExtension extension is meant to hold all array functions, other than #arraymap - I'm not planning to add any more to SF, unless there's a compelling reason to. Yaron Koren 21:05, 29 November 2010 (UTC)Reply[reply]
Thank you. I will look into using these

Post-submit processing

Is there a way to apply a field's input to a template or function after the user hits submit? I have fields, like dates, which I would like to format differently, but since I am putting it into a property in the template page (Eg. [[Artical date::{{{date}}}]]) it has to be altered before use and after input. SFortuna November 30, 14:12

I'd like to add custom date formatting to SF, but it's not there yet, so as far as I know there's no way to do this. Yaron Koren 14:07, 1 December 2010 (UTC)Reply[reply]
Return to "Page Forms/Archive November 2010" page.