Extension talk:Page Forms/Archive April to July 2016

Adding a subcategory in the URL

Hi, this is probably an easy one to solve but I can't find the documentation. I would like to create a form that will create a new page under a specific (sub)URL.

For exemple :

• Creating the page Wood using the form form:species
• Will create a page with the URL : /index.php/species/Wood

Thanks. ClemFlip (talk) 16:54, 4 July 2016 (UTC)

That's a subpage, not a subcategory - you can do that by adding "|super_page=species" to either the #forminput or #formlink call, depending on which one you're using. Yaron Koren (talk) 04:26, 6 July 2016 (UTC)

Thanks. ClemFlip (talk) 11:43, 6July 2016 (UTC)

Extension:Translate and Semantic Forms

Hi, we would like to use the Extension:Translate to allow translations of pages created with forms. But we are having troubles and I would like to understand if Semantic Forms is compatible with this extension.

First, we can't insert the <languages /><translate></translate> tags in templates in order to automatically embed the strings / value in field that will be translatable.

The only way to use Extension:Translate with Semantic Forms is to, once a page has been created thought the form, go to the edit page "&action=edit" and add manually the <languages /><translate></translate> tags.

Then, we can't translate Property. Well, in fact it's possible to translate a Property page but when I go to a page that use a property and I switch language, system says that the translated words doesn't belong to the list of authorized values. For the system, only the original values (untranslated) are authorized.

Do you confirm that or is there a doc that I haven't seen? Thanks a lot. ClemFlip (talk) 13:38, 22 April 2016 (UTC)

I've never tried using Translate and Semantic Forms together, so there's not much I can contribute here. Maybe someone else reading this knows more. I will say that in part this is also a Semantic MediaWiki question; and more generally, it's an issue inherent to these extensions, in that none of them were designed to work on multi-lingual sites (that's part of why a new extension, Wikibase, was needed in order to power Wikidata). I do think that the handling needs to be different for fields that have a set list of allowed values, vs. those that can take in any sort of value. But I haven't really looked into any of it. Yaron Koren (talk) 19:02, 22 April 2016 (UTC)

Multiple instance forms for long tables

We are using a multiple instance template to add rows to a table. The table has 17 columns, so the form fails at around row 62 - assuming due to the php field input limit of 1000. This limit, along with the fact that loading time for the form get long after 20 or 30 multiple instances or so, suggests Semantic Forms may not work for this use case (managing large tables). We can't split information across multiple pages.

Could something like this work: a query-based display page (Cargo) that calls a single instance form for each row of the table, showing in a pop-up, so that each row is stored semantically as individual page in the background, but the person using the table never sees it. Maybe include a button/action in each row to "edit row", and another for "delete row". I think I can see how editing rows might work, I don't know about deleting them.

The goal obviously is a better UI for maintaining mediawiki tables. We can't use Visual Editor right now due to our custom skin. We would prefer to keep content stored in the wiki (as opposed to just pulling, say, Google Docs onto the page) so that we can use our draft/published control and permissions scheme (supplied by Ponydocs Extension).

Anyone have a magic solution we haven't thought of yet?

--Bgrenon (talk) 12:57, 13 April 2016 (UTC)

There's actually a new feature coming in SF 3.6 that might make the handling of large tables more doable - spreadsheet-style editing. 3.6 will hopefully get released in the next few weeks, so that might be worth trying out. On the other hand, I don't know how well it would display on the screen, with 17 columns. Unfortunately, there's no way to isolate a single instance of a multiple-instance template in a form. Why wouldn't the multiple-pages thing work? Yaron Koren (talk) 15:28, 13 April 2016 (UTC)

The spreadsheet editing feature is fantastic. Is there any drop-down functionality available for it? The documentation mentions if there are multiple values, you'll get a dropdown, but I can't get that to work (using text or checkbox or unspecified input type). (--Bgrenon (talk) 13:26, 13 June 2016 (UTC))

Yes - the easiest way to get a dropdown to appear is to add a "values=" parameter. Yaron Koren (talk) 16:50, 14 June 2016 (UTC)

