Extension talk:Page Forms/Archive October to December 2015

Scemantic doesn't understand my tag as a template when content includes a link

I have created :

• an attribute called : "Notes"
• a template called : "Notes" with this content

  [[Notes::{{{Notes|}}}]]

• a form with :

{{{for template|Notes}}}
{{{field|Notes|input type=textarea|rows=5|maxlength=5000}}}
{{{end template}}}

• Then, when I edit the form, when I leave the field empty, I see nothing (that what I want).
• When I enter some texte, i see my text (No problem here, that what I want too.
• But when I enter a link in my text I get :

  [[Notes::My link]]

But, after some investigation, I realized that when I change my template for : {{{Notes}}} (so I removed the hooks) I get :

• If I leave the field empty, I see {{{Notes}}} (which it shoudn't... it should be empty)
• And when I enter a link in my text I get my link (that what I want).

So, to sum up: if I use [[Notes::{{{Notes|}}}]] or {{{Notes}}} in the template the results will be deferent if I enter a link in the filed...

Do you know what I do wrong ? Thanks a lot Clément

Hi - first, new sections should go at the bottom of the page, not the top. Also, this is an SMW question, not a Semantic Forms question. But I think just adding "$smwgLinksInValues = true;" in LocalSettings.php will fix the problem. Yaron Koren (talk) 18:17, 9 December 2015 (UTC)

Scemantic search for a page with number type property doesn't work

Hi,

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)

Editable-grid input (jqGrid?)

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

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}}}

and

