Extension talk:Page Forms

Forminput size

 * I'm having a problem with the size argument on #forminput. It does not seem to affect anything on the #forminput inputbox.  Running 1.8.8.  I'd like to make it 0. so I have just a button that calls the form with  as the default.  That way I can have buttons on the page for each infobox template to let the user just click and use the form to edit the properties without ever going into ugly edit mode.


 * You should use #formlink instead. Yaron Koren 16:19, 1 March 2010 (UTC)

MW Version error (Class HTMLTextField not defined)
In "includes/SF_GlobalFunctions.php" there is the following lines (83-90): I installed SemanticForms with MediaWiki version 1.15.1. The wiki uses several other extensions too, and it seems (yes, it was unlikely to happen, but it happened) that one of them defines an 'HTMLForm' class... So SemanticForms loaded the upload class designed for MW 1.16 — which leaded to a fatal error, since "HTMLTextField" was not defined.

I propose to rely on MW's "$wgVersion" variable instead of checking for a class definition: This worked fine for me (I'll update this post if I find the extension which defines an "HTMLForm" class. Alvinos 13:01, 8 March 2010 (UTC)


 * I found it! The guilty one is "SpecialDeleteOldRevisions2". To make the old version "SpecialDeleteOldRevisions" compatible with MW > 1.12, they just bundled the old file "HTMLForm.php" with their extension... Pathetic.


 * Ah, good to know. Unfortunately, checking by MW version is perilous too, because different people use different SVN versions, so there's no direct correspondence between MW versions and whether that class is in there. I could change the code to check for 'HTMLTextField' instead, though... Yaron Koren 15:17, 8 March 2010 (UTC)


 * I changed it to check for 'HTMLTextField' in version 1.9; hopefully that works better... Yaron Koren 14:19, 11 March 2010 (UTC)

Sub-properties
Hi Yaron and all:

I have a question regarding the use of Sub-properties within SMW (http://semantic-mediawiki.org/wiki/Property:Subproperty_of). I have set up some sub-properties, and I have added them to my template that my form uses.

I dont see the sub properties show up on the form or on my Drill Down. Is this by design? is there anyway to get them to show up? Thanks,

Dave Manzolillo DManzolillo@gmail.com

formlink
I don't know if I am using #formlink the way it was meant to be used, but I had a hard time figuring out how to pass the page name using formlink. I tried default value=page_name, query string=title=page_name and query string=target=page_name. None of those worked.

I ended up using

form_name/page_name (ctrl-click)">

which works, but I don't know if I am using it the way it was meant to be used or if I just tricked it. I'm using 1.9 which uses Special:FormEdit instead of Special:AddData or Special:EditData. Don't know if that makes a difference. I hope my approach will continue to work in future versions.

Specifically I was trying to use it to create a subpage form_name/ (ctrl-click)"> Dmoorevtedu 14:05, 15 March 2010 (UTC)


 * Hi - if you know the page name ahead of time, then the best solution is not to use #formlink, but to use this approach. Its advantage (besides the fact that it's not a hack :) ) is that it'll show up as a regular link after the page is created. Yaron Koren 15:16, 15 March 2010 (UTC)
 * Yes but what if you want to preload data? I have preloading working with Dmoorevtedu's hack, but of course one would have to hide the button/link if the page has already been created.  217.151.109.252 22:41, 17 March 2010 (UTC) (Bob)

Floatbox Not Appearing?
I hope I am missing something obvious and silly here. I have the same behaviour on two different wikis, one at 1.14 and a brand new one at 1.15

Here is my form. If you add a new page, and attempt to upload a photo, you are brought to a new page instead of seeing the Floatbox.

I have no errors in PHP, or apache...not sure where to start here. Has anyone seen this? Thanks! --John Thomson 01:38, 23 March 2010 (UTC)


 * I like the domain name. :) The issue is that all the references to CSS and JS files in the source code are incorrect - somehow, $wgScriptPath in LocalSettings.php is being set to "/wiki" instead of "/mw". Yaron Koren 03:56, 23 March 2010 (UTC)


 * Thanks on both counts, Yaron! I have two wikis on that server, one at "/" (of my Document Root), and the 1.15 instance in "/mw".  Both LocalSettings *appear* to have the correct value ("", and "/mw", respectively).  Changing the value of $wgScriptPath has catastrophic effects on the rest of the wiki and extensions, of course.  My only recourse now is to hack through the code and hard-code the paths to the JS and CSS files, and while that has netted me some improvements, it is still not working properly...my skin "greys out" as though the floatbox is about to appear, then nothing.  Unless you have another suggestion?  How were you able to determine that $wgScriptPath was set to"/wiki"?  Thanks again for the prompt assistance, it is much appreciated!  ITM, I will keep futzing... --John Thomson 12:34, 23 March 2010 (UTC)


 * Hi - you just have to check the HTML source; any instance of "/wiki" there is probably a mistake. Yaron Koren 14:12, 23 March 2010 (UTC)


 * I ended up symlinking my root to "wiki" just to get past this, and it worked. Thanks again for your help! --John Thomson 15:37, 23 March 2010 (UTC)