Thanks for the response. This is not working for us (text field and checkbox only, no dropdown). It may be a conflict between our custom skin and SF css. That's where we'll look next anyway. --Bgrenon (talk) 14:17, 16 June 2016 (UTC)

Undesired effects of query form on page title and section headers

Using a query form in a page started to have undesired effects after updating Semantic Forms.

I have a page Sandbox with the following code:

 = a =
 == aa ==
 === aaa ===
 {{Special:RunQuery/QueryAuflage}}
 

The page title (first line in the page) is displayed as Spezial:RunQuery/QueryAuflage instead of Sandbox and the section headers are displayed as UNIQ70028b3423b19709-h-0--QINU a, UNIQ70028b3423b19709-h-1--QINU aa, and UNIQ70028b3423b19709-h-2--QINU aaa.

(MediaWiki 1.21.2, Semantic MediaWiki 1.8.0.4, Semantic Forms 3.6-alpha) LambdaB (talk) 12:58, 14 April 2016 (UTC)

Hi LambdaB, this is a known issue and one for which there is no fix I'm afraid. Best advice is to ensure that any embedded query form comes first in the page's syntax. You can sort of cheat around this though by using CSS to lower the embedded form. Cavila 19:03, 26 May 2016 (UTC)

Size in percentage for text input boxes?

This is admittedly a request, but would it be possible to make the size parameter for text input boxes to be a percent of the container rather than number of characters (or to have that option)?

The reason I ask is that I have such a pain trying to edit the CSS appropriately for these, especially if I'm trying to build multiple instance templates. Character numbers are quite difficult to work with for different browser window sizes or anything responsive. If I'm missing an easy trick, I'd love to hear that also of course.

Thanks for the consideration! --Joshkking (talk) 14:13, 16 April 2016 (UTC)

It would be nice if there were a way to do that directly, although you can instead use the "class=" parameter, and set the width in the CSS. Although maybe you knew about that one, given that you mentioned CSS. Have you tried this? If so, what's the difficulty? Yaron Koren (talk) 13:23, 17 April 2016 (UTC)

Multiple loading of SemanticForms Extension

During initial setup using index.php (when LocalSettings.php is absent), if you choose the SemanticForms extension, the setup will add two lines

wfLoadExtension( 'SemanticForms' ); require_once "$IP/extensions/SemanticMediaWiki/SemanticMediaWiki.php";

The first line ```# wfLoadExtension( 'SemanticForms' );``` should not be included or it checks for certain things (version, flags, etc) that it should abort loading.

I encountered this issue

Call to a member function exists() on a non-object in /<snip>/extensions/SemanticForms/specials/SF_FormEdit.php on line 273

After I commented the first line, its work fine now.

Yoonghm (talk) 06:00, 17 April 2016 (UTC)

What setup process are you using? I didn't know there was a MediaWiki setup process that also added extensions. Yaron Koren (talk) 13:20, 17 April 2016 (UTC)

Enable links to forms

I followed the instructions of your example in the quick start guide exactly. This works great. After I altered the template as described in the 'enable links to forms' section, something strange occurs.

When you create a new book, the values of Genres are stored in the Authors field and those of Authors in Genres. Why is that?

--C Wagner (talk) 08:37, 18 April 2016 (UTC)

Where is the error - in the underlying wikitext, in the display of the page, or in the values stored by Semantic MediaWiki or Cargo? Yaron Koren (talk) 16:44, 18 April 2016 (UTC)

The error is visible in the wikitext, the display of the page and in the values stored by Semantic MediaWiki. C Wagner (talk) 14:16, 3 May 2016 (UTC)

Great - it sounds like the error is in the form. Could it be that, in the form, you have something like "Authors: {{{field|Genres}}}", i.e. the wrong labels for the fields? Yaron Koren (talk) 15:05, 3 May 2016 (UTC)

No that's not the case. In Form:Book there is "Authors: {{{field|Authors}}}" C Wagner (talk) 10:48, 4 May 2016 (UTC)

Alright. Could it be that you just entered the data in the wrong fields when filling out the form? Yaron Koren (talk) 13:51, 4 May 2016 (UTC)

