Extension talk:Page Forms

My pages Special:CreateProperty and Special:CreateClass don't show up...
Hi ! I have installed the extension on a clean new mediawiki website (English Version) but I am facing the following bugs :

Special:CreateProperty and Special:CreateClass doesn't show up ! I get a "No such special page. You have requested an invalid special page."

Moreover, when I am logged in, I get a 500 error on my page Special:Preferences...

However, I think the Semantic Forms Extension is installed correctly since I get the line into my Installed extensions on the Special:Version page.

Any idea why ?

Version :


 * MediaWiki : 1.24.1
 * SF : 3.0
 * PHP Version : 5.4.34

Thanks for your support.


 * My guess is that you don't have the Semantic MediaWiki extension installed. The Special:Preferences thing seems like a separate error, though. Yaron Koren (talk) 14:50, 7 January 2015 (UTC)

multiple instance template not working anymore after version changes. Any idea why ?
My form http://coetus.eu/wiki/Formulaire:SUITE used to work on mediawiki 1.19, including the template multiple :

Yet after I moved to mediawiki 1.23 and to semantic package, the button "Ajouter un tome dans la suite" is not active anymore, i.e. when I clic on it, nothing happens.

To make sure this is not due to my browser, I tried your sample page on http://discoursedb.org/wiki/Special:FormEdit/Item/An_example_item and that one works perfectly i.e. when I click on any of the two "add another" button, I get the expected behaviour i.e. a new series of fields presented.

Do you have the same problem with my form on your side, and do you have any clue on what I may have done wrong ?

Many thanks, and very best wishes for 2015 to you, and to the semantic wiki community.


 * It's great that the form is publicly available - that makes it much easier to debug with the browser JavaScript console. In your case, you have the error message "Unknown dependency: jquery.collapsibleTabs", which is preventing any other JS from running. I don't know what the source of that error is, though - maybe a custom extension? Yaron Koren (talk) 16:43, 5 January 2015 (UTC)