Hi Yaron, I was just having the same issue and saw this post..it turned out that it somehow added the /wiki path also. All other extensions render the same. I just wanted you to know that it was not an isolated incident. I ended up going in and hard coding the path in SF_Utils --Demetelski 22:38, 3 April 2010 (UTC)


 * Perhaps you just don't have any other extensions that use $wgScriptPath? The problem definitely isn't coming from Semantic Forms. Yaron Koren 03:18, 4 April 2010 (UTC)

Using Wikilinks In Form Submission
Hi All,

I am having a hard time figuring out what my problem is here...when I add a wikilink like Main page in a form submission, it tends to hose the previous text in that text area...

--John Thomson 14:57, 27 March 2010 (UTC)
 * All is well, I eventually found out about this:

$smwgLinksInValues = true; --John Thomson 15:36, 27 March 2010 (UTC)
 * Thank you for this tip - I'd the same problem - --Ulli 757 20:42, 28 April 2010 (UTC)

Modifying input type=categories?
Hi..I have placed the array of a category in my form in order for the user to check off which to include in the page. A couple of questions..1) I have the form results set to show as the right-hand box but it does not display the data from the checked off category boxes. I would have though that it would display the checked off categories and then have them as a link in the box? 2) If this is not the case is there another way for users to select multiple categories and have them display? Thanks..Deon

One other issue...I was testing out forms...I created a form Lessons and then deleted it..I then created a form Lesson and now when I click edit with form it keeps taking me back to the Lessons form with the message Error: no form page was found at Lessons even though I created it with the Lesson form. Ideas? Thanks.


 * Hi - for the first issue: do the category names show up correctly in the page source? If so, you probably just need to fix the #arraymap call in the template. For the second issue: you need to replace "Lessons" with "Lesson" in the category page. Yaron Koren 15:31, 30 March 2010 (UTC)

Hi Yaron, Yes, the category names show up in the source but do not show on the page..here is the code I used

Thanks, Deon


 * Yes, but what code did you use in the template? That's the issue. 16:58, 30 March 2010 (UTC)

I just added that code to the form under the template..I didn't do it through the create template page because I didn't see a way to set the property for this.


 * It sounds like you have some misunderstandings about how forms, templates and categories work together. I'd recommend playing around with it more, and reading more of the SF documentation. Yaron Koren 18:30, 30 March 2010 (UTC)'

Ok figured it out and now adds to the categories I want. One question which I am not sure if it can do it because I see that the example form doesn't display it either. Besides the categories being displayed on the bottom can the text of each category show next to the field? On the example page the commas are there but no text. Thanks to anyone. --Demetelski 15:45, 31 March 2010 (UTC)


 * That's great to hear. Yes, you can have both - in the #arraymap call, instead of just "", you should have " Category::x" . Yaron Koren 16:08, 31 March 2010 (UTC)

One question and one issue
Hi,

So first what I think is a bug..In my form if a user tries to create a bullet with the wiki (*) as the first input character it will not show the bullet but the asterisk, but the next line with a bullet will show.

