Extension talk:Semantic Forms

From MediaWiki.org
Jump to: navigation, search
This page contains changes which are not marked for translation.

An archive box Archives 


Scemantic search for a page with number type property doesn't work[edit source]


I have created a Number Property called "Cost".

I have created new pages with this property through a form.

But when I use the Scemantic search (Special:Ask), it find "no results"...

If I change the Property type to Text, it finds some results...

Do you know what I do wrong ?

Thanks a lot. BR, Clément

This is a Semantic MediaWiki issue - you should submit a bug report about it on the SMW GitHub site. Yaron Koren (talk) 14:58, 10 November 2015 (UTC)

Adding a list of existing pages names and link into a form results page[edit source]

Hi Yaron, Hi All,

I want to insert an autocompletion search field into a form to let the users search for existing pages and who "tokenizes" the page name in the field.

In the results page, I should be able to display the name of the pages that have been tokenized in the form. Each page name has a link to its page.

In other words, this functionality will link a page to others.

Any idea how to do that ?

Thanks for your great support.


I don't really understand the point of this, but it sounds like you could do it with Special:RunQuery, where the template would not call a query but instead just display links to all the pages, using #arraymap. The form would presumably use the "tokens" input type. Yaron Koren (talk) 14:02, 24 September 2015 (UTC)

Inserting a simple popup (modal) in a form[edit source]

Hello there,

I would like to insert a popup (like a Bootstrap modal) into a form.

Do you know how I can do that ?

I know how to insert a Tooltip and to Enhancing query forms. But I didn't find anything about inserting a simple popup with simple text in it without using HTML.

Thanks a lot

What about a tooltip instead? For that you could use #info, if you have Semantic MediaWiki installed, or if not you could use the SimpleTooltip extension. Yaron Koren (talk) 16:50, 15 September 2015 (UTC)
Hi Yaron, a tooltip is to small for all the content that I want to insert in the popup (image + text) plus, it doesn't fit well in my webdesign. :( is there a way to insert a boostrap modal ? I use Chameleon skin by the way. Thanks.
I fixed the problem. To anyone that might be interested : I used [shortcode of Chameleon] and I remplaced the <button> that is not interpreted by mediawiki by a simple div.

Horizontal code output from form?[edit source]

Hello Does anyone know whether its possible to force a form to create horizontal code eg.


instead of


I don't want this on every form, so im not looking for a global setting. any ideas?

I don't think it's possible, unfortunately. Yaron Koren (talk) 18:14, 1 September 2015 (UTC)

Save And Continue breaks multi instance forms with divs[edit source]

Just a heads up, though this might be a bit specific... I have a form with multiple instances. Additional fields appear/disappear depending on your choice from a dropdown. Pressing save and continue and then changing your choice from the dropdown will load the fields as it should, but they're greyed out and not editable until you reload the page. SMW 1.6.2, SF 2.2.1

Automatic page creation "broken" with SMW's php rebuildData.php[edit source]

On our wiki pages get created automatically with SMW's rebuildDate.php (previously called SMW_refreshData.php) and runJobs.php. We use the ExternalData extension to load customer data into the wiki. When a customer is new the page will then be created automatically. This worked fine but stopped working in SMW 1.9.2. In this release the move was made from SMW_refreshData.php to rebuildData.php. I tested this on MW 1.23.9 and different SF versions, 2.8 and master.

Testing this in my home wiki (MW 1.24.1, SMW dev-master and SF 3.3.1) the same thing happens. Example with a property page called Property:Testname with the following content:

* Has type:[[Has type::Page]]
* [[Creates pages with form::Testcaseautofill]]

== Test pages ==
* [[Testname::Testcase1]]
* [[Testname::Testcase2]]
* [[Testname::Testcase3]]
* [[Testname::Testcase4]]

After saving the page and running php runJobs.php the 4 pages get created automatically.

When I then delete Testcase1 and rebuild with:

php rebuildData.php --no-cache -v


php runJobs.php

The page Testcase1 does not get created. The property Testname actually has the value Testcase1 but with a red link. Even when I use the Data repair and upgrade function and run php runJobs.php the page Testcase1 does not get created.

I am pretty sure that SMW_refreshData.php added pages to be created to the MW job Que which you could then "empty" by using runJobs.php. I am not sure why this is not working any more. It seems that SMW's php rebuildData.php is "ignoring" [[Creates pages with form::Testcaseautofill]] or SF as a whole or SF is not doing its "job".

Because of this "problem" it is not possible any more to get pages to be created automatically. The only way to do this in the example above is to refresh the Property:Testname page and run php runJobs.php. I already reported this on GitHub (half way the discussion) because I noticed this behaviour during testing. It would be a shame when this "functionality" is lost. Is this something that can be fixed in SF or in SMW or both? Regards, --Felipe (talk) 12:27, 3 September 2015 (UTC)

The discussion on GitHub has progressed. Yaron, when time permits could you have a look at the comment from MWJames on GitHub? Is this part of a possible "solution" for the problem discussed here, if so is it something that can "easily" be achieved with SF? Thanks, and regards. --Felipe (talk) 12:26, 4 September 2015 (UTC)
Actually, I'm planning to replace the "Creates pages with form" special property with a parser function, like was done with "Has default form" and "Has alternate form". That will remove the SMW-related issues, and will enable Cargo support as well. I'll try to get to that soon. Yaron Koren (talk) 13:34, 4 September 2015 (UTC)
OK, thanks. --Felipe (talk) 14:30, 4 September 2015 (UTC)