Multiple instances of RunQuery being turned into UNIQ ... QINU string
My problem seems to be related to some recent problems described here and here. I want to embed two RunQueries on a single pages (e.g., the page's source code looks something like

  

This works fine and dandy if I include just Form1 or Form2, but if I include them both like this, then Form1 doesn't display at all, and instead just shows a UNIQ ... QINU string like "UNIQ639ef22958a33d50-item-0--QINU". Here is some information about my set-up:


 * MediaWiki: 1.24.1
 * PHP: 5.5.7 (cgi-fcgi)
 * MySQL: 5.0.95
 * Semantic MediaWiki: 2.0
 * Semantic Forms: 3.0

My wiki is publicly accessible if you would like me to e-mail you the link so you can see the problem in action. Thanks in advance!

- 70.48.43.161 13:38, 5 January 2015 (UTC)

Field Auto-completion Filtered By Property
I'm trying to provide a combobox, where the auto-completion provides a list of pages in a namespace that contain a particular property, but I can't figure out if this is possible.

Specifically, I'm hoping to provide a dropdown of Machine's from which the user will select a Virtual Host, these Machine's having the Boolean property, Virtual Server, ticked.

I can get the combobox to display all Machines with the followingː

and I can see that there is documentation on values dependent on= but I can't quite join up if it is possible to use this to provide only other Machine's that have the Virtual Server property equal to 1.

Am I able to achieve what I'm after?

- Adam Carrgilson 11:33, 8 January 2015 (UTC)


 * You don't need "values dependent on", you need to replace "values from namespace" with either "values from category" or "values from concept", and then create a category or concept that matches the set of pages you need. "values from concept" would be the better approach - see the documentation for more information on that. Yaron Koren (talk) 15:55, 8 January 2015 (UTC)

transcluded in another page
Embedding a page that is in a sub-category

I tried the following with no effect, B still becomes a member of the category. Is there any way to fix this? If a page (which we'll call Page A) gets transcluded in another page (which we'll call Page B), and Page A belongs to a category that's associated with a form, it can have the unfortunate side effect of making Page B a member of that category as well, thus giving Page B an "edit with form" tab at the top, even if such a tab is not appropriate. You can solve this problem by putting the category declaration in Page A within a "&lt;noinclude&gt;" block, which will make Page A a member of that category but not Page B.


 * Sorry, I don't know. Yaron Koren (talk) 19:43, 8 January 2015 (UTC)

indexing multiple instance templates
I know this has been asked before, but I am just curious if there is any plan to implement this in the future. I attempted to modify the js file and add in the index field, but it does not work. I am not sure if the patch needs to be updated.

--Dgennaro 19:35, 13 January 2015 (UTC)


 * No, unfortunately there's still not a solution, though I do want to implement one. I think it would be cleaner to do via SIO or subobjects than in the form, but... whatever works. I should also note the order is preserved if the data is stored via Cargo, but that's a whole other story. Yaron Koren (talk) 21:49, 13 January 2015 (UTC)


 * I saw that. I plan to look into Cargo when I can come up for air. --Dgennaro 21:58, 13 January 2015 (UTC)

Multiple-instance template not working anymore (SF 2.7 -> SF 3.1)
I seem to be having this problem after upgrading from SF 2.7 to SF 3.1. In addition, the first combobox disappeared from the form view. When I replace all instances of input type=combobox in the form, the multiple-instance templates are working fine again. There's this in the debugging console:

"TypeError: jQuery(...).data(...) is undefined" TypeError: jQuery(...).data(...) is undefined Stacktrace: jQuery.fn.SemanticForms_registerInputInit@[...]extensions/SemanticForms/libs/SemanticForms.js:379:9 @[...]index.php?title=Form:[...]&action=submit:6921:77 handlePending@[...]load.php?debug=true&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140604T100439Z:10317:10 runScript/markModuleReady@[...]load.php?debug=true&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140604T100439Z:10457:8 runScript/nestedAddScript@[...]load.php?debug=true&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140604T100439Z:10464:9 runScript/nestedAddScript/<@[...]load.php?debug=true&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140604T100439Z:10469:9 addScript/script.onreadystatechange@[...]load.php?debug=true&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140604T100439Z:10389:9

Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 11:16, 14 January 2015 (UTC)


 * Update: SF 3.0 has other, combobox-related issues but multiple-instance templates are working fine, so that should narrow down the issue to a fairly recent modification. Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 11:48, 14 January 2015 (UTC)


 * I assume this is happening on a private wiki. Could you try to replicate this problem on a public wiki, like scratchpad.referata.com? Also, what are the other combobox issues you're seeing? Yaron Koren (talk) 16:57, 14 January 2015 (UTC)


 * Hi Yaron,
 * 1. Using SF 3.0 (on at least one machine) and 3.1 (on another one), two comboboxes in my form were showing stray placeholders. On further investigation, it looked like the stray content probably came from MediaWiki:Sitenotice, where #formlink is used for ready access to a number of forms. SF's switch to the Select2 library probably helps to explain why this is happening now and not in earlier versions of SF.
 * 2. ...which made me wonder if the unresponsive multiple-instance templates (SF 3.1 only) could also be due to something related to the use of #formlink in MediaWiki:Sitenotice. To cut a long story short, it's the use of #formlink in combination with one or more #formlink parameters (I can't be much more specific I'm afraid) that's causing the trouble. It messes up some of the comboboxes, in turn leading to issues with multiple-instance templates.
 * The solution for me was to simplify #formlink, removing some of the unessential parameters, and the issues were gone! Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 14:25, 15 January 2015 (UTC)


 * Oh, great. And it's good to know that there might be an issue with #formlink - I'll have to look into it. Yaron Koren (talk) 22:21, 15 January 2015 (UTC)

Problem with losing session data while submitting form
I've been trying to work with the Semantic Form, but keep getting the "Sorry! We could not process your edit due to a loss of session data." error.

I've upgraded to 3.1 and (thinking there might be some issue with the Cargo additions) went back to 3.0. No dice.

I've updated in test and, thinking this might be a problem with something there, did an upgrade (to SMForms 3.0) in production just now. I'm still getting the "We could not process..." problem.

I tried instrumenting and tracing the code from where  fails and got the following as the first failure:

User::matchEditToken: broken session data 1f054b3425fd476a1bf9e17304d12282+\ != db0cba2825d4b644ba8a1a0cd2948714+\
 * 1) 0 extensions/SemanticForms/specials/SF_UploadWindow.php(98): User->matchEditToken('1f054b3425fd476...')
 * 2) 1 extensions/SemanticForms/specials/SF_UploadWindow.php(24): SFUploadWindow->loadRequest(Object(WebRequest))
 * 3) 2 includes/specialpage/SpecialPageFactory.php(385): SFUploadWindow->__construct
 * 4) 3 extensions/SemanticForms/includes/forminputs/SF_TextInput.php(111): SpecialPageFactory::getPage('UploadWindow')
 * 5) 4 extensions/SemanticForms/includes/forminputs/SF_TextInput.php(231): SFTextInput::uploadableHTML('input_2', NULL, '', 'test-upload3.sv...', Array)
 * 6) 5 extensions/SemanticForms/includes/SF_FormPrinter.php(1881): SFTextInput::getHTML('test-upload3.sv...', 'Unconventional ...', false, false, Array)
 * 7) 6 extensions/SemanticForms/includes/SF_FormPrinter.php(1334): SFFormPrinter->formFieldHTML(Object(SFFormField), 'test-upload3.sv...')
 * 8) 7 [internal function]: SFFormPrinter->formHTML(' \n<...', true, false, 47989, '', 'Sandbox test', NULL)
 * 9) 8 includes/StubObject.php(105): call_user_func_array(Array, Array)
 * 10) 9 includes/StubObject.php(125): StubObject->_call('formHTML', Array)
 * 11) 10 extensions/SemanticForms/includes/SF_AutoeditAPI.php(870): StubObject->__call('formHTML', Array)
 * 12) 11 extensions/SemanticForms/includes/SF_AutoeditAPI.php(870): StubObject->formHTML(' \n<...', true, false, 47989, '', 'Sandbox test', NULL)
 * 13) 12 extensions/SemanticForms/includes/SF_AutoeditAPI.php(116): SFAutoeditAPI->doAction
 * 14) 13 extensions/SemanticForms/specials/SF_FormEdit.php(92): SFAutoeditAPI->execute
 * 15) 14 extensions/SemanticForms/specials/SF_FormEdit.php(46): SFFormEdit::printForm('Unconventional_...', 'sandbox test', NULL)
 * 16) 15 includes/specialpage/SpecialPage.php(363): SFFormEdit->execute('Unconventional_...')
 * 17) 16 includes/specialpage/SpecialPageFactory.php(562): SpecialPage->run('Unconventional_...')
 * 18) 17 includes/MediaWiki.php(275): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
 * 19) 18 includes/MediaWiki.php(584): MediaWiki->performRequest
 * 20) 19 includes/MediaWiki.php(435): MediaWiki->main
 * 21) 20 index.php(46): MediaWiki->run
 * 22) 21 {main}SpecialPage::getContext called and $mContext is null. Return RequestContext::getMain; for sanity