The next question I have is I have 2 templates one is set as the right-side box and the other in the page. I was wondering if I can have the right-side box not automatically take the title of the page but if I can specify it or change code somewhere. I have looked but can't find anything..might have missed it. Thanks --Demetelski 14:40, 3 April 2010 (UTC)


 * Hi - the first one isn't really a bug; you just need to put that field on the line below whatever's right before it in the template; MediaWiki doesn't recognize an asterisk as a "bullet" unless it's the first thing on the line. For the second issue, look in the right-hand-side template for something that looks like " ", and change that to whatever you want. Yaron Koren 03:16, 4 April 2010 (UTC)

Input type = checkbox, default=checked?
Is it possible to define a checkbox in a form where it defaults to being checked? I tried setting input type=checkbox (which works), but default=checked doesn't seem to work. --Gkullberg 15:20, 5 April 2010 (UTC)


 * You can do it - it just has to be "default=true" or "default=yes". Yaron Koren 04:43, 6 April 2010 (UTC)

Upgraded to SMW 1.5.0 and SF 1.9, but now setting the default to now on a date-type input literally puts in the word now. Wazzup with that?


 * No idea - can you reproduce it on a public wiki, like scratchpad.referata.com? Yaron Koren 04:43, 6 April 2010 (UTC)

Autocompletion on Main namespace post-upgrade
I recently upgraded to SF 1.9, and it seems autocompletion for the main namespace isn't working. When I view the source of the form page, I see this:

autocompletestrings['Main,list'] =  (ctrl-click)">;

I feel like this segment of code should have a list of all the possible values. Automcompletion is working for other namespaces. Is this a known issue? --Gkullberg 18:48, 5 April 2010 (UTC)


 * Ah, you've found a bug - thanks for the bug report. I just fixed it in SVN, but if you're not using SVN you can fix it on your own side by just looking for the string "main" (quotes included) in the file /includes/SF_FormInputs.inc and changing it to "Main". Yaron Koren


 * That worked, thanks Yaron. --Gkullberg 20:28, 6 April 2010 (UTC)

Uploadable Feature Fails
With the new SMW and Semantic Forms, using this code: ! Mp3:

results in a large text field and no "upload link". This used to work with the old versions...


 * I can't reproduce this problem - can you reproduce it on a public wiki, like scratchpad.referata.com? Yaron Koren 19:06, 6 April 2010 (UTC)

mandatory fields issue
Hello,

Every time I put "values from concept= or autocomplete on concept=" the mandatory input doesn't work. When saving the warning just flashes quickly and it goes on saving the page. Any idea what I could be doing wrong?

thanks Msevero 02:57, 7 April 2010 (UTC)


 * What versions of SF and SMW are you using? Yaron Koren 17:13, 7 April 2010 (UTC)


 * SF 1.9, SMW (Version 1.5.0.a-SVN), MW 1.16.0 beta 1 (monobook skin) Msevero 03:36, 16 April 2010 (UTC)


 * I can't reproduce this. Could you try to recreate it on a public wiki, like scratchpad.referata.com? Yaron Koren 17:08, 16 April 2010 (UTC)

Hi, I have a similar problem. As soon as I set a default value for a field like e. g. the form ignores other fields in the same form labelled as mandatory and which are not getting pre-populated with a value. Thus it is possible to save the form without populating the other mandatory fields. In this case I am just getting the warning quickly flashing. As soon as I remove the label mandatory from the field to be the pre-populated all the other mandatory fields are not longer ignored. I am using SMW 1.5.0 and SF r63748 of March 14, 2010 on MW 1.16.0beta2. However I will try to get this reproduced on scratchpad... Cheers --kgh 00:27, 18 April 2010 (UTC)

