Extension talk:Semantic Forms Inputs

From MediaWiki.org
Jump to: navigation, search
Start a new discussion
First page
First page
Previous page
Previous page
Last page
Last page

Styling for datepicker fields is only applied to mandatory fields in SF 3.2

I noticed that with SF 3.2, the fancy new css applied to input fields is not applied to fields with input type=datepicker (or datetimepicker) unless the field is also set as mandatory. Functionally things are fine. Afraid that's the extent of my ability to help.

Lbillett (talk)15:56, 28 April 2015

I can confirm this but never got around reporting it. I added the following including some other modification to "MediaWiki:Common.css" to enforce the same appearance for datepickers:

/* Semantic Forms Inputs */
.hasDatepicker {
    width: 95px;
    border: 1px solid #bbb;
    border-radius: 3px;
    display: inline-block;
    margin-left: 0;
    max-width: 100%;
    padding: 4px 8px;
[[kgh]] (talk)16:03, 28 April 2015

Wow. Thanks kgh. Worked perfect!

Lbillett (talk)16:14, 28 April 2015

Ubuntu SWM Semantic Form date picker error: jquery.ui.position: Error Module jquery.ui.position has failed dependencies

I'm having a problem with date picker in a Semantic Form. I'm getting this error message:

jquery.ui.position: Error Module jquery.ui.position has failed dependencies

I've tried to find a solution, but, so far, no luck. Any suggestions?

Ubuntu: 3.16.0-31-generic #43-Ubuntu SMP Tue Mar 10 17:37:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

MediaWiki Versions look OK - all current.

Fustbariclation (talk)14:41, 17 March 2015

No idea. Maybe you could try to set debug=true in the URL and then find the actual trigger of the error using Firebug or the like.

F.trott (talk)21:42, 19 March 2015

Datepicker error: Undefined offset: -1 in [...]/extensions/SemanticFormsInputs/includes/SFI_DatePicker.php on line 287


I get this datepicker error on two wikis, running on 1.23.1 /SFI 0.9.0 alpha and 1.23.6 / SFI 0.7.

  • Undefined offset: 0 in [...]/extensions/SemanticFormsInputs/includes/SFI_DatePicker.php on line 283
  • Undefined offset: -1 in [...]/extensions/SemanticFormsInputs/includes/SFI_DatePicker.php on line 287

The corresponding lines in the PHP file are about the minDate and maxDate.

281 // correct min/max date to the first/last allowed value
282 				if ( !$minDate || $minDate < $enabledDates[0][0] ) {
283 					$minDate = $enabledDates[0][0];
284 				}
286 				if ( !$maxDate || $maxDate > $enabledDates[count( $enabledDates ) - 1][1] ) {
287 					$maxDate = $enabledDates[count( $enabledDates ) - 1][1];

I can acces, fill in and save the form, but would quite like to get rid of the error message. I have taken out the "data format" part, but with no effect. Any ideas what I could do to fix this error?

Zabien (talk)23:01, 2 March 2015

What about doing a 0.8.0 release?

The last version was officially released in May 2013. In the meantime amongst others the big I18n change catering for new versions of MW has occurred. I guess this will make upgrading easier for people.

[[kgh]] (talk)09:51, 1 February 2015

Will this extension be made available though Composer ?

That's pretty much the question: Will this extension be made available though Composer ?

Heinrich krebs (talk)17:22, 3 December 2014

Not in the short term, I am afraid. Unless somebody provides a patch.

F.trott (talk)12:19, 21 December 2014

Today button

Hi, in the datepicker.js code the showButtonPanel is 'false' because there seemed to be a bug with the button panel. When I change the showButtonPanel to 'true' however it seems to work fine.

Is it safe to make it 'true' and if it is, could there be a type specific parameter for this?

AdSvS (talk)11:16, 16 December 2014

If it works, set it to true.

(Before implementing new params the whole thing could use a makeover of the code, including an update of the widget.)

F.trott (talk)12:09, 21 December 2014

SFI not working -- Giving error


MediaWiki 1.21.2
PHP 5.3.17
MySQL 5.5.33
Lua 5.1.5
Semantic Forms Version 2.7
Semantic Forms Inputs Version 0.7

I have tried SFI 0.9alpha with the same results.

I keep getting the following error:
Ext.semanticforms.main: TypeError: Cannot read property ‘initFunctions’ of undefined

I have tried different browsers and different accounts, updated extension file permissions, etc with no luck. When I use F12 in Chrome is makes a reference to the Vector skin but I'm not sure what to make of it. Can anybody help me?


Clifford15:41, 30 May 2014

Sorry, I totally missed this. If it is still of interest, my best guess is that some JavaScript error (possibly from another extension) prevents the main SF module to load. Check the browser console JavaScript errors (Ctrl+Shift+J on FireFox).

F.trott (talk)17:48, 23 November 2014

menuselect and datepick acts innormal, seems something wrong with the JS

MediaWiki 1.22alpha (8b6be1c) 1.22wmf21 Semantic Forms (版本2.6) Semantic Forms Inputs (版本0.7)

i have testest the simplest Form, containing only a single {{{field}}}, and copied the example menuselect codes.

after i have saved, i can see the top lev contents with the triangle icons, but the lev2 triangle icons shows up too without text content. When i move mouse on it, nothing pop out.

Another problem with datepicker: the set of icons used to select date occurs twice in the same line, and both function normally.

both 2 problems could turn normal after i do a search,(i am using this form as a query form, so i can search on the same page) 04:23, 14 November 2014 (UTC), 14 November 2014

finally, i found that this is the problem of menuselect and queryformlink

when i use menuselect in a normal form invoked by {{#formlink}} , everything is ok.

but when i use menuselect in a form invoked by {{#queryformlink}}, then this bug occurs.

is there anyone can help? thx!

Extirpate (talk)09:03, 15 November 2014

This should be fixed in the latest SF development version. Please give it a try.

F.trott (talk)17:43, 23 November 2014

Sort order for "two listboxes"?

Is it possible to force a sort of the contents of Two Listboxes? I've tried going back and changing the order of the allowed values for my property, but the sort order of the listboxes never changes. Thanks.

Lsilverman (talk)03:33, 28 January 2014

I think it should be possible to do that using the plain "values" parameter (i.e. not one of the "values from..." parameters). You could try using an ask query, something like values={{#ask: ... }}. Of course you then face the problem of sorting that ask.

If you already specify allowed values with your properties the simplest solution might be to just explicitly list the allowed values by hand in your form. Or - if you have many forms - to put the list of allowed values in a template. All not very comfortable or elegant, I know.

F.trott (talk)16:16, 28 January 2014

Am I correct that specifying a preferred sort order isn't supported on any of the input types?

Lsilverman (talk)16:53, 28 January 2014

Yes, you are correct.

F.trott (talk)16:54, 28 January 2014

How about now?

Lsilverman (talk)15:11, 21 November 2014

No news and not a priority, I am afraid. If you need that feature, your best bet would be to provide a patch.

F.trott (talk)15:24, 21 November 2014

Menuselect Warnhinweis: Eine Teilabfrage enthält eine ungültige Bedingung

Edited by author.
Last edit: 09:32, 14 October 2014

Trying to use the MenuSelect https://www.mediawiki.org/wiki/Extension:Semantic_Forms_Inputs#Examples_4 as outlined in the example

{{{field|Part of|input type=menuselect|structure= {{#ask: [[Part of::+]]{{!}} format=tree{{!}} parent=Part of }} }}}

I get the error message: Warnhinweis: Eine Teilabfrage enthält eine ungültige Bedingung the simple example

{{{field|foo|input type=menuselect
* Item 1
** Item 11
** Item 12
* Item 2
** Item 21
** Item 22

works as expected. Neither

'''Thema:''' {{{field|Thema|input type=menuselect|structure={{#ask: [[Category:BITPlanStandard]] {{!}} ?nr {{!}} format=tree {{!}} parent=nr {{!}} limit=70 }} }}}


'''Thema:''' {{{field|Thema|input type=menuselect|structure={{#ask: [[Category:BITPlanStandard]] {{!}} format=tree {{!}} parent=nr }} }}}


'''Thema:''' {{{field|Thema|input type=menuselect|structure={{#ask: [[Thema::+]]{{!}} format=tree{{!}} parent=Thema }} }}}

work - all give the same error message.

All these ask queries used on their own work as expected.


  • MediaWiki 1.23.5 (a80a0a2) 19:06, 13. Okt. 2014
  • Semantic Forms 2.8 (8bdcec3) 21:31, 6. Okt. 2014 GPL-2.0+ Ermöglicht Formulare zum Hinzufügen und Bearbeiten semantischer Daten Yaron Koren, Stephan Gambke und andere
  • Semantic Forms Inputs 0.9.0 alpha (329a4b7) 19:14, 27. Aug. 2014 GPL-2.0+ Ermöglicht verschiedene zusätzliche Eingabearten für Semantic Forms Stephan Gambke und andere
  • Semantic MediaWiki 2.0 GPL-2.0+ Ermöglicht es, das Wiki zugänglicher zu machen – für Menschen und Maschinen (Dokumentation) Markus Krötzsch, Jeroen De Dauw, James Hong Kong und andere
  • Semantic Result Formats 1.9
Seppl2013 (talk)08:12, 14 October 2014

The example is wrong ... {{!}} should not be used but the verbatim | So e.g.:

'''Thema:''' {{{field|Thema|input type=menuselect|structure={{#ask: [[Category:BITPlanStandard]]  | format=tree | parent=nr | limit=70 }} }}}

works. I feel stupid :-) Please fix the example so other's won't get into this feeling, too ...

Seppl2013 (talk)09:08, 14 October 2014

Indeed? Could be something changed with latest changes in Semantic Forms. Anyway, fix it yourself, it's a wiki.

F.trott (talk)07:53, 15 October 2014


for "input type=date" works the next:


but, for "input type=datepicker" does not works "default=now"

how can i do that datepicker field prints the current date?, 4 August 2014

Datepicker: Format in Form ok but saved value displayed in wrong format

Dear all,

I'm using the Datepicker from Input formats in a german installation. In the Form I defined "date format=dd.mm.yy" and when using the picker everything is fine. But after saving the form data (I understand that the dates are saved in format YYYY/mm/dd anyway) and calling the result wiki site the date is also shown in YYYY/mm/dd format.
The strange thing is that I already have a similar setup of a Form that is also utilizing the datepicker and this works perfectly well. The date format during entering/editing in the datepicker is in dd.mm.yy format and after saving the dates on the result wiki page are also displayed in the correct dd.mm.yy format.
I could not find any differences regarding the date form fields and template definitions in both cases - therefore I don't have a clue what is going wrong here...

Does anybody have some suggestions?
Many thanks!

Sochin67 (talk)15:40, 22 March 2013

You should use the #time parser function from Extension:ParserFunctions. I don't know, why one wiki works while the other doesn't. Look at the source of the wiki pages to see if they really are the same.

F.trott (talk)20:35, 26 March 2013

The help states, that one can only format the field in the form, but the value send to the template is alsway YYYY/mm/dd, for easy storage. Well, I find it not easy in any case, for now I have to change the display of the value at every instance again, which is all, but easy.... Would be nice, if one could globally, or per property, define a standard output format.

Heinrich krebs (talk)13:24, 12 May 2014

The values are formatted by a form, so it is not necessary to change each and every page. Just change the form (format the date using the #time parser function).

F.trott (talk)13:33, 12 May 2014

Could you post an example, please ? I edited the template, that is filled by the form, so the values were reformatted to the way I want them to be, that kinda works... Still, I find it not elegant, and can't see the reason, why the format in the form isn't the same as the format sent to the template and ultimately is stored in the property.

Heinrich krebs (talk)15:23, 12 May 2014

Yes, sorry, editing the template is what I meant.

The problem with other date formats is, that they are ambiguous and may not be interpreted correctly (or not recognized at all) by SMW. So you should store the date in the property in the yyyy/mm/dd format and display it in whatever format you prefer using the #time function.

F.trott (talk)15:27, 12 May 2014

Dynamic default value (now) possible?

With SF's input type=date or datetime it's possible to specify 'default=now', and it'll fill in the current time, is this also possible with date(time)picker? 'default=2015/07/04' in the form definition does not work, since the #time parser functions does not get evaluated.

Patrick Nagel13:48, 9 March 2011

I'm afraid it is not possible with either of them. The default value is handed down to the input type in the same parameter as the current value, there is no possibility to distinguish between them so I can't decide when to parse and when not. The solution lies with SF here. You might vote on this or this bug or (more effectively) discuss it with Yaron directly.

F.trott20:35, 9 March 2011

It's not clear to me that this requires any change from SF - it might just need a fix in SFI. F.trott and I talked about the issue "offline", but now I don't remember what the conclusion was.

Yaron Koren16:00, 11 March 2011

I do. :)

The point is, SFI could parse the current/default value given as a parameter to the input. But then it would also parse any user input a user might have done earlier. E.g. lets say it would indeed parse the value. Along comes some user thinking that "{{#time:...}}" would be a good thing to put into that field - would result in a valid date after all. This user would fully and rightly expect that "{{#time:...}}" appears verbatim in the page. It even would after the first edit. Then on the second edit the datepicker would parse that string and save it, i.e. it would replace the parser command by a static value.

F.trott22:49, 11 March 2011

Patrick, could you try updating to the last SVN version of SF and using default={{#time:Y/m/d}}? (You will need Extension:ParserFunctions if you don't have it yet.) The "default" parameter should get parsed now. It's still brand new, so any bug reports would be welcome.

F.trott22:57, 15 March 2011

just tried that, but the date doesn't get parsed inside the form field. I'm using SF 2.2.1, SFI 0.4.2 alpha, parser functions 1.4.0, 8 August 2011

Hmm, should work.

What exactly do you specify as the default and what is displayed in the form?

And does it work if you use a different input type, e.g. text?

F.trott07:34, 9 August 2011

Using default with the parser worked for me. Remember that if you use a parser within a field declaration make sure it is not the last parameter specified, or if it is, place the 3 field closing curly braces on the next new line, otherwise it will break the field; for example:

  • WRONG:
    {{{field|bulletin_date|mandatory|input type=datetimepicker|default={{#time:Y/m/d}}}}}
  • RIGHT:
    {{{field|bulletin_date|mandatory|default={{#time:Y/m/d}}|input type=datetimepicker}}}
  • RIGHT:
{{{field|bulletin_date|mandatory|input type=datetimepicker|default={{#time:Y/m/d}}


   Thorncrag  19:12, 10 October 2011

That bug is mentioned in the documentation - if it's any simpler, you don't even need a newline, you just need a space (like "}} }}}").

Yaron Koren21:12, 10 October 2011

Menuselect - can you alter the drop-down menu width?

Menuselect allows you to set the maxlength of the input, and the size of the field itself.

However, the drop-down menu seems to be set at about 20 characters wide. It means that, with long menu items, they wrap-around and you have a very long, thin, drop-down menu for only about 20 items.

Would it be possible for it to set the menu width to the width of the longest entry?

Alternatively, is there a way of setting the drop-down length wider?

Fustbariclation (talk)

Fustbariclation (talk)09:14, 30 April 2014

Coincidently there is a current discussion on this on the smw user mailing-list. Cheers

[[kgh]] (talk)12:21, 30 April 2014

Thank you for the pointer - but it's not a coincidence - at least it is, but not an accidental one because the question there is also from me.

I thought I'd put the answer here for anybody coming later:

It turns out that this is a bug with Safari (version 7.0.3) - the menu works perfectly well on Firefox (version 28.0). That is, the drop-down menu is wide enough and there is no wrap-around, so it looks fine.

I've submitted a bug report to Apple about the problem with Safari.

Fustbariclation (talk)03:12, 2 May 2014

I thought that it might be you, but one never knows. Just yesterday me and another user posted the very same question to something out of the blue. So ... :) I am glad that it was possible to track down the cause of the issue and I hope that Safari does its part soon, too. Cheers

[[kgh]] (talk)07:12, 3 May 2014

pipe characters in input text

hello there i have a form where users can input text (paste e-mails that can contain all kinds of characters) I was able to escape all wiki markup characters using #replaceset function but there is one problematic one, which is pipe (|). Code datatype cannot do with it anything either. Any ideas how to escape pipes?, 23 April 2014

It might be worthwhile for those text emails to go into a form "section" (using the {{{section}}} tag), instead of a form "field" - there's a lot more flexibility there.

Yaron Koren (talk)19:48, 23 April 2014

Javascript error using input type=datapicker

I've installed SFI development version on MW 1.19 and SMW 1.7 and SF 2.5.2.

In the form I use:

{{{field|Startdatum gepland|property=Startdatum gepland|input type=datepicker}}}

It appears a textbox in the form and i get the followin Javascript error:

Uncaught TypeError: Cannot read property 'regional' of undefined TestCluster:399
(anonymous function) TestCluster:399
fire load.php:14
self.fireWith load.php:15
jQuery.extend.ready load.php:6
DOMContentLoaded load.php:12
Toine Schijvenaars (talk)18:24, 28 May 2013

I never responded to this, sorry! Is it still an issue?

F.trott (talk)08:43, 14 February 2014

Support default=now

For datepicker please!

David Mason (talk)16:19, 7 July 2013

Conditional Regular Expression

Hi I'm sure I'm missing something simple, but here's the problem: I have some optional fields that a user can elect to fill out or not, but when they are filled out they need to be limited to the pattern they can enter. But if I set a regular expression for that field it shows an error if it is not filled out. The mandatory setting in Semantic Forms recognizes if statements -- is there away with semantic inputs to write a regular expression that's conditional? I'm sure I'm over looking something simple, because that's generally the case, but any guidance here would be helpful. Thanks

Christharp (talk)04:01, 12 December 2013

The input is matched against a JavaScript style regexp. Maybe this helps: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions

In principle it should be as easy as wrapping your whole regexp in parenthesis and appending a question mark.

F.trott (talk)12:57, 16 December 2013

Forms gone

Hello team,

After a dozen upgrades and a fresh mediawiki install I've lost all my forms. I unable to locate 'm in backups. Where are the forms saved to?


T, 18 November 2013

Forms are stored as pages in the Forms namespace.

F.trott (talk)14:15, 20 November 2013

box size for "two listboxes"

It would be nice if we can specify the size of the two listboxes rather than playing with css... Thanks in advance., 31 October 2013
First page
First page
Previous page
Previous page
Last page
Last page