Creating a form without any uploads in it (just a simple text entry) resulted in the same problem.

I poked around and saw other people with similar problems, but no clear solution.

Ideas? -- ☠ MarkAHershberger ☢ (talk) ☣ 22:53, 16 January 2015 (UTC)


 * That does sound like a problem with tokens, in some way. What version of MediaWiki are you using? And does this problem happen on a form with an "uploadable" input? And if so, does it also happen on forms without "uploadable? Also, where have you seen similar problems? I don't remember them, but maybe that would shed some light on this issue. Finally, it's not "SMForms", it's just SForms. :) Yaron Koren (talk)÷ 23:08, 16 January 2015‎ (UTC)
 * SForms... got it.
 * It happens on forms without "uploadable", too. I haven't seen similar problems on this wiki, except when you wait too long to submit.  That isn't the issue here.
 * I've instrumented  and   in the following way:

""
 * And, to demonstrate that this isn't a problem with uploadable, I've created the following simple form (this is copied from another form, since I haven't really dealt with forms before):




 * Submitting this form ends up with the following in the debug log:

*** getEditToken w/o request *** getEditToken before user check *** getEditToken token: MWCryptRand::realGenerate: Generating cryptographic random bytes for User::getEditToken/MWCryptRand::generateHex/MWCryptRand::realGenerateHex/MWCryptRand::generate/MWCryptRand::realGenerate MWCryptRand::realGenerate: openssl_random_pseudo_bytes generated 16 bytes of strong randomness. MWCryptRand::realGenerate: 0 bytes of randomness leftover in the buffer. *** getEditToken was null got c8477b8f9928be26955e36b0d3295736 *** getEditToken returning c8477b8f9928be26955e36b0d3295736 *** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 *** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 User::matchEditToken: broken session data 3514833eb1ab2367bc008b4bd487873e+\ != 337f3aae3ee72537c5773bd58d2e37b8+\ *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 EditPage::importFormData: Failed token check; forcing preview SFUtils::showFormPreview: enter. Title::getRestrictionTypes: applicable restrictions to Sandbox are {edit,move} *** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 User::matchEditToken: broken session data 3514833eb1ab2367bc008b4bd487873e+\ != 337f3aae3ee72537c5773bd58d2e37b8+\ *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 *** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 *** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 *** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9
 * 1) 0 includes/EditPage.php(1237): User->matchEditToken('3514833eb1ab236...')
 * 2) 1 includes/EditPage.php(798): EditPage->tokenOk(Object(FauxRequest))
 * 3) 2 extensions/SemanticForms/includes/SF_AutoeditAPI.php(374): EditPage->importFormData(Object(FauxRequest))
 * 4) 3 extensions/SemanticForms/includes/SF_AutoeditAPI.php(900): SFAutoeditAPI->setupEditPage('')
 * 5) 4 extensions/SemanticForms/includes/SF_AutoeditAPI.php(116): SFAutoeditAPI->doAction
 * 6) 5 extensions/SemanticForms/specials/SF_FormEdit.php(92): SFAutoeditAPI->execute
 * 7) 6 extensions/SemanticForms/specials/SF_FormEdit.php(46): SFFormEdit::printForm('Sandbox_test', '', NULL)
 * 8) 7 includes/specialpage/SpecialPage.php(363): SFFormEdit->execute('Sandbox_test')
 * 9) 8 includes/specialpage/SpecialPageFactory.php(562): SpecialPage->run('Sandbox_test')
 * 10) 9 includes/MediaWiki.php(275): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
 * 11) 10 includes/MediaWiki.php(584): MediaWiki->performRequest
 * 12) 11 includes/MediaWiki.php(435): MediaWiki->main
 * 13) 12 index.php(46): MediaWiki->run
 * 14) 13 {main} *** getEditToken w/o request
 * 1) 0 includes/EditPage.php(1237): User->matchEditToken('3514833eb1ab236...')
 * 2) 1 extensions/SemanticForms/includes/SF_AutoeditAPI.php(461): EditPage->tokenOk(Object(FauxRequest))
 * 3) 2 extensions/SemanticForms/includes/SF_AutoeditAPI.php(908): SFAutoeditAPI->doStore(Object(EditPage))
 * 4) 3 extensions/SemanticForms/includes/SF_AutoeditAPI.php(116): SFAutoeditAPI->doAction
 * 5) 4 extensions/SemanticForms/specials/SF_FormEdit.php(92): SFAutoeditAPI->execute
 * 6) 5 extensions/SemanticForms/specials/SF_FormEdit.php(46): SFFormEdit::printForm('Sandbox_test', '', NULL)
 * 7) 6 includes/specialpage/SpecialPage.php(363): SFFormEdit->execute('Sandbox_test')
 * 8) 7 includes/specialpage/SpecialPageFactory.php(562): SpecialPage->run('Sandbox_test')
 * 9) 8 includes/MediaWiki.php(275): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
 * 10) 9 includes/MediaWiki.php(584): MediaWiki->performRequest
 * 11) 10 includes/MediaWiki.php(435): MediaWiki->main
 * 12) 11 index.php(46): MediaWiki->run
 * 13) 12 {main} *** getEditToken w/o request
 * A sucessful edit on a non-SForms wiki page ends up with the following in the log:

*** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 User: got user 15838 from cache User: loading options for user 15838 from override cache. Title::getRestrictionTypes: applicable restrictions to User:Hershm are {edit,move} *** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 *** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9 *** getEditToken w/o request *** getEditToken before user check *** getEditToken token: 368f4813db995d79921958378cc7eaa9 *** getEditToken returning 368f4813db995d79921958378cc7eaa9
 * I could see this being a conflict with some other extensions, though. Any pointers there? -- ☠ MarkAHershberger ☢ (talk) ☣ 16:46, 17 January 2015 (UTC)


 * That's a lot of printout! First of all, it's just Semantic Forms or SF, not SForms - sorry about the confusion. As to the issue, I think it's a reasonable guess that the problem is due to some conflict with another extension, but I don't know anything more than that. Maybe try to disable/enable other extensions to try to isolate the problem, or just to make sure that that's not it? Yaron Koren (talk) 01:09, 19 January 2015 (UTC)
 * Just trying to be thorough!
 * I disabled most other extensions in the dev server and still had the problem. I'm using an updated and extended Auth remoteuser to handle SSO.  Like I said, everything else works, so maybe Semantic Forms has exposed a bug in my code or my code has exposed one in Semantic Forms!
 * Or, we could both be winners and each have a bug in our respective code base!
 * I'll go disable the extension now and see if I can get it to work. Thanks for your help. -- ☠ MarkAHershberger ☢ (talk) ☣ 21:32, 20 January 2015 (UTC)


 * Note that I downgraded to 2.7 (from 3.1) and the form submission works now, even with my mods. I don't think the problem only with my code. -- ☠ MarkAHershberger ☢ (talk) ☣ 01:36, 22 January 2015 (UTC)


 * After using git bisect, I tracked it down the patch for and added my comments to.