Hi Yaron, I tried to recreate the problem at scratchpad.referata.com and failed. Since the configuration varies at refarata. Thus I presume that this issue arises with MW 1.16. since it seems to be the only difference between the three of us. Cheers --kgh 10:11, 18 April 2010 (UTC)


 * Thanks for trying it out on Scratchpad. I copied over your wiki pages to Discourse DB, which uses MW 1.16, but I couldn't replicate it there either - see here. Yaron Koren 03:02, 19 April 2010 (UTC)


 * Hi Yaron, I have to thank you for trying to recreate this. Hmm..., it was to easy to blame it on 1.16. I will try to track the reason. Stay tuned. Cheers --kgh 09:00, 19 April 2010 (UTC)

Adding Headings in the Form or Template to be posted to the page along with the data
I was wondering if there is a way to post a title/heading above the template form that will get posted to the page along with the data after the user submits the form?

For Example:

Say we have some form that has xyz number of templates associated with it. The user is filling out the forms where the form has titles for each template. The user submits the form and the data gets posted to a new page. On that page is now the data the user field out with the field names in a table form and the title of the template or heading gets appended above the data such as below:

After posting the form to a new page

HEADING

Data: Data: Data: Data:

The goal here is to either somehow post the title of each template above the data of that template on a new page or somehow declare a new title that will be posted in the same way. Does anyone know how to do this or if its even possible? I want to make a formatted professional page that has headings for the data the user posts.

--Neezy 16:19, 7 April 2010 (UTC)


 * Sorry, I don't think I understood this - can't you just have each template put whatever heading it wants? Yaron Koren 17:14, 7 April 2010 (UTC)


 * Hmmmm.... Basically, if you take a standard template... It asks for a Template Name, Category, Field Names, Display label, and property, and has the option for aggregation. Well if I fill out a name for the template, a category, and associated fields and save the page.  When I add the template to the form it will show the template name when filling out the form, but how do you get it to post it to the article along with the data.  This is basically what I am trying to do. --Neezy 16:20, 14 April 2010 (UTC)


 * Just edit the template to have it display whatever you want. Yaron Koren 18:14, 14 April 2010 (UTC)

Problem with "edit with form"
I get the following error with mediawiki 1.12.0, and SMW 1.4.2 when I click on "edit with form": Fatal error: Call to private method Xml::expandattributes from context 'SFFormUtils' in /home/jusylves/bromontpedia/extensions/SemanticForms/includes/SF_FormUtils.inc on line 458 Any advice?


 * Evidently Xml::expandAttributes, which was added in the last version of SF, either didn't exist or was a private function in MW 1.12. It seemed a little silly to require MW 1.13 just for this one function, so I just checked in a change to Semantic Forms so that it's no longer required. If you re-get the code from SVN, it should work fine; or you can wait until the next version comes out. Yaron Koren 20:38, 8 April 2010 (UTC)


 * Thanks for the quick reply. Actually, your use of 'method_exists' doesn't work with php < 5.1! In php 5.0.x, method_exists will return True on private methods. I've tried the following, it seems to work:

SF_FormUtils.inc:457 if ( in_array('expandAttributes', get_class_methods(Xml) ) ) {
 * I don't know if this is also valid in php 5.1.x.

When using NSFileRepo
When using Semantic Forms 1.8.3 (not sure about other versions) and Extension:NSFileRepo I have noticed that a small modification is needed in the SF_UploadWindow.php file on/around line 422.

If this is not done you will receive and warning message that says that the file was renamed when uploading a file via the upload window. I have found that this message could be confusing to users.

I hope that this helps someone.

--Dgennaro 17:27, 8 April 2010 (UTC)

Form with variable number of fields
I have a template which uses a variable number of arguments, e.g. a0, b0, a1, b1, ..., an, bn, where n can vary from page to page. I want to construct a form with input fields arranged in a table, with a0 and b0 on the first line, and so on. The number of lines will change from page to page. I do not wish to use the page creation feature; pages will be created by a script with a fixed value for the number of arguments, and the form will only be used to modify the values of the a's and b's. Therefore I do not need to consider the case where the form must be updated when n is changed.

I have two questions: This doesn't work. Values of the template parameters in the page are not passed to the form. I assume that this is because the conversion a --> a0 is not done before the "field" markup is parsed?
 * First, is there a way to pass the number of arguments (n) to the form, so that it uses a loop to produce a table with the correct number of lines?
 * Second, assuming that it is possible to pass n to the form, I have been playing with the following code:


 * Yeah, there's no way to have a form with a variable number of fields. I'd recommend simplifying the whole setup by using a multiple-instance template instead. Yaron Koren 00:27, 10 April 2010 (UTC)

Form Looping
Hey guys just created my first form. Now it was outputting fine with all the info. Now all of a sudden when I hit save page it will go to a 'Start of form' page and states -

''"Enter the name of a page here, to be edited with the form "formname". If this page already exists, you will be sent to the form for editing that page. Otherwise, you will be sent to the form for adding the page." '''

Then when I enter in the page name it will just take me back to my form..? Im not sure if its relationship issue with my properties but his my form

' Create Cemetery Page



Free text:

Thanks guys


 * Hi, there might just be confusion here around the word "form". In SF terms, the page you copied over isn't a form (even though its name starts with "Form:") - it's a "form definition page". When you actually see the form fields in front of you, that's the "form". Does that clarify the situation, or are you actually having a looping problem? Yaron Koren 13:26, 22 April 2010 (UTC)

Question aout upgrade to 1.9
Hi there - I'm currently running SF 1.8.6, hoping to upgrade to 1.9. Reading the version history notes, I was concerned about the renaming of "AddData" to "FormStart". If my wiki had previously used "AddData" in various links / buttons / code snippets, will I need to find each one and rename change it to "FormStart"? Thanks! LittleKyle 16:37, 23 April 2010 (UTC)


 * Hi - "AddData" actually changed to "FormEdit" (it was "AddPage" that changed to "FormStart"), but in any case - yes, you'll have to change the string. If it's on your wiki in more than just a handful of places, the Replace Text extension could help. Yaron Koren 16:45, 23 April 2010 (UTC)

&returnto parameter
This is basically a question about a form in a form. I have a setup based on two types of pages, "characters" (e.g. 免  ) and "glyphs" (e.g. 免/1 , 免/2  , ...), the former aggregates the latter glyph pages using #ask queries (real world example). Character pages are also the main entry point for contributers, and I'd like to offer easy access to the form editing of glyph pages. While I can link to the edit form on the "subpage", a submit, once done, will load the glyph page, disrupting the workflow.

I'd be open for suggestions how to do a different take, but currently I believe giving a "returnto" option with the "query_page" attribute of the form pointing back to the aggregating character page might be the easiest solution. I'd try a patch if this would be accepted into the source. Putting a form with "multiple" into the major form doesn't seem feasible as the glyph pages themselves have a fairly complex structure. --Christoph Burgmer 20:40, 27 April 2010 (UTC)


 * A "returnto" parameter would be great, if it worked... I doubt it could be made to work, without some modifications to MediaWiki itself, but if it could, then yes, I'd gladly add such a patch in to the code. Yaron Koren 21:49, 27 April 2010 (UTC)
 * I just talked to hhappel and he suggested to go into the hooks and redirect all "glyph" pages, without such a feature though. I'll check my options and report back --Christoph Burgmer 00:05, 28 April 2010 (UTC)
 * I read through the sources for an hour or so and decided I will go for the quick solution with redirects per hooks. Here's my solution, for it might help others.
 * * I use subpages for the "glyph" pages, i.e. pages aggregated by a main page.
 * * I use a hook to do a redirect to the main page:

$wgHooks['OutputPageBeforeHTML'][] = 'cdbfRedirectMainSubpage'; function cdbfRedirectMainSubpage(&$out, &$text) { $title = $out->getTitle; if ($title->getNamespace != NS_MAIN) // limit to namespace return true; if (!MWNamespace::hasSubpages($title->getNamespace)) // only if subpages are configured for this namespace (main) return true; $parts = explode( '/', $title->getText ); // fall back to super page $target = $parts[0]; if ($target != '' and count($parts) > 1) { $targetTitle=Title::newFromText($target); $targetTitle->setFragment($title); // in redirect skip to #anchor with name of the subpage, e.g. 免/2 => 免#免/2 $out->redirect($targetTitle->getFullURL("")); return false; } 	return true; }


 * I think this is clean enough. I would've liked to put a redirect into forms, but it seems I need to go way deeper into the code than I wanted for now. --Christoph Burgmer 09:09, 28 April 2010 (UTC)


 * Hi, can you explain this code in further detail? And does this have anything to do with forms? Yaron Koren 20:37, 28 April 2010 (UTC)


 * I just updated the code to use another hook (use diff in case you want to see the old version). Right now I let the redirect happen after the page has been rendered internally. This is to make sure Semantik MediaWiki has time to parse the page's properties. Using the old hook before the page is accessed will lead to properties disappearing from the database. I had to rebuild my index after removing my changes to get everything back.
 * This code might be special to my usecase, but I believe it is connected to Forms as it solves the problem of editing subpages that only exist due to structural considerations. In my case, from a user point of view, these subpages shouldn't be accessed, but from a design perspective my suppages have multiple relations and this dependencies are, it seems, impossible to code into one page. Long story short: 1 character can have n glyphs, 1 glyph can have m decompositions. These multiple relations are thus distributed over several pages.
 * With the code above you can effectivly hide subpages from the user as that each access will redirect to the "main" page for the dataset. This is a "returnto" taken to the whole wiki, not only for edit forms. Here any request for a subpage, be it 免/2 or 免/2/some/eaven/further/away will resolve to 免. For my case (and thus in this code here) I limit redirects to the main namespace and only to subpages in the form "page/subpage" if subpages are configured (not default).
 * If you want to limit the effect to form edits you would probably need to chose another hook (maybe 'ArticleUpdateBeforeRedirect'), but in this case you will have to make sure SemanticMediaWiki still parses changed properties or you loose them from the store as happend to me before. --Christoph Burgmer 21:43, 28 April 2010 (UTC)

I see. By the way, to store those kinds of compound relationships, another (I think easier) approach is to use multiple-instance templates on one page, in conjunction with the Semantic Internal Objects extension. Yaron Koren 05:54, 29 April 2010 (UTC)
 * Thanks. I'll look into it. I thought that most of the benefits of this extension are gone with records being introduced, but I might be wrong. I'll be happy to put everything in one place if data storage and queries are not affected. --Christoph Burgmer 16:25, 29 April 2010 (UTC)
 * From what I understand, it doesn't solve the issue of multiple properties in subobjects:
 * character
 * glyph
 * decomposition
 * glyph
 * decomposition
 * decomposition
 * That is, I have subobjects in subobjects, subsubobjects--Christoph Burgmer 17:28, 29 April 2010 (UTC)


 * Hi - assuming "decomposition" is just a string, you can actually store that using SIO; you just need to specify decomposition as a "list" value. Yaron Koren 03:42, 2 May 2010 (UTC)
 * Interesting. But would Semantic Forms then allow me to add another glyph and for this add one or more decompositions? How are semantic internal objects processed in forms anyway? --Christoph Burgmer 09:44, 3 May 2010 (UTC)


 * Yes - you can do that via multiple-instance templates, with "decomposition" as a "list" input. Yaron Koren 12:53, 3 May 2010 (UTC)

Problems with SVN version of FCKeditor
When using MW 1.16beta and the SVN version of FCKeditor loading a semantic form (with free text field) will produce javascript alerts like  for all the special MW toolbar items which will then not appear. Any ideas what the reason for this behavior could be? Thanks, --Thai 19:39, 28 April 2010 (UTC)

Influence date format
If I have a property of type date and want to edit it with semantic forms (input type=date), in my german mediawiki the template parameter always has the format YYYY/mm/dd (after editing it with semantic forms). This is normally not a problem, since this format is parsed correctly and transformed into a valid date property, but I use the template parameter to display this on the page itself, since in Germany we use the format dd.mm.YYYY. The only workaround I found is using the property within an inline query ( instead of the template parameter, but that workaround leads to problems with the preview (since at that state, the property is not yet overwritten) --92.229.17.49 14:50, 3 May 2010 (UTC)