I think I found a bug during testing {{#formredlink:...}}. On a Property page (but it can be any page) when you use:

== heading ==
* [[Testname::Testcase1]] {{#formredlink:form=Testcaseautofill|target=Testcase1|create page}}

When you save the page and Testcase1 does not exist the page gets saved but on your screen you get:

[03b02c65] /mediawiki/index.php/Property:Testname MWException from line 86 of /var/www/html/mediawiki/includes/parser/ParserOutput.php: Bad parser output text.
#0 [internal function]: ParserOutput->{closure}(array)
#1 /var/www/html/mediawiki/includes/parser/ParserOutput.php(97): preg_replace_callback(string, Closure, string)
#2 /var/www/html/mediawiki/includes/OutputPage.php(1854): ParserOutput->getText()
#3 /var/www/html/mediawiki/includes/OutputPage.php(1873): OutputPage->addParserOutputText(ParserOutput)
#4 /var/www/html/mediawiki/includes/page/Article.php(617): OutputPage->addParserOutput(ParserOutput)
#5 /var/www/html/mediawiki/extensions/SemanticMediaWiki/includes/articlepages/SMW_OrderedListPage.php(67): Article->view()
#6 /var/www/html/mediawiki/includes/actions/ViewAction.php(44): SMWOrderedListPage->view()
#7 /var/www/html/mediawiki/includes/MediaWiki.php(458): ViewAction->show()
#8 /var/www/html/mediawiki/includes/MediaWiki.php(255): MediaWiki->performAction(SMWPropertyPage, Title)
#9 /var/www/html/mediawiki/includes/MediaWiki.php(682): MediaWiki->performRequest()
#10 /var/www/html/mediawiki/includes/MediaWiki.php(476): MediaWiki->main()
#11 /var/www/html/mediawiki/index.php(41): MediaWiki->run()
#12 {main}

SMW's php rebuildData.php also won't run BUT When you don't have the heading:

* [[Testname::Testcase1]] {{#formredlink:form=Testcaseautofill|target=Testcase1|create page}}

or there is no heading before {{#formredlink:...}} like:

* [[Testname::Testcase1]] {{#formredlink:form=Testcaseautofill|target=Testcase1|create page}}
== heading ==

It works, the page gets saved without any faults and php rebuildData.php also works. Maybe I am doing something wrong here but that MWException should not come I think. There are also some other strange things happening but that could be me, not understanding {{#formredlink:...}} in combination with create page:). It seems that it is not possible anymore to tell the wiki to create pages for a certain property like Creates pages with form in the past. --Felipe (talk) 08:30, 19 September 2015 (UTC)

That indeed sounds like a bug. But I don't understand why you have that particular text - won't it print the page name twice? Maybe you should use #set to do the setting of the property - and maybe doing that won't lead to the same error. Yaron Koren (talk) 00:22, 21 September 2015 (UTC)
Hello Yaron, yes it will print the text twice. I was just playing around with an "old" template. I did some more testing and below is what is happening when the page that needs to be created does not exist yet.
Example 1 with heading
== heading ==
{{#formredlink:form=Testcaseautofill|target=Testcase1|create page}} {{#set:Testname=Testcase1}}
A. This breaks php rebuildData.php, it will fail on the specific page with [7c3c6468] [no req] MWException from line 1662 of C:\Apache\htdocs\mediawiki-1.25.2\includes\OutputPage.php: Title is null. I can send you the Backtrace if you want.
B. When you refresh the page it shows:
SF Page Refresh 2015-09-21.png
If you refresh again the page looks normal and Testcase1 is created.
Example 2 heading below
{{#formredlink:form=Testcaseautofill|target=Testcase1|create page}} {{#set:Testname=Testcase1}}
== heading ==
A. This breaks php rebuildData.php, it will fail on the specific page with [e4129d6a] [no req] MWException from line 1662 of C:\Apache\htdocs\mediawiki-1.25.2\includes\OutputPage.php: Title is null.
B. When you refresh the page it looks normal with a redlink for Testcase1.
If you refresh again the page looks normal and Testcase1 is created.
Example 3 no heading
{{#formredlink:form=Testcaseautofill|target=Testcase1|create page}} {{#set:Testname=Testcase1}}
A. This breaks php rebuildData.php, it will fail on the specific page with [465ec2a4] [no req] MWException from line 1662 of C:\Apache\htdocs\mediawiki-1.25.2\includes\OutputPage.php: Title is null.
B. When you refresh the page it looks normal with a redlink for Testcase1.
If you refresh again the page looks normal and Testcase1 is created.
In combination with ExternalData
I also converted our template to use {{#formredlink:...}}. It uses externaldata to generate pages automatically but it is not possible to save the page, you get a blank screen. This is because it uses {{#for_external_table::

* {{#formredlink:form=Testcaseautofill
|create page
}} {{#set:Testname::{{{Testname}}}}}
When we use {{#display_external_table: it works.

But the same faults appear as in the earlier examples. When a page does not exist yet php rebuildData.php will fail and if there are headings before {{#formredlink:...}} you get faults on the actual pages. I hope this helps to fix this. Regards, --Felipe (talk) 13:18, 21 September 2015 (UTC)

[SOLVED] Query for the page title in a query form[edit source]


how can I query for the page title in a query form? Since the page title is created via the first form field in the two-step-process, there is no manually created property behind it. I need to have a form field where I can search in the page titles. – I have the feeling I might just be missing something very obvious. –Zabien (talk) 16:52, 3 September 2015 (UTC)

You just need to have the template store the page name via a property (if you're using SMW) or field (if you're using Cargo). In either case, you can use the {{PAGENAME}} magic word. Yaron Koren (talk) 20:10, 3 September 2015 (UTC)
So I have to use e.g. [[Has page title::{{PAGENAME}}]] to be able to query for it later? Okay, that seems to be the obvious I've missed. Thought there might be an even more direct way. Thank you for the quick help! –Zabien (talk) 21:36, 3 September 2015 (UTC)
I think that's the easiest way. Although using #set might be preferable, since you don't want to display a value to the screen. Yaron Koren (talk) 23:16, 3 September 2015 (UTC)
Good point! I'll give this a try! Thanks heaps! –Zabien (talk) 10:21, 4 September 2015 (UTC)

Missing values in "Semantic Property" dropdown box[edit source]

I am using Mediawiki 1.25.2, Semantic MediaWiki 2.2.2, Semantic Forms 3.3.2 (2e5712c). I tried to create a template. The semantic property dropdown box only list 14 values. Even I add additional properties via Special:CreateProperty. Does it happen to your version? Any fix? -- 08:24, 15 September 2015 (UTC)

I had restarted php-fpm and the problem went away, i.e., there is a cache issue. Is there a mean to force the update of cache? Also renamed properties (redirects were deleted too) also showed up in the list of values of Semantic Property -- 08:29, 15 September 2015 (UTC)
I don't know - this might be a Semantic MediaWiki issue. The SF code is just calling an SMW function to get the list of properties. Yaron Koren (talk) 13:37, 15 September 2015 (UTC)
I would like to confirm that even the property is deleted, the SWM function (please point me to the file or function as I am new to mediawiki and php) still return the deleted property.
That is a known SMW issue - I'm guessing that you can also see that same deleted property on the page Special:Properties. If so, you should ask the SMW developers about it. Yaron Koren (talk) 14:37, 15 September 2015 (UTC)
For a discussion about deleted properties/subjects (and its apparent reappearance), please have a look at the #1100 issue.--MWJames (talk) 14:59, 15 September 2015 (UTC)

Using query string in #forminput[edit source]

I have a form which has a property "Student ID" and I want this property to be filled from #forminput via query string and using value from the title of the page.

  {{#forminput:form=Student|placeholder=Student ID|query string=Student[Student ID]={{PAGENAME}}}}

  <div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
  {{{for template|Student}}}
  {| class="formtable"
  ! Student ID: 
  | {{{field|Student ID|mandatory|restricted|class=student_name|rows=1|cols=9|maxlength=9}}}
  {{{end template}}}

If I use form name "12345699A", the immediate URL is


What I want is


I do not know how to get or parse URL using the existing standard extension as I did not install Extension:UrlGetParameters.

I'm not completely sure I understand, but it sounds like you'd be better off using #formlink instead of #forminput, and a page name formula. Yaron Koren (talk) 14:40, 15 September 2015 (UTC)
I tried #formlink just now, do not know how to enter the "Student ID". My original question can be simplified to

1) Enter 123456789A into the textbox

Form input.jpg

2) I want $forminput to generate the url


instead of


--Yoonghm (talk) 14:59, 15 September 2015 (UTC)

The specific thing you're asking about can't be done. However - if the student ID is always the page name, why do you need a form field for it at all? Can't you just always use the page name? Yaron Koren (talk) 15:03, 15 September 2015 (UTC)
The problem for beginner likes me is that there are too many features within mediawiki and its extensions, there is no other good reference except your book. I want to put the Student ID as a property as I cannot prevent people from changing it and can be used for semantic query. Okay, I will consider your suggestion. --Yoonghm (talk) 15:30, 15 September 2015 (UTC)

Max size for properties[edit source]

I would like to start a review site and store the reviews in properties. Yet even a comparably short review (800 words, 4500 signs) breaks the parser. What would be the recommendation in order to deal with this? I would like to add interviews with the length off 12(!) A4 pages into a property. Currently, I had to move all into a standard input field in order to avoid broken parser tags.

To give an example of what I talking about: http://adsol.oneyoudontknow.com/index.php/wiki/Anticosm_-_Anticosm

  • Top: the text added as a property (text)
  • Below: text added as a free field.

The lack of formatting is due c/p it from the bottom.

--Temptuousinsolence (talk) 18:17, 15 September 2015 (UTC)

Is this a Semantic Forms question? Anyway, I don't think it's the size of that text that's causing the problem, but rather the fact that it contains square brackets. Yaron Koren (talk) 01:21, 16 September 2015 (UTC)

Group pages (created via Semantic Form) in Category:<category_name> according to other properties instead of page name[edit source]

I have created several pages using Form:Student with the following page names.

  • 1111111A
  • 1111112B
  • 2222222C
  • 3333333D

These pages are in Students category.

Form:Student uses Template:Student which has the following properties

|Student ID=
|Student Name=
|Tutorial Class=
|Admission Year=
|Accumulative GPA=
|Acad Program=
In the Category:Students page, these pages are grouped under 1, 2 and 3.

How can I use Tutorial Class property to group them? --Yoonghm (talk) 02:18, 16 September 2015 (UTC)

This isn't a Semantic Forms question, but: you should be able to use DEFAULTSORT for that. Yaron Koren (talk) 13:13, 16 September 2015 (UTC)

Constraining the user to use forms to create a page.[edit source]

I want to constrain users the use the forms to create a new page.

In other world, users can't create new pages on my wiki. They can ONLY add new pages thought the form. Is there an easy way to do that ?

Thanks a lot.

I don't know of any. Yaron Koren (talk) 13:14, 16 September 2015 (UTC)

#default_form parameter to hide "This category uses the form ..."[edit source]

Is there a way to hide the "This category uses the form ..." text that is inserted automatically by #default_form? Like [[Has default form::myform| ]]...

--Planetenxin (talk) 11:47, 17 September 2015 (UTC)

Unfortunately, not at the moment - other than putting it in a hidden div or some such. Yaron Koren (talk) 12:56, 17 September 2015 (UTC)

Semantic forms and Translate[edit source]


I'm trying to use Semantic Forms and Translate extensions. My problem is that I can't modify an existing page containing the Translate's tags <translate><!--T1--> with Semantic Forms (big red message when saving "Modifying Page failed").

As the page can safely be modified with the tags using the edit tab, I'd like to know if there is something I can do to force Semantic Forms to save a page with those tags ?

Best regards. LS.

That's unexpected... what versions of MediaWiki and SF are you using? And are the "translate" tags contained above or within the infobox template, or just below it? Yaron Koren (talk) 16:25, 17 September 2015 (UTC)
Thanks for your reply. The versions are the last stables (1.25.2 for Mediawiki) downloaded tuesday. The tags are in the wikicode produced by the form. For example, I create a page containing :
by writing <translate>Blabla</translate> in the Title field of a Semantic Form. All goes right until I try to effectively translate the content : as soon as the <!--T1--> appears, it's no more possible to modify the page with the form. If I try to change (with the edit tab) say <translate> in <translat> or <!--T1--> in <!--V1-->, the Semantic Form returns to its normal operation.

--Ludovic Strappazon (talk) 20:57, 17 September 2015 (UTC)

That's unfortunate... I have no idea why that's happening. It sounds like a bug in either SF or Translate, but I don't know more than that. It might be worth creating a Phabricator ticket for it. Yaron Koren (talk) 01:47, 18 September 2015 (UTC)
Hi, I've just seen that if I remove the Translate extension, Semantic Forms returns to its normal operation and save the contents with tags. I'm going to create a ticket. Thanks again.

Best regards, --Ludovic Strappazon (talk) 07:21, 21 September 2015 (UTC)

Wrong format date output[edit source]

First I want to congratulate you on this great script. I am Spanish, and here the usual format is day / month / year. When I create a page with form, the date field appears in this format. When I edit the property of the field is also used properly displayed in this format. But the end result is always the created page Year / month (with numbers) / day.

I have read through everything and I have tried everything without getting any results. I'm not sure that the problem is in your script, because if I put on any page


also shown year/month/day. But I insist that the property is properly displayed.

Can you help me solve this ?. Thank you very much for your time and help: Luis.

I don't think there's any way to get a form to output day/month/year. But you can have the template display dates in this format to the user, using the #dateformat parser function - see Help:Magic words. Yaron Koren (talk) 16:32, 17 September 2015 (UTC)

Thank you very much for your quick reply. I'm clear that the problem has nothing to do with his script. Anyway, I had already tried this method I have even tried to define it manually in LocalSettings.php simply ignored by my wiki. You can see an example here: [1] Thanks again

I don't understand the syntax you're using in that template - you should be calling #dateformat. Yaron Koren (talk) 01:38, 18 September 2015 (UTC)

solved[edit source]

Explain the steps if they can be of help to someone: First I tried his method and works but it has any drawbacks:
- Does not accept the format xx / xx / xx so must first replace the "/" with "-"
- The system does not recognize it as date format and has an error, so that the property can not be "date" it must be "text"
- You can not add words to date like (typical in Spanish) "02 de enero de 2010"

The solution I've found to not have any of the above three problems is to use


(requires ParserFunctions).

For example

{{#time:d \d\e F \d\e Y|{{{Nacimiento|}}}}}

Where "Nacimiento" is the name of the property that I used to date in my template, It produces output (if such date is 2010/01/20):

20 de enero de 2010

and the system is no problem recognizing it as date. Thank you very much for your support that has helped me a starting point and hope it can be useful to someone. Greetings: Luis

Problem with #default_form[edit source]

When you transclude a page that uses #default_form through a template, then the page which embeds this transcluded content also inherits #default_form: as a result, that page becomes editable using the wrong form. I'll just stick to the old SMW approach (which lets you embed content without inheriting its annotations). Is there anything else that can be done about this? Best, Cavila 12:18, 21 September 2015 (UTC)

I can't think of anything. Yaron Koren (talk) 13:53, 21 September 2015 (UTC)
Alright, thanks. It's no problem for me as long as that special property is supported. Cavila 18:59, 21 September 2015 (UTC)

Problem with "checkbox"[edit source]

When i use input type "checkbox" with russian as main wiki language, it stores value "Yes" like "да". But when I try to edit existing page with this value checkbox shows unchecked. If I manually change value from "да" to "Yes" the checkbox shows ckecked.

Is it possible to disable this localisation interchange for checkbox and have only Yes?

No... but that's a bug that should be fixed. What versions of SF and MW are you using? Yaron Koren (talk) 14:10, 25 September 2015 (UTC)
I was actually asking about your MW version, not your SMW version, but anyway, I think I have enough information to solve this bug. The issue seems to have been due to a combination of a change I made two months ago and the fact that PHP's regular lowercasing function doesn't work for Cyrillic. I think I just fixed it; if you get the latest SF code, the problem should go away. If not, please let me know. Yaron Koren (talk) 23:21, 11 October 2015 (UTC)
  • I had MW 1.23 but today I've completely updated MW to 1.25, SMW to 2.2.2 and SF to 3.4 (90cb2b3) (latest version including patch with mb_strtolower). It still not shows checkbox checked when template has "Да" as "Yes". I'll send You login data to my wiki (I guess it may help).
  • One important add: I've not set any value to mbstring.internal_encoding, so when I try execute mb_strtolower('Да') I show 4 black diamonds with ask sign into (utf-8 to iso 8859-5). When I execute mb_strtolower('Да','utf-8') I recieve 'да' (correct).

Editable-grid input (jqGrid?)[edit source]

This has been a planned feature at least since 2011 and was discussed on the mailing list back in 2010. A good alternative is, of course, the multiple-instance form, which has seen a lot of improvement over the years and which is in some respects, more versatile than a simple datagrid. So I was wondering: do you still see a future for the grid feature? And in situations in which a form contains (say) 40+ instances of a template, do you think there's any significant performance gain to be had from an editable grid input in comparison with the current feature? Cavila 21:07, 2 October 2015 (UTC)

I still think it would be cool to have the editable grid feature; although I also think it would be hard to implement. And yes, it would be less flexible than the multiple-instance template option. I don't know whether it would have better performance, but I'm guessing it would. I've heard that forms start to become unloadable if there are 50 or more template instances on the page, which probably wouldn't happen with the jqGrid thing, I would think. Yaron Koren (talk) 22:42, 2 October 2015 (UTC)
Thanks. Implementing and maintaining such a feature can't be trivial (FWIW, jqGrid is used in the timeseries result format, but that's for presenting rather than inputting data). But it would be a great thing to have, perhaps especially for keeping long lists of things. Sounds like a candidate project to be proposed for the next Google Summer of Code. Cavila 07:56, 3 October 2015 (UTC)

Firefox problems with tree and combobox[edit source]

We've started having some weird issues with Firefox after installing Semantic Results Formats. In particular, the combobox and tree input types no longer seem to be working properly.

The code looks like this:

 {{{field|location|input type=combobox|mandatory|property=Location|size=50}}}


{{{field|1|input type=tree|height=200|mandatory|top category=2015 Logs|hideroot|height=200|width=250}}}

It continues to work just fine in Chrome. Here are screenshots comparing the two: Combobox and Tree

We're on MW version 1.25.1, SMW version 2.2.2, Semantic Forms version 3.4, and Semantic Results Format version 2.3 (though I don't know that that one's related, it did seem to break after installing it).

Any ideas for things to look at? I'm mystified.

The SRF thing might actually be the cause - if you use SMW and SRF, they should be at the same "2nd level" version, i.e. if it's SMW 2.2.*, it should be SRF 2.2.*. It could be that the mismatch is causing some JavaScript problem. Yaron Koren (talk) 01:14, 18 October 2015 (UTC)
Thanks, I'll see if can get those in the same version and see if it fixes the problem! --Aekki99 (talk) 03:46, 18 October 2015 (UTC)
My wiki has same parameters (mw 1.25, smw 2.2.2, sf 3.4 and srf 2.3 ) and both features (combobox and tree) work fine in firefox. Try to look over browser javascript console (Ctrl+Shift+K). It might be another extension that also uses javascript (like fancybox etc.). Dmitry Russkih (talk) 11:58, 18 October 2015 (UTC)

Old Error pops up again: .....includes/MagicWord.php: Error: invalid magic word 'default_form'[edit source]

I'm running MW 1.25.1, when I upgraded SF to 3.4 I get this error when I tried to run /mw-config/.

...includes/MagicWord.php: Error: invalid magic word 'default_form'

I see others had this problem a year ago but I couldn't find their solution to it. Only after commenting out SF in LocalSettings.php would /mw-config/ complete, after which I could reinstall SF and /mw-config/ would simply show its "Upgrade complete." page. Is this fixed in v1.25.3? WmBliss (talk) 03:05, 19 October 2015 (UTC)

I don't know. Is this problem still happening? Yaron Koren (talk) 14:04, 19 October 2015 (UTC)

template in forms[edit source]

Hi Yaron,

I would like to use a template for an often needed field type in a form like

{{{for template|evaluation}}}

where the first parameter is an upcounting number, the second parameter contains the topic.

The templates source is

| {{{2}}}
| {{{field|{{{2}}}|input type=radiobutton|values=yes,no|show on select=yes=>yes{{{1}}};no=no{{{1}}};|mandatory}}
| <span id="yes{{{1}}}">50 points</span><span id="no{{{1}}}">0 points</span>

Using this I don't get a field in the form.

When I use this lines instead of the template (of course without parameters) in the form like

| topic1
| {{{field|topic1|input type=radiobutton|values=yes,no|show on select=yes=>yes01;no=no01;|mandatory}}
| <span id="yes01">50 points</span><span id="no01">0 points</span>

the form works.

What goes wrong using templates in a form? Even a template without parameters doesn't work. And even if I don't use a table it doesn't work.

You need to escape the form elements; see here. Yaron Koren (talk) 01:50, 20 October 2015 (UTC)

Undefined property: SFTemplateField::$mCargoFieldType[edit source]

Not sure if this is a Page Schemas or Semantic Forms issue. I'm trying to setup semantics using Cargo. I've got a page schema setup, runJobs, and it gets as far as creating tables but not the fields.

In edit schema for a category I check the cargo field box and select types (i.e. text, page, date). After I generate pages I look in the edit source for the template created and the fields aren't defined for the cargo_declare...

{{#cargo_declare:_table=Project}} </noinclude><includeonly>{{#cargo_store:_table=Project|Date={{{Date|}}}|Author={{{Author|}}}|Update={{{Update|}}} }}{| class="wikitable" ! Date | {{{Date|}}} |- ! Author | [[{{{Author|}}}]] |- ! Update | {{{Update|}}} |} </includeonly>

I'm getting errors in my logs like this...

Undefined property: SFTemplateField::$mCargoFieldType in extensions/SemanticForms/includes/SF_Template.php on line 67.

Here are my versions:

Semantic Forms 3.4 (464a78b) 12:45, October 23, 2015

Cargo 0.10 (5d58912) 00:38, October 15, 2015

Page Schemas 0.4.5 (05b735d) 13:49, October 20, 2015

Sorry about that! This was a bug in Semantic Forms, although it only showed up when used with Page Schemas. I guess I must not have tested this... I just merged in what I think is a fix for this bug in SF. Yaron Koren (talk) 01:16, 26 October 2015 (UTC)
That did seem to fix that issue, thanks. I'm still having some issues creating a table just for one of my templates, but I'll add a new topic under cargo to discuss.

language of boolean values in templates[edit source]

I have a Form:X calling Template:X which contains a boolean Property:X. I'm seeing a behavior related to the language used for the value of the property which I'm having trouble finding a reason for.

I'm using: MW 1.24.2, SMW 2.2, SF 3.4. The value of $wgLanguageCode is "da".

I have a fair amount of pages using Form:X, Template:X with correctly functioning values of Property:X in English: "yes" or "no".

Something must have changed, because when I use the Form:X to edit one of these pages now, it gets saved with Danish boolean values: "ja" or "nej". It appears to me that $wgLanguageCode is one place to control the selection of language for these booleans, but I'm fairly certain I did not change that.

What is puzzling me is this: given that I did not change the $wgLanguageCode, what setting was it which resulted in a SMW with $wgLanguageCode of 'da' to use english boolean values? I've tested changing the language in my account and that does not seem to override $wgLanguageCode.

any clues? JosefAssad (talk) 18:17, 27 October 2015 (UTC)

Yes, there was a change in SF two months ago; you can see it here. The code now gets its values from MediaWiki, not SMW; and I'm guessing that MW has Danish values while SMW doesn't, or something like that. Is it a problem? Yaron Koren (talk) 23:55, 27 October 2015 (UTC)
I did figure out that $wgLanguageCode was the first factor which changes which language is used for booleans. The thing which is causing me confusion is, that the wiki has always had a Danish language code, yet I have pages which were created and work fine using sematic forms which used english boolean values. A couple of days ago, I performed a null edit on one of those pages and it changed the Booleans to Danish. Of course this is fairly easily remedied by adding the Danish booleans to the SMW_true_words and SMW_false_words but I'm wondering what prompted the form to suddenly choose Danish when it had been using English boolean words before. Of course the answer is usually "you changed something" so I think it's mainly a matter of finding out what it is precisely I changed. :) The versions of MW/SMW/SF have not changed, and the $wgLanguageCode has not changed either. JosefAssad (talk) 10:01, 28 October 2015 (UTC)
Oh, okay. Well, it could be that that page, or pages, was created before you upgraded to SF 3.4... Yaron Koren (talk) 10:16, 28 October 2015 (UTC)
Ah yes, that looks like the cause; I checked a backup and it was on 3.2, the server in question is on 3.4 currently. So before, SF was getting the boolean words from SMW_true_words and SMW_false_words, and after it was getting them from the MW localisation, is that correct? It seems to me that my problem (SF saves Danish boolean values which are not recognised by SMW) can be remedied by adding the Danish words to SMW_true_words and SMW_false_words, but shouldn't SMW also recognise the Danish boolean terms automatically? JosefAssad (talk) 10:54, 28 October 2015 (UTC)
If the Danish words for "yes" and "no" aren't there in the list, that would explain why it's failing. Yaron Koren (talk) 23:42, 28 October 2015 (UTC)

using formlink to edit a single entry on a page with multiple instances[edit source]

I have a page with multiple instances of the same template. I do have a multiple instance form to help with the editing, but when only making a small change things can get pretty confusing. So I added a formlink to the template that calls a single instance of the multi-instance form. Unfortunately it doesnt have the desired effect: it just always loads the first instance on the page. The instances do have unique IDs, is there any way to refer to these?

I've been fiddling for a while and searching the disuccsions to no avail. Any ideas appreciated :) -- 14:22, 29 October 2015 (UTC)

I'm not sure what you were trying to do with #formlink, but unfortunately there's no way to show just one instance in a form. Yaron Koren (talk) 14:48, 30 October 2015 (UTC)

Adding a table containing pipes ("|") into a text field of a form ?[edit source]

Is it possible ?


Nicolas NALLET (talk) 16:58, 31 October 2015 (UTC)

Unfortunately, no - unless you use {{!}} instead... I hope to look into this soon. Yaron Koren (talk) 21:58, 1 November 2015 (UTC)
Ok thanks, I will use this workaround. Nicolas NALLET (talk) 10:20, 2 November 2015 (UTC)

Any {{ in section text when editing with form causes text to disappear from that section[edit source]

I recently noticed a problem editing with forms on my wiki. This seems to happen only when the form includes a section AND the section in the form includes a template along with a free text area. Editing the text area in the section (with or without form) it is possible to add and save a template or a parser function, anything with double curly brackets such as {{PAGENAME}}. All good so far, but if I then click the "edit with form" tab at the top of the page, all text after and including the first {{ in that section is simply gone. I can toggle between the normal "edit" tab (all text shows) and the "edit with form" tab (no text), and if I save while in the form it saves just what I see (no text).

This does not happen in Sections in the form that include only a text area and not a template, and it does not happen in textarea fields within a template in a form.

Running mediawiki 1.25.2 - SMW 2.3 - SF 3.4. Thanks for any help.

--Davsib1 (talk) 20:50, 3 November 2015 (UTC)

That sounds like a bug... hopefully it'll get fixed. Yaron Koren (talk) 17:26, 4 November 2015 (UTC)

Edit with form when there are 2 or more forms on page.[edit source]

Hi there, I currently have a setup in which I use two different forms on one page. I have it set up to use an "Edit with form" tab but by the setup I had to select a default form to link it to. As a result when editing, it only shows the default form it is linked to and the other just appears as a free text without form at the bottom of page. Is there a way o have more than one or all forms on a page to open using the forms when clicking on Edit with form tab? Here is my sample page http://www.wikimezmur.org/am/Hana_Tekle using two forms Artist and Albums. Albums is linked as default but artist which should be on top comes down as free text at bottom and if saved it will be saved at the bottom of page.

I have tried to work around it for a while but hoping for a solution. Thank you for the input. Wikimanz (talk) 16:41, 15 November 2015 (UTC)

Looking at your setup, I don't know why you have two forms - it would seem to make sense to have a single "Artist" form, that holds both templates. Yaron Koren (talk) 03:41, 16 November 2015 (UTC)

Preview and Bootstrap[edit source]

The preview Button is not working on Bootstrap-enabled pages, i.e. if the skin you are using is Bootstrap-enabled. Actually, a preview is build inside an iframe, but it has a height of 0px. On pages without semantic forms, it works fine, as the preview is handled by another function.

Possible solutions I came up with:

  1. Use only skins which are not Bootstrap-enabled. This is bad, as Bootstrap does provide some nice functionality.
  2. Use another framework which provides the same functionality as Bootstrap. I haven't tried that yet.
  3. Disable Bootstrap inside the preview. I don't know if that is possible
  4. Build the preview the regular way. I'm not sure why semantic forms handles it's own preview. The problem seems to be in handleLoadFrame()
  5. Disable the preview Button for certain skins.

All of these quasi solutions are somehow lame. Any ideas how to solve this in a simple and satisfying way?

(btw: this is the 1st topic in the archive of past discussions, but it's not solved yet).

cheers, Alvaro Ortiz Troncoso (talk) 09:04, 16 November 2015 (UTC)

I would think the best solution is to have that iframe have a full size. That's probably a CSS issue, but I don't know how to fix it. That issue from 2011 is unrelated, I think. Yaron Koren (talk) 15:29, 16 November 2015 (UTC)

How to control checkbox lay-out in form[edit source]

Hello, I am wondering if there is a way to control the how check-boxes are shown in a form (when used with {{#arraymap:... in the template) which can assign multiple values to a property. An example is shown here. When you press edit on that page you go to the form and al possible options are shown, users are able to select the options they need. This is what we want but the way that the check boxes are shown is not very user friendly, we want to be able to put then in a list, each one on a new line. Basically like the list box but then with check boxes. The list box is not an option because you loose your selection when you don't use the ctrl key, this is bound to go wrong. Is this possible with SF, I can not find anything in the documentation? Thanks --Felipe (talk) 08:29, 17 November 2015 (UTC)

See here. If you want each checkbox on a separate line, I think "width: 100%" would do it. Yaron Koren (talk) 15:27, 17 November 2015 (UTC)
Thanks for the tip, it works like a charm. I completely missed that one. Regards, --Felipe (talk) 16:23, 17 November 2015 (UTC)

Some more div id for 'show on select'[edit source]

Like mentioned before in the archived issue div id for 'show on select' by Cavila, hiding multiple "spots" in the form with a single id actually works in SF 3.2. All id's with the same name are hidden when not selected, it does not matter where they are in the form. I did not find an explanation or solution in the short discussion.

The example here shows what happens in SF 3.4. When you press edit and toggle Show on select: only the first id is hidden. I do not see any errors in my browser console (Chromium).

When the toggle value is No (false, 0) the html looks like this:

In SF 3.2[edit source]

		<div id="showonselect" style="opacity: 0; display: none;"><b>1</b> Some text.</div>
		<div id="showonselect" style="opacity: 0; display: none;"><b>2</b> Some text.</div>
		<div id="showonselect" style="opacity: 0; display: none;"><b>3</b> Some other text.</div>
		<div id="showonselect" style="opacity: 0; display: none;"><b>4</b> Some other text.</div>

In SF 3.4[edit source]

		<div id="showonselect" style="opacity: 0; display: none;"><b>1</b> Some text.</div>
		<div id="showonselect"><b>2</b> Some text.</div>
		<div id="showonselect"><b>3</b> Some other text.</div>
		<div id="showonselect"><b>4</b> Some other text.</div>

Is this behaviour intended or is this a bug? Thanks. --Felipe (talk) 10:06, 17 November 2015 (UTC)

I'm not sure if it's a bug or not... though it's obviously not ideal. It's really my fault for having made "show on select" use IDs, not class names. You're not supposed to have more than one element with the same ID on the page, so HTML like this example is invalid, even though it's a practical solution. I think the JS code is now more sensitive about stuff like that. I would give each div its own ID, and then add a clause to the "show on select" value for each one of them - you can do that. Yaron Koren (talk) 17:06, 18 November 2015 (UTC)
Ok Yaron, I am able to give each element in the form its owns ID. This works fine with properties of the type Text but it does not seem to work when a property is of the type Boolean. I changed the example to show what is happening when you edit this page you will see what I mean. Thanks, --Felipe (talk) 19:49, 18 November 2015 (UTC)
Yes, that's true - I never thought about the need to have multiple elements for a checkbox. I just checked in some changes to the code that hopefully fix this problem. Yaron Koren (talk) 17:28, 19 November 2015 (UTC)
Tested SF master at home and now it is working. Thanks, --Felipe (talk) 18:41, 19 November 2015 (UTC)

Semantic Form Permission Problem[edit source]

Hi, I am working on a closed wiki which uses semantic forms. One of the form fields, which is expecting a URL and sets a property of "homepage" is causing a problem. When a non-administrator tries to edit the URL field they get a red modifying failed error, when an administrator tries to do exactly the same think it work perfectly. The "homepage" property is set as having type URL. I am not sure how best to debug this issue. The wiki is currently using mediawiki 1.25.1, semantic mediawiki 2.2.2 and semantic forms 3.3.1 Thanks --Jpadfield (talk) 16:40, 18 November 2015 (UTC)

What's the exact error message? Yaron Koren (talk) 17:00, 18 November 2015 (UTC)
The only error that appears on the actual page is "Modifying PAGENAME failed". in red above the form. Click edit with form, fill in URL field, click save, user is returned to the edit with form page with the red "Modifying PAGENAME failed" error below the title and above the first form field. Where else should I look for errors ? --Jpadfield (talk) 17:22, 18 November 2015 (UTC)
Alright. I would look in the JavaScript console, if you know how to do that. Yaron Koren (talk) 17:30, 18 November 2015 (UTC)
There are no javascript warnings or error in current version of chrome --Jpadfield (talk) 17:50, 18 November 2015 (UTC)
That's very strange. Are you sure it's only the URL field that causes problems? And does it fail for every value for regular users, and succeed for every value for admins? Yaron Koren (talk) 18:18, 18 November 2015 (UTC)
The other fields in the form (text, textarea and date) are all fine and do not cause any problems for users, these fields link to pages and simple values and they also define a range of properties. When it comes to the URL field:
  • Admin users: can enter/edit a URL value using the form or source without error.
  • Normal users can enter/edit a URL value on the source page without error.
  • Normal users can not enter/edit a URL value using the semantic form - this leads to the red "Modifying PAGENAME fails." error.
  • If an URL has been previously entered by and admin or through the source, a normal users can use the form to edit any of the other fields, without error as long as they do not alter the URL value. If they edit the URL value it again fails with the red error.
  • Normal users can delete existing URL values, using the form, without error, as long as they do not enter a new one.
I have a bit more information, it seems that if a web address, such as http://www.mediawiki.org is entered into any of the other fields, just as simple text, with no extra formatting, the form also fails. So the problem is something to do with how the forms structure parses URL strings. Other internal wiki links work fine as I have: $smwgLinksInValues = true; entered in the LocalSettings, it is just the URL sting http://www.mediawiki.org or [http://www.mediawiki.org] that causes the error and again only for normal users, admin users can add URLs in any of the fields without the error.
Thanks for this detailed research; this is very helpful. One more question: can you try using the very latest SF code and see if the problem is still happening? You're using code from a few months ago. Yaron Koren (talk) 15:25, 19 November 2015 (UTC)
The wiki is a live project wiki that shares code with several other wikis so I need to be careful about updating, I have run some tests though and should be able to update it soon. --Jpadfield (talk) 15:33, 19 November 2015 (UTC)
So far, upgrading to the latest versions seems to have solved the problem, sorry for any inconvenience, and thanks for the responses. --Jpadfield (talk) 13:13, 20 November 2015 (UTC)
That's great! I don't know what would have solved this problem, but there have been a lot of changes. Yaron Koren (talk) 14:21, 20 November 2015 (UTC)

Spreadsheet-style editing of a table of values[edit source]

Hi! In the slides from SMWCon Fall 2015, a future feature referred to as "Spreadsheet-style editing of a table of values" was mentioned. This is very interesting! Is there a place other than watching the git log where the eventual implementation of this feature can be followed? Also, do you have a rough idea of when you think it would see the light of day? It's not out of the question that I might be able to encourage the schedule with a bit of bounty. --JosefAssad (talk) 11:15, 23 November 2015 (UTC)

Yes, that would be a great feature to add. In addition to the Git log, you can also check the features list of each new version - versions lead to an update of the "Version history" page, and are announced with an email to the semediawiki-user mailing list. I have no idea when it would be implemented; I have no specific plans to work on it. Possibly in the next Google Summer of Code (i.e., next summer), but that's just one possibility. An offer of funding could certainly help speed the process along, whether it was me implementing it or someone else. Yaron Koren (talk) 14:07, 23 November 2015 (UTC)

Error: operator for the virtual field tableName.fieldName must be 'HOLDS' or 'HOLDS LIKE'.[edit source]

After adding cargo table= and cargo field= to field for a form, the two cargo fields that take lists gave ""Error: operator for the virtual field TableName FieldName must be 'HOLDS' or 'HOLDS LIKE'. When I removed the cargo table= and cargo field= the error went away.--Cody3647 (talk) 17:29, 23 November 2015 (UTC)

I just tried that - it doesn't happen for me. (With a Cargo field that holds a list of values, which I assume is what you have as well.) What versions of SF and Cargo are you using? And what other parameters are in that "field" tag, if any? Yaron Koren (talk) 19:28, 23 November 2015 (UTC)
Mediawiki: 1.25.3 and Cargo: 0.10 and Semantic Forms: 3.4. One of the fields was: field|children|input type=textarea|cols=20|autogrow|placeholder=Separate names with semi-colons(;). No need to link names, they are automatically linked.|cargo table=Characters|cargo field=children --Cody3647 (talk) 03:34, 29 November 2015 (UTC)
You should try upgrading to the latest SF version, 3.4.1. Yaron Koren (talk) 13:52, 29 November 2015 (UTC)

multiple-instance and file-upload[edit source]


with an Update to MW 1.25.2, SMW 1.9.2 and SF 3.4 I got the problem, that the "upload"-Button for file-upload inside a multiple-instance-template disappeared. Outside the multiple-instance it works fine.

Any solution?

Thanks in advance!

Could you try using the very latest SF version, 3.4.1? There's a chance that whatever problem you're seeing has been fixed. Yaron Koren (talk) 18:40, 25 November 2015 (UTC)

Pipes in free text input not allowed?[edit source]

Typical free text input example at the end of a form {{{standard input|free text|editor=wikieditor|rows=25}}}.

The problem is that with SF 3.4.1 we get the following message "|" is not allowed, except within {{...}} or [[...]] when there is a table in the free text input. This means you can not save a page with a pipe in the free text input. Reading this I assume that it applies only to the field inputs and not for the free text inputs. Is this a bug or did I miss something? Regards, --Felipe (talk) 13:45, 27 November 2015 (UTC)

Are you using the latest version of SF? The free text thing was a bug in an early version of 3.4.1. Yaron Koren (talk) 14:44, 27 November 2015 (UTC)
I am now, and it works. I got the latest version from GitHub, git.wikemedia.org is still down. I was also send to the wrong conclusion because of PHP Caching (OpCache). Thanks and have a nice weekend. --Felipe (talk) 15:30, 27 November 2015 (UTC)

Partial forms no longer update target templates[edit source]

Hello everyone. We're trying to migrate our system to a new version and are running into an issue where a form defined as partial form no longer changes a target page. We've done some digging and have found:

  • creating a new page, or editing a page where the target template is not present is no problem. The code is created with the correct input values.
  • editing a page in which the template is present and already has a value will not update the template to the new input values upon saving.
  • removing partial form from the info-tag gives us expected results: The input is saved, but the code is also moved to the top of the page.

We're going from MW 1.16.5 SMW 1.6.2 SF 2.2.1 to MW 1.25.1 SMW 2.3.0 SF 3.2

I've tried updating to SF 3.4.1 on our testing environment, however, this did not change the behavior. Unfortunately we really depend upon this feature, unless there are other ways to write to the middle of a page with a form without screwing up the whole layout. We now think it might have something to do with user permissions, however no error messages are identifiable in the logs. Any ideas would be greatly appreciated.

Partial forms have not really been supported in a long time - actually, I'm surprised that they worked for you with SF 2.2.1. Assuming the pages you're dealing with have the standard structure of template calls, then free text, what I would recommend is to change this partial form to a "pseudo-partial form". A "pseudo-partial form" has the same set of templates as as the main form for a page, but simply doesn't include fields for one or more templates; so the form may include lines like "{{{for template|TheMainTemplate}}}{{{end template}}}". Does that make sense? Yaron Koren (talk) 19:52, 27 November 2015 (UTC)