Providing a dynamic file name (one-step process)
Heiya, is it possible to dynamically set a default file name for file uploads when using the one-step-process? So far this seems only to be possible when one wants to upload a file directly (file name = page name) and additionally annotate it with further information but not if the file to be uploaded just relates to the page to be created with with form. I do not think that this is if I am not mistaken. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 20:05, 18 January 2015 (UTC)


 * I'm not sure I understand the question, but the "default filename" thing should always be possible to do. However, there's a major flaw in that feature, which is that the uploaded file has to have the same file type as the default filename is set with (like ".gif" or whatever it is); otherwise it won't work. Yaron Koren (talk) 01:31, 19 January 2015 (UTC)


 * Indeed, the file type is another issue. Providing a dynamic default filename based on the page name when creating a page through the one-step process is what I meant. One just ends up the the "Semantic Forms Permission error.jpg" as default filename. This is understandable since the form has now clue what it will be. However, doing it with e.g should work but the filename would not be very meaningful. At least it is unique. Probably a matter of compromise --&#91;&#91;kgh&#93;&#93; (talk) 09:29, 19 January 2015 (UTC)


 * Ah, based on the page name, now I get it. No, it's not possible; the file upload happens before the page is created. Yaron Koren (talk) 15:37, 19 January 2015 (UTC)


 * Thank you for confirming. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 15:56, 19 January 2015 (UTC)

No multiple selection in "tree" input
There are no parameters to enable multiple selection in "tree" input. Proposed example also doesn't show this feature: see example. Dmitry Russkih (talk) 18:05, 20 January 2015 (UTC)


 * There is indeed a problem with that example, although it's due to a temporary issue involving Cargo. Anyway, you can always specify that the tree input should allow multiple values by adding "|list" to the field tag. (Maybe the documentation should be clearer on that.) Yaron Koren (talk) 19:03, 20 January 2015 (UTC)
 * Thanks! I've comlemented help page but I can't edit example page (capcha wonts one name, but system not accepted both 'Kerry' or 'John Kerry') Dmitry Russkih (talk) 00:04, 21 January 2015 (UTC)


 * Thanks. I purposely made that CAPTCHA "incorrect", because it was the only way to fully block spammers. I could just add in "|list" to the form, but instead I plan to fix the issue with template parsing in SF, so that it knows it's a list. To clarify, this particular bug only happens when the Cargo extension is installed. Yaron Koren (talk) 14:47, 21 January 2015 (UTC)