I reinstalled again and the problem seems to be gone now. Thanks anyway. C Wagner (talk) 11:53, 3 June 2016 (UTC)

Error using datepicker

When I use the datepicker input type, I get the following error:

Warning: OutputPage::getModuleStyles: style module should define its position explicitly: jquery.ui.datepicker ResourceLoaderFileModule [Called from OutputPage::getModuleStyles in /w/includes/OutputPage.php at line 623] in /w/includes/debug/MWDebug.php on line 300

Using:

• MediaWiki: 1.26.2 (f465524)
• PHP: 5.6.20 (cgi-fcgi)
• Semantic Forms: 3.6-alpha (77c4a3b)

Jaider ^msg 18:31, 22 April 2016 (UTC)

Sorry for the long delay. This is due to a MediaWiki bug - I just added a note about it (including a fix) here. Yaron Koren (talk) 18:54, 28 April 2016 (UTC)

Thank you, Yaron. Do you know if there is an open bug report on Phabricator to follow up on this issue? Jaider ^msg 23:20, 2 May 2016 (UTC)

No idea. I actually don't even know if the error still shows up in MW 1.27 - I seem to remember that it doesn't, but I could be wrong about that. Yaron Koren (talk) 00:13, 3 May 2016 (UTC)

Spreadsheet mode with combobox

The new spreadsheet-style editing approach is really nice, but it's missing combobox support. Are you planning to add it?

It would be great to have autocompletion within the spreadsheet display, but I have no specific plans to add it. It would require custom JS programming - how much of it, I don't know. Yaron Koren (talk) 16:04, 18 May 2016 (UTC)

Force unnamed parameter for template?

Hi,

is there a way to force unnamed parameters to always be printed out? By the way I did not find any section for the sfg... configuring variables. --Andreas P. 09:19, 24 May 2016 (UTC)

Do you mean print something like "1=ABC" instead of just "ABC"? I don't think so. The documentation for the $sfg global variables is scattered around in different sections - perhaps there should be one central list of them. Yaron Koren (talk) 14:39, 24 May 2016 (UTC)

"1=ABC" instead of just "ABC"? yes. With SF 3.4.1 there is the problem: adding an equal sign into the form field, e.g. "ABC=lorem ipsum" to an unnamed template parameter it does not transform to "|1=ABC=lorem ipsum" but to "|ABC=lorem ipsum", which distorts the template structure --Andreas P. 22:56, 24 May 2016 (UTC)

That's true. Why not just give the fields names, then? Yaron Koren (talk) 00:34, 25 May 2016 (UTC)

Well I guess I understand what you're pointing at, but I'd like the extension to take care of it to transform (always) to the unnamed parameter, e.g. "|1=lorem ipsum" --Andreas P. 08:27, 25 May 2016 (UTC)

That's a fair point; I guess the real solution is for the form to add the number if the value contains an equals sign? Yaron Koren (talk) 11:43, 25 May 2016 (UTC)

Autocomplete glitch

Thanks for the SF 3.6 release, Yaron and everyone else who made this possible. One thing I noticed is that autocomplete did not work properly on pages in a namespace other than the 'main' one - using textarea with autocomplete: the dropdown only shows me possible values when the namespace prefix has been entered. More specifically, it is just the first word of a value (after the prefix) for which this issue exists. Say, for instance, that there is a page called "Wiki:Cars for rent". No matching values are found if the user types "Cars", but things are okay if he/she types "Wiki:Cars" or "for" or "rent". I don't think I've seen this using SF 3.4. Cavila 18:57, 26 May 2016 (UTC)

That's odd. Is "Wiki" (or whatever the text you're actually using is) a "true" namespace? If you go to the talk page for that page, does its title look like "Wiki talk:Cars for rent", or "Talk:Wiki:Cars for rent"? Yaron Koren (talk) 11:32, 29 May 2016 (UTC)

It certainly is, even though it is a custom namespace (with SMW enabled) and I did not create a talk page to go along with it. Perhaps I should also mention that $wgCapitalLinkOverrides has been set to 'false' for this particular NS and pages in this NS are not viewable by anonymous visitors. If I replace 'values from concept=...' with 'values from namespace=...', I do get results but they are shown without the namespace prefix. Cavila 19:36, 30 May 2016 (UTC)