{{{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'

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

Hi Yaron,

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

{{{for template|evaluation}}}
{|
|-
{{EvalYesNo|01|topic1}}
|-
{{EvalYesNo|02|topic2}}
...

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

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

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

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 :) --212.103.80.194 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 ?

Is it possible ?

Thanks

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

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.

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

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

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'

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

<tr>
	<td> 
		<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>
	</td>
	<td> 
		<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>
	</td>
</tr>

In SF 3.4

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

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

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)

I think I know what might have happened! Page saving may had been blocked by Extension:SpamBlacklist. This happend to me. I had a perfectly working form and when I tried to add a certain new page I got this "Modifying PAGENAME failed". After numerous experiments with the form itself I gave up and since I needed to save that page, I went the manual way, to fill in the template fields via code edit. And it was then that MediaWiki showed an error message that saving had been blocked due to the spam blacklist! And it also told me which url was the blacklisted one (I couldn't have figured this out myself because template used values gathered from an external web API via the External Data extention, hence the blacklisted url). So what I did was to go and put this url into MediaWiki:Spam-whitelist and that solved the problem! I then tried to save with form again and it worked!

Maybe it would be a good idea if the form could show this MediaWiki/SpamBlacklist error somehow, if possible.

--Ioannis Protonotarios 02:48, 21 December 2015 (UTC)

Spreadsheet-style editing of a table of values

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'.

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)

Updated and doesnt seem to be giving me the error anymore. --Cody3647 (talk) 21:03, 2 December 2015 (UTC)

multiple-instance and file-upload

Hi,

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?

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

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)

lose page data when rearranging for_templates in semantic form

I'm still learning so not sure if this is somewhat intended/known behavior or if I'm doing something wrong. I created a fairly complicated form with Page Schemas, and have since moved to more fine tuning directly in form/templates. I have lots of different types of info like project identification, details, and some with multiple instance templates like contacts and status updates, so I separated these out into individual templates and split them up in the page with 'hidden' sections for headings (is this typical, not sure how should be done otherwise to get section headings on resulting pages).

Anyways, I've got a few sample pages and realize that I should move one of my sections further up the page, otherwise it get buried after a long list of status updates. The problem is getting this to take effect on resulting pages. If I edit the form to rearrange, and then edit the page I lose data from that section/template. The beauty of these semantics rather than my own database solution is the dynamic nature and automation, so I thought it should just parse for that section and repopulate data in new spot. Re-inputing data won't be acceptable to my users. Am I doing something wrong or misunderstanding? Thanks. --Kc5vcx (talk) 19:50, 8 December 2015 (UTC)

I don't know; I'd have to see what you did. Why do you have hidden sections? If the goal is to display a section header on the page, can't you just add that in to the template? Yaron Koren (talk) 19:54, 8 December 2015 (UTC)

Possibly, except for the case of multiple instance templates, like for instance status updates. I'd like to have a header for them all collectively, not in each and every one. --Kc5vcx (talk) 20:00, 8 December 2015 (UTC)

Well, you could use another template just to display the section header; or you could embed that multiple-instance template in another template, which (besides other things) would display the section header. I think both of those are a better solution than having a hidden section; especially if you ever want to change the name or display of that section header. Yaron Koren (talk) 21:17, 8 December 2015 (UTC)

Makes sense, and maybe would clear up my problem. Do you have an example? It's not clear how to define this within a form (the template holding a multiple instance template). --Kc5vcx (talk) 21:53, 8 December 2015 (UTC)

This hopefully explains how to do it. Yaron Koren (talk) 00:24, 9 December 2015 (UTC)

Thanks, now I realize what I've been missing, and fixes my issues. I also found this example. --Kc5vcx (talk) 01:41, 10 December 2015 (UTC)

multiple instance templates after section

I mentioned this over on Page Schemas talk page, but would like to bring it back up here, and it sort of relates to my above topic. I'm facing the same issue as described in the archive Multiple_Instance_templates_directly_after_section, and wondering if it was fixed. My workaround has been to enforce a minimum of 1 for multiple instance templates, but this isn't really clean when that data isn't relevant. Was the original suggested work-around to use another template that would just create the section heading by passing a title in as a parameter? Thanks. --Kc5vcx (talk) 19:57, 8 December 2015 (UTC)

The above (embed in field and holds template) resolves this issue for me, and no longer need a minimum instance. However, it just allowed me to remove the (hidden in my case) section so I can't actually confirm it's fully fixed. --Kc5vcx (talk) 01:45, 10 December 2015 (UTC)

That's great! My guess is that it's not fixed. Yaron Koren (talk) 02:43, 10 December 2015 (UTC)

<page name> variable for uploadable fields

I've discovered to make that page name variable be substituted correctly I had to enter: &lt;page name&gt;

So a real example (which works):

{{{field|CV|uploadable|default filename=CV for &lt;page name&gt;}}}

Thanks for a great tool, Andrew Ruthven

That's not good; I'll have to look into that. Yaron Koren (talk) 03:17, 20 December 2015 (UTC)

Date Inputs Changing When Opening Form

Opening a form to edit a page, the dates in a date input on a second (and last) instance of a multiple instance template are changing from the month/year they were to January 1970 overwriting the existing values. The Cargo field is a date type and the input type is date. I recently finished our move from SMW to just Cargo as well. Im not sure if the problem started before that or after.

• Mediawiki: 1.25.3
• Cargo: 0.10 (394e616) 07:53, December 14, 2015
• Semantic Forms: 3.4.1 (6c6dee4) 15:24, December 15, 2015

--Cody3647 (talk) 21:05, 19 December 2015 (UTC)

Is this on a public wiki? If not, could you pastebin the form, template and a page where you see this happening? Yaron Koren (talk) 03:16, 20 December 2015 (UTC)

Should be able to view sources. Form, Main Template, Sub-template:Occupation, Sub-template:Relationship, example. The example page its happening the last instance of the relationship template, but Im pretty sure its happened with both sub templates as they both have dates. Thanks, --Cody3647 (talk) 07:27, 20 December 2015 (UTC)

Okay, great. This sounds silly, but I think the issue is that you need to uppercase all the type declarations in #cargo_declare within that template (in all the templates, really) - "date" should be "Date", etc. Right now, these are all just stored as text values. (Which probably also explains why you needed to set "input type=date", etc. throughout the form.) I don't know why that led to the date values getting wiped out in certain cases, but my guess is that fixing this will make that problem go away. And yes, I should probably make the types case-insensitive. Yaron Koren (talk) 15:12, 20 December 2015 (UTC)

Fixed all of the type declarations. But, the last instance on the example page is still changing to January 1970. --Cody3647 (talk) 17:44, 20 December 2015 (UTC)

I just looked into this. It looks like this is the issue: when SMW is not installed, SF uses PHP's strtotime() to parse the date; and values of the form "YYYY/MM" (like you had in some of your fields) do not get handled by that function; they show up as null, which ends up being displayed as "January 1970" (long story for that one). As long as you use Semantic Forms to set the values, though, it should be fine; SF stores year/month values as "MonthName YYYY", which strtotime() understands. Yaron Koren (talk) 23:30, 20 December 2015 (UTC)

I've tried to set the date with SF, after it got changed to January 1970, but it still gets stored as YYYY/MM and then the next time its edited via the form its back to January 1970.--Cody3647 (talk) 10:16, 21 December 2015 (UTC)

I added $date=str_replace('/','-',$date); right before $seconds = strtotime( $date ); in parseDateNonSMW in SF_DateInput.php. Seems to work, not sure if this is a long term solution but it works for now. --Cody3647 (talk) 13:24, 22 December 2015 (UTC)

This turned out to be a bug in SF, for wikis that have the combination of SMW not installed, $wgAmericanDates not enabled and month/year-only dates. The fact that the YYYY-MM format gets parsed correctly is a good find; I didn't know that. I ended up getting SF to just always print out such dates as "MonthName YYYY". If you upgrade to the latest SF code, it will hopefully all work. Sorry for the problems, and thanks for your help. Yaron Koren (talk) 21:07, 22 December 2015 (UTC)

Its all working correctly now. Thanks. --Cody3647 (talk) 22:43, 23 December 2015 (UTC)

Problem with "wpRunQuery=true"

Re:

You can also link to 'Special:RunQuery' where the query has already been run. To do that, just add "wpRunQuery=true" to the query string; see here for an example.

(from Extension:Semantic Forms/Creating query forms)

I recall that this was working in earlier versions of SF, but the linked example from discoursedb.org and an additional test I did for comparison seem to show that this is no longer the case. Cavila 19:52, 20 December 2015 (UTC)

That link looks fine to me - the query is indeed run. Yaron Koren (talk) 20:42, 20 December 2015 (UTC)

The URL suggests that two form fields for the ItemQuerier template should be prefilled: "A" in the "author" field and "New" in the "source" field. Instead, the fields come up empty and and there is no sign of any query string being used. Cavila 21:19, 20 December 2015 (UTC)

Ah, yes. The template name changed - I just updated the URL, so now it looks like it works fully. Yaron Koren (talk) 23:17, 20 December 2015 (UTC)

Great, that's one thing sorted. Now that just leaves me wondering why my test example didn't work - will look into that. Cavila 20:58, 21 December 2015 (UTC) [Update:] Got it! The square brackets in the url string need to be 'urlencoded' or else that string gets truncated. That's why my test didn't succeed. Cavila 09:38, 28 December 2015 (UTC)

Allow Special:RunQuery to Output Custom Extension Results

Tried to post in the developer's mailing list but got rejected as spam.

We use SF to generate some highcharts output (through a custom tag extension) based on SMW properties, but Special:RunQuery won't fire up the extension unless this little wfRunHooks line is added to SF_RunQuery.php around line 150. Once there everything works perfect.

// Now write everything to the screen. 
wfRunHooks( 'OutputPageBeforeHTML',array( &$wgOut, &$text ) );   //Added this line
$wgOut->addHTML( $text ); 

A local IT contractor got this to work for us using the above. I don't know if this is the right list on which to mention it. I'm curious to know if there's a problem with this adjustment/hack and whether it should/could be included into SF_RunQuery.php (blow up other things, security etc.). I'm not a developer and have no idea how to 'commit' such a contribution. - Lbillett (talk) 16:05, 21 December 2015 (UTC)

This is a good place to ask. I would rather not include that hook, because calling core MediaWiki hooks from within extensions can lead to strange behavior (in this case, stuff being displayed in Special:RunQuery that's meant to only show up in regular pages). So an SF-only hook would be better. Thankfully, though, there are already a lot of these - see here for the complete list. Is it ResourceLoader modules that are added with that hook? If so, having that custom extension use the "sfAddResourceLoaderModules" hook might do the trick. Yaron Koren (talk) 18:30, 22 December 2015 (UTC)

Ah, sounds like it. It believe it is resourceloader related. At least, I know our extension uses resourceloader to set up which js to make available. I'll see about how to incorporate sfAddResourceLoaderModules on that side. Sounds much more appropriate. Thanks a ton. - Lbillett (talk) 14:30, 30 December 2015 (UTC)