Oh... you didn't mention that this was for "values from concept". That explains it. I think this behavior has been in place since the beginning, although it's not ideal - hopefully I or someone else can fix it. Yaron Koren (talk) 20:18, 30 May 2016 (UTC)

Looking back, I think it did work in 3.4, if only to an extent because not all values were retrieved from the DB. Anyway, I've had more luck trying an alternative approach, which is to switch to "tokens" and use a mapping template to strip away any namespace prefix. As far as I can tell, that seems to do it (!), although "tokens" isn't my preferred choice of input. Cavila 08:11, 24 June 2016 (UTC)

Autocomplete does't work

Confirm this bug in namespace (V. 3.6 (c7c5c0e)), autocomplete doesn't work in most fields. 3.4. works fine. Any help for this? Thanks a lot. --Tom Jac (talk) 11:16, 25 July 2016 (UTC)

Is this happening for fields that use "values from concept"? Otherwise, it's a separate issue. Yaron Koren (talk) 12:14, 25 July 2016 (UTC)

No. Here an example: {{{field|Author|input type=text with autocomplete|size=40|placeholder=Surname, Forename}}} (own wiki) Thanks a lot. --Tom Jac (talk) 06:37, 27 July 2016 (UTC)

Okay, this is unrelated. There could be any number of things going wrong; one possibility is that the form doesn't know where to get the values from. Assuming the autocompletion values are supposed to come from either SMW or Cargo, you should add either "property=" or "cargo table=" and "cargo field=" parameters to the field tag, to make it explicit. Yaron Koren (talk) 12:46, 27 July 2016 (UTC)

Like this? {{{field|Author|input type=text with autocomplete|property=Author|size=40|placeholder=Surname, Forename}}} - doesn't work. The problem has existed for the last updates. Previously everything worked. The crazy thing is that other fields with the same parameters are still working. Using a German localisation. --Tom Jac (talk) 14:28, 27 July 2016 (UTC)

Thanks a lot for fixing this! -- Tom Jac (talk) 17:44, 15 August 2016 (UTC)

Randomizing letter combinations

With the one-step process for form creation, one can create the page title automatically during the creation of the form. There is the option to randomize numbers and adding letters to this number combination in a format like "abc12345", e.g. BBC04385. I would like these letters "abc" also randomized, is there any way to do so? --Zabien (talk) 17:12, 1 June 2016 (UTC)

That's interesting - no, I don't think it's possible, and I don't think anyone has asked for this before. What format do you want the random string to be - always three letters and five numbers, or something more random? And why? Yaron Koren (talk) 17:31, 1 June 2016 (UTC)

I would love to have the choice! I like the usage of something like <unique number; start=0000001> or <unique number;random;7>. But as far as I know, a page title cannot start with a number ("due to a bug in SF"), so one would have to add a letter combination in the beginning (page name= abc<unique number; start=0000001>). Letters exponentiat by 26, numbers only by 10, so the random combination would simply be shorter when it's also including letters.

Of course it can't be something like <unique letter> to use it like <unique letter><unique number>, this surely wouldn't work easily. But could it not simply be defining an entire string by letter positions? (Something along this, general this.) It thought there'd be a parser function for these string calculations, but can't find it. The freedom to work with combinations like "abc12345abc" or even wilder would also be possible – though I agree their usefulness would be hard to argue for.

I'm guessing that that SF bug still applies even if the random number/string starts with a letter and not a number, unfortunately... though I could be wrong. But if there indeed is an advantage to having letters in there, I think this would have to be done via a hook - i.e., a hook gets added to the relevant function in the SF code (makeRandomNumber()), and then some outside code gets added that creates its own random string according to its own rules. I could take care of adding the hook part. Yaron Koren (talk) 20:17, 1 June 2016 (UTC)

Sounds good! :)) --Zabien (talk) 16:47, 3 June 2016 (UTC)

Popup - Idle-Symbol doesn't disappear

Hi Yaron and thanks for the great work on Semantic Forms. I just have one little issue: after creating a record with a SemanticForms popup, the record is stored. This is fine. But the idle symbol from the popup doesn't disappear after clicking the save button. When I refresh the browser I'm back on the articel from where I called the Popup. I'm using:

• MediaWiki 1.26.3
• Semantic MediaWiki 2.3.1
• Semantic Forms 3.6
• PHP 5.5
• MySQL 5.5

Also in the JavaScript console there is no error. Do you have any ideas?

Thanks in advance. --DirkCogno (talk) 15:50, 6 June 2016 (UTC)

Do you mean this image? Are you sure it's supposed to appear after hitting "Save"? I only remember it displaying when the popup form is being loaded. Yaron Koren (talk) 14:08, 6 June 2016 (UTC)

Yes, exactly this image. It really appears after hitting "save". --DirkCogno (talk) 16:36, 6 June 2016

Have the some problem with SF 3.2 sometimes. In some cases i get a small window (1x1 cm²) with the only content "undefined". No hints at JS Console. With SF 2.7 everything works fine. With 3.6 popup i have the problem, that empty mandatory fields are not recognized. --SnowlDD (talk) 17:31, 6 June 2016 (UTC)

Sorry about these problems. Thankfully, I was able to reproduce the issue on my own wiki - I guess I just haven't tried out popup forms in a while. Anyway, I just checked in what I think is a fix; if you get the latest code from Git, the problems will hopefully go away. Yaron Koren (talk) 02:03, 7 June 2016 (UTC)

Thank you very much. That helps us a lot. :) --DirkCogno (talk) 09:52, 8 June 2016

Combobox mandatory

I'm using combobox in combination with 'values from property' and there doesn't seem to be a way to clear the field after it has been filled before.

This makes it automatically mandatory, which is nog what I had in mind. Is there a way to go around this? --AdSvS (talk) 08:34, 10 June 2016 (UTC)

For a combobox, you just need to click on the top (blank) value in the dropdown to clear the input. Does that not work for you? Or are you asking about something else? Yaron Koren (talk) 11:39, 10 June 2016 (UTC)

Populating a listbox with page names and a property of these pages

We're currently using a form to create a page for different measurements, e.g. temperature tests. In this form, we select the test equipment which was used to perform the test, e.g. a thermometer. Unfortunately, the test equipment is described on pages with IDs as the page title, e.g. TestEquipment:1234. On these pages, there is more information about the test equipment, e.g. type, device name or serial number.

Currently, we only populate the test equipment listbox with the page title (values from category=test equipment). As the page titles are only the IDs of the devices, it is hard to see which device you have selected, you'd have to check the corresponding wiki page to make sure you've got the right one.

Is there any way to display a property, like the name, together with the page name in this listbox? Something like this would be great:

• TestEquipment:1234 (Thermometer TX250)
• TestEquipment:1235 (Humidity Sensor HX3000)
• <equipment-id> (<property 1> <property 2>)

-- Novac1993 (talk) 09:19, 10 June 2016 (UTC)

You probably need to use a "mapping template" - see here. Yaron Koren (talk) 11:41, 10 June 2016 (UTC)

Thank you! I created a new template and added it to the listbox via "mapping property=" "mapping template=". The template looks like this:

<includeonly> {{#ask: [[{{{1|}}}]] | ?Manufacturer= | ?Name= | format=list | link=none | sep= }} </includeonly>

Now, the listbox entries look like my example above. -- Novac1993 (talk) 08:04, 13 June 2016 (UTC)

However, when I save the page with an entry selected, the page will get saved with the displayed string (e.g. TestEquipment:1234 (Thermometer TX250) ) instead of the page name (e.g. TestEquipment:1234). Is there a way to make this behave like the "mapping property" (displayed string != saved string)? -- Novac1993 (talk) 08:13, 13 June 2016 (UTC)

That sounds like a major bug. Did you mean "mapping template" above, by the way, when you wrote 'via "mapping property="'? Yaron Koren (talk) 13:28, 13 June 2016 (UTC)

Whoops, I meant mapping template, yes. The selected list entry is saved just as it is displayed in the listbox (e.g. "TestEquipment:1235 (Humidity Sensor HX3000)" ) instead of the correct value of the field (e.g. "TestEquipment:1235"). -- Novac1993 (talk) 13:53, 13 June 2016 (UTC)

Alright. What version of SF are you using? Yaron Koren (talk) 15:16, 13 June 2016 (UTC)

We're still on MW 1.23.13 with SMW 2.3 and SF 3.4. We're planning to upgrade MW and all extensions as soon as 1.27 is out. -- Novac1993 (talk) 15:37, 13 June 2016 (UTC)

Ah. It's possible that this bug has been fixed already. Yaron Koren (talk) 16:42, 13 June 2016 (UTC)

I'll try this again after the upgrade, thank you for the help! -- Novac1993 (talk) 08:18, 14 June 2016 (UTC)

Just FYI, upgrading to MW 1.27, SMW 2.4.1 and Semantic Forms 3.6 fixed the problem! -- Novac93 (talk) 12:52, 11 August 2016 (UTC)

Great! Yaron Koren (talk) 13:24, 11 August 2016 (UTC)

Default value ignored in field

During updating our test wiki we stumbled on an issue with Semantic Forms. When using the following syntax in a Form {{{field|Defaultvalue1|default=some text}}} the default=some text is ignored. Defaultvalue1 is of the type Text. This is working in SF 3.4.1. Is this a bug or did I miss something in the documentation? See example on the SMW sandbox wiki: http://sandbox.semantic-mediawiki.org/wiki/Defaulttest

We are testing on:

• MW 1.26.3
• PHP 7.0.7
• SMW "dev-master"
• SF "dev-master"
• open-layers "dev-master"

Thanks, --Felipe (talk) 13:04, 10 June 2016 (UTC)

I think it's just because you're editing an existing page - the default value only applies when creating new pages. By the way, it's cool that you're using the OpenLayers extension - I didn't know if anyone had tried that out yet. Yaron Koren (talk) 14:46, 10 June 2016 (UTC)

Hello Yaron, thanks for the quick responds. When properties are added or changed in a template we often set a default value. We do this all the time and as long as I can remember the default value in a form always worked, on new pages but also on existing pages. This is a very powerful feature. Wen adding new properties it is not possible anymore to fill in a default for mandatory fields. What happens in the current situation is that users now need to set all the new fields manually before they can save the page, this is not very user friendly. You can also see this happening in the examples when you try to save the page. In the past you never had the option on a mandatory field with a set default to select "nothing" and now you have this option. This new behavior more or less breaks our wiki. Is it possible to revert back to the old behavior where the default can be used on all pages existing and new? Btw, default=current user is actually working on existing pages :)

As for the Openlayers extension, I believe it got installed when using composer install to get SF master installed but I am not sure. Before only SF was installed but something was wrong because it was very slow. After using SF master and Openlayers everything was working as fast as it should be. But again I am not sure, i will check this next week. Thanks and regards, --Felipe (talk) 08:11, 11 June 2016 (UTC)

Hello Yaron, I made some changes to SF_FormPrinter.php in order to fix the above mentioned problem. These changes also fix the default=now for a date input because it is not working in SF dev-master. I am not sure if what I did is the correct way but it seems to be working fine. See phabricator for details in attached file. --Felipe (talk) 12:05, 13 June 2016 (UTC)

Sematic-forms (dev-master) requires open-layers when installed via composer

It is mentioned in a previous topic but I made a new one to not mix stuff up. When installing SF via composers it requires open-layers to be installed. composer update result:

 Problem 1
   - Installation request for mediawiki/semantic-forms dev-master -> satisfiable by mediawiki/semantic-forms[dev-master].
   - mediawiki/semantic-forms dev-master requires mediawiki/open-layers dev-master -> satisfiable by mediawiki/open-layers[dev-master] 
     but these conflict with your requirements or minimum-stability.

Is this correct? --Felipe (talk) 08:45, 14 June 2016 (UTC)

I don't know much about Composer, but it looks like the addition of the OpenLayers extension as a requirement in SF's composer.json (which somebody else added) was probably a bad idea. Yaron Koren (talk) 16:02, 14 June 2016 (UTC)

It was not done by accident but with a purpose see here. Is this not something that should be in SemanticResultFormats or does SF really depend on OpenLayers? --Felipe (talk) 06:33, 22 June 2016 (UTC)

Yes, I know it was done on purpose. SF can make use of the OpenLayers extension, for its "openlayers" input type, but it probably shouldn't require the extension in Composer. Yaron Koren (talk) 13:41, 22 June 2016 (UTC)

Randomiser ({{{info|page name=Abc-<unique number;random>}}}) broken in SF 3.6?

I'm not sure if it's me but either the page ends up being saved without a number or it isn't saved at all. Is this perhaps a bug specific to 3.6? Cavila 07:41, 27 June 2016 (UTC)

We use {{{info|page name=OP <unique number;start=1>}}} and that works just fine. Also tried {{{info|page name=OP <unique number;random>}}} which also works ok.

We are using SF 3.6 master, SMW-2.4.0-rc1 master and a whole bunch of other extensions on MW-1.26.3. Maybe when you try to isolate the problem by disabling all other extensions. --Felipe (talk) 09:35, 27 June 2016 (UTC)

Yes, this bug was fixed on June 1, so it exists in version 3.6 but not in master. I plan to release a 3.7 at some point soon... Yaron Koren (talk) 13:41, 1 July 2016 (UTC)

Thanks! Cavila 13:45, 1 July 2016 (UTC)

Download Links broken

Actually all download-links (zip + git) under "Download and Installation" are broken. Could you please fix this? Used https://gerrit.wikimedia.org/r/mediawiki/extensions/SemanticForms for git clone. RacingRalf (talk) 08:46, 1 July 2016 (UTC)

Ah, yes - the removal of git.wikimedia.org threw everything off. I just updated the links for SF; now I have to do it for all my other extensions... Yaron Koren (talk) 13:39, 1 July 2016 (UTC)

Thx! RacingRalf (talk) 12:13, 4 July 2016 (UTC)

Download works but installation is broken (extension-semanticforms vs SemanticForms) C Wagner (talk) 10:45, 4 August 2016 (UTC)

Yes, that's true - sorry. I just changed the git clone URL, so if you use this one, the directory should have the right name. Yaron Koren (talk) 14:57, 4 August 2016 (UTC)

Only 1 datepicker is shown in a form

Hello, I noticed that when using SF 3.6, SMW 2.3.1 in MW 1.23.x (PHP 5.4.x) if two datepickers are included in a form, only the first one is shown. --Toniher (talk) 20:53, 8 July 2016 (UTC)

I can't reproduce this problem. Are you seeing any JavaScript errors in the console? And do you have Semantic Forms Inputs also installed, and if so, what version? Yaron Koren (talk) 13:26, 12 July 2016 (UTC)

Spreadsheet-style editing : one empty row is created at every form edit

even if we dont edit the spreadsheet part of the form.

Any has the same behaviour ? have found a workaround ?

Thanks,

Nicolas NALLET (talk) 13:02, 11 July 2016 (UTC)

You found a bug in the handling of spreadsheets - it looks like it was introduced on May 31. Sorry about that. I just checked in what I think is a fix. Yaron Koren (talk) 02:42, 13 July 2016 (UTC)

Error 500 on any Form

Hi, y'all.

Any time I attempt to access anything to do with a Form, I generate an HTTP Error 500. This includes all the Forms special pages, and the forms I've attempted to create manually. I also seem to be missing the #default_form parser hook, though I don't know if that's related or not, and I can't seem to find any info on what to do to get that hook installed on its own anyway. I'm running:

Product Version

MediaWiki 1.27.0

PHP 5.5.9-1ubuntu4.14 (apache2handler)

MySQL 5.5.47-0ubuntu0.14.04.1

ICU 52.1

What version of Semantic Forms are you running? Also, this may help. Yaron Koren (talk) 12:07, 22 July 2016 (UTC)

Getting the latest entry via forms

I was wondering whether it would be possible to access the latest entry of a forms submission via query without changing forms. Basically something like a submission timestamp. Could it be done via cargo?

I don't understand. What do you mean by "without changing forms"? Yaron Koren (talk) 21:49, 24 July 2016 (UTC)