Extension talk:Page Forms

Blank Page on Edit Save After Installation
I installed Semanatic MediaWiki with no extra configuration and waited until the database was finished updating until installing Semantic Forms. Upon my first save of a page edit, the system brought me to a blank page a with the URL: http://www.Example.com/index.php?title=TestPage&action=submit I realized after the fact that certain install requirements regarding name spaces MAY not have been met. I have Extension:SocialProfile installed but didn't think it had any new names paces, but I added the following line to my LocalSettings.php anyway. $smwgNamespaceIndex = 150; Also, I commented out the following line and saving worked for a while. include_once('extensions/SemanticForms/includes/SF_Settings.php'); I tried later and now I'm getting more errors like the following line on only some saves. Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 1966080 bytes) in /home/example/public_html/sitename/extensions/SemanticMediaWiki/languages/SMW_Messages.php on line 4843 At this point I'm figuring as a first time wiki admin that I might be doing something wrong. I can't find any uninstall features in order to reinstall Semantic Forms if I have to. Any ideas? Thanks ahead of time.

Jephrei 02:03, 3 May 2009 (UTC)


 * That last message just means that the system ran out of memory; see here for one way to fix it. Yaron Koren 03:55, 4 May 2009 (UTC)


 * Yeah. i figured that out after i posted. but nope....that fixes the mem but only with semantic forms disabled. I TRIED to disbable both or uninstall completely to reinstall but there's no uninstall documentation. if i comment out the settings in localsettings.php will it be "disabled" or do i have to rollback the database or undo the changes somehow? Also, if i didn't set the custom name space addition lines in localsettings.php before the install and instead added the lines AFTER the install, will SMW and SF work? Jephrei 20:41, 5 May 2009 (UTC)
 * I found that removing languages that I didn't need from SF_Messages.php solved all my problems.

Pointing red links to 'add data' form also for username in top-right-corner
Would it be possible to enable the feature with pointing red links to the add-data-form also for the userpage-link in the personal toolbar (the link with the small person icon next to it). We would like to see this feature so users who are new to our wiki can simply click on their (red) username and get the form.

I browsed around the code a bit and it seems to me that this link is generated in includes/SkinTemplate.php:buildPersonalUrls from the data contained in the array userpageUrlDetails, which in turn is filled by a call of the form: makeUrlDetails( $this->userpage ). Further down the call tree the hook for this function seems to be GetLocalUrl, but I guess there will be some filtering necessary to track down this link (or class of links).

Or is there any other way to make the link point to the form?? - LosWochos 08:24, 20 May 2009 (UTC)


 * You seem to have uncovered a bug - when you click on a user page, if the "User" namespace has been assigned a form, next to the "create" tab there should be an "edit with form" tab (or even better, "create with form"); but it's not there. I've found a fix, that will go into the next version; let's see how it looks after then. Yaron Koren 03:54, 21 May 2009 (UTC)


 * Uh .. yeah .. right .. this bug seems familiar to me :) I discovered it a few days before, but it didn't seem that important since we have a category defined by the template that is filled with the form and assigning the form to the category works once the user page contains the template call. We're really looking forward to the next version ;) - LosWochos 07:42, 25 May 2009 (UTC)

Problem with the database
While saving the form I'm getting the error

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "". MySQL returned error "1146: Table 'wikidb2.test_smw_ws_articles' doesn't exist (localhost)". Retrieved from "http://localhost/mediawiki-1.14.0/index.php/3"

I am using MediaWiki-1.14.0, SMW-1.4.2, Halo-1.4.3, SF-1.6


 * That's a Halo database table - you should talk to them about it. Yaron Koren 15:19, 22 May 2009 (UTC)

Dynamic dropdown lists
Hi Yaron!

Is there a plan about to extend possibilities of values parameter of parsers? My problem is that I have got a page type based on the next template: ... : ... In the form I can't filter the values of property values field by allowed values of property: ...

... standard inputs ... I think the solution needs Javascript, but because I'm not a JS magician I was looking for something else: I think I need something like this:
 * values from category needs to create a category (Category:Allowed values of property name), but some properties have String type.
 * values from concept needs a concept, but I can't create a concept that lists allowed values of a property (or can I?)
 * I can cut create page operation described above in two steps:
 * 1) When I create the new page (with a create page form) than I fill in the property name only and create a link to another form (add property value form).
 * 2) I send the property name in query string of this link to add property value form, but I can't use this value in values parameter of  parser.

Sorry about my bad english and long post, I hope it was understandable (I'm undestanding less and less). Pipi69e 23:19, 24 May 2009 (UTC)


 * Hi - there's no plan to have Semantic Forms handle the kind of free-form property-addition you're talking about. Yaron Koren 23:45, 24 May 2009 (UTC)


 * Thank You for your reply, Yaron! Now I'm trying to insert a dropdown to a form with parser function of Extension:Simple_Forms. It puts a select element in HTML source of form with suitable id and name values, but SF doesn't process the selected option. What I'm doing wrong?
 * Many thanks for your patience :) Pipi69e 10:31, 25 May 2009 (UTC)


 * Well, I'm not surprised that doesn't work; Semantic Forms only processes those inputs it knows about... I can't think of any solution to your problem, unfortunately. Yaron Koren 20:27, 25 May 2009 (UTC)


 * Hmmm... I think I must redesign my data model. Many thanks once more! Pipi69e 20:49, 25 May 2009 (UTC)

Feature request: Tool Tips on Form fields
It would be nice to have a possibility to define a tooltip text for form fields so I could give a description what the user should put into that field. F.trott 07:16, 27 May 2009 (UTC)


 * Hi, this is a very under-documented feature, but you can already do that using SMW's #info function: just add . Yaron Koren 13:06, 27 May 2009 (UTC)


 * Probably never meant to be used by anybody outside SMW, hence undocumented, but it blends in really nice with the Look&Feel of SMW and I would go for it. Alas, it does not work inside a form: The inclusion of SMW_tooltip.js is missing in the AddData special page. Could you give me a pointer where I should start hacking? F.trott 14:28, 27 May 2009 (UTC)


 * Ok, got something figured out for myself. I just changed addJavascriptAndCSS in SF_Utils.inc: Add $smwgScriptPath to the global statement and add near the end. Works like a charm - as long as you don't use autocompletion. With autocompletion you get the info-icon on a new line. Hmm... F.trott 15:19, 27 May 2009 (UTC)


 * That's strange; I thought I fixed that problem in 1.6 (by making a change like the one you did). What version are you using? Yaron Koren 16:04, 27 May 2009 (UTC)


 * Still on 1.5.4, sorry. I'll try 1.6 then. Thanks. F.trott 18:17, 27 May 2009 (UTC)


 * Ok, I installed 1.7.1. The info-function ist available now. I still have the problem, that the info-icon appears on a new line if I use a text field with autocompletion. Do you have suggestions? F.trott 07:41, 3 June 2009 (UTC)


 * Hm, that's a CSS issue... how about putting the #info call after the the input "label", and before the input itself? Yaron Koren 16:40, 3 June 2009 (UTC)


 * CSS was a good hint. I just put the input fields in a . Thx. F.trott 08:34, 4 June 2009 (UTC)

ERROR -- YAHOO is 'undefined'
I am receiving an error (YAHOO is 'undefined') when I navigate to any form that I have created within my wiki. I believe that the error has to do with autocomplete, but I do not have any properties that are typed as a 'Page' (in which autocomplete is the default). I do know that you are supposed to be able to add the "no autocomplete" parameter to the field's definition, but this effort was unsuccessful.

I am thinking that the error has something to do with the following piece of code: YAHOO.util.Event.addListener(window, "load", attachAutocompleteToAllDocumentFields); To me this looks like it is making autocomplete the default for all fields and overriding all other efforts.

Someone please give me a clue. I have searched everywhere for an answer.


 * The problem is coming from the YUI library. Did you modify your value of $sfgYUIBase, by any chance? Yaron Koren 23:47, 5 June 2009 (UTC)


 * No modifications have been made. Dgennaro 16:31, 8 June 2009 (UTC)


 * Are you using some special skin? If so, try switching to 'MonoBook' and see if the problem is still there. If not, what version of Semantic Forms are you using? Yaron Koren 17:53, 8 June 2009 (UTC)


 * Everything is working great now. We have been using the Ionic's Isapi Rewrite Filter and if I don't fully qualify the $sfgYUIBase (/wikiCode/extensions/YUI/build/" the re-write rules were building the url as 'wikiCode/Special:AddData/extensions/YUI/build/yahoo/yahoo-min.js'.  If I don't define a fully qualified path for $sfgYUIBase I need to determine a re-write rule. Wolcott 18:06, 8 June 2009 (UTC)

Question/Problem...
MediaWiki 1.14.0 PHP 5.2.9-2 (cgi-fcgi) MySQL 5.1.34-community Semantic MediaWiki (Version 1.4.2) Semantic Forms (Version 1.7.1)

I am having a problem with form parsing. Basically I have a form that Uses the same templates over and over again. For example:

I use this template subsubsection to layout these sections on the final page and classify for TOC. What is happening is that all of my sections/subsections/subsubsections are accounted for on the final page, however only the values given to the final instance of those templates are loaded for all of them. So in this instance the final page will have, given i dont enter anything on for the details field:

any thoughts besides going back and only allowing a single instance of each template on this form?

67.97.209.36 18:23, 8 June 2009 (UTC)


 * You can't have a "for template" call more than once for the same template in a form; that seems to be the problem. Yaron Koren 19:09, 8 June 2009 (UTC)


 * Anyway to add this? or is my only option to create separate templates? 67.97.209.36 20:15, 8 June 2009 (UTC)


 * I think that's your only option. What's so bad about separate templates? Yaron Koren 23:19, 8 June 2009 (UTC)
 * The sheer number of them. I think I need to go a different route, this could become unmanagable. 67.97.209.36 13:05, 9 June 2009 (UTC)
 * My main issue is have this page with mutiples of these sections/subsection/subsubsections, but also scattered around it a few multiple instance templates that i use to build a table on the final page. I could move this all to a single template if i were able to embed mutliple instance templates inside the main template. is that possible? an example below.

lets say my section template looks like this



lets say the page created looks like this

is this possible?


 * I don't really understand the example - you want to embed form-definition code in actual pages? In any case, the SF mailing list might be a better venue for this discussion. Yaron Koren 14:25, 9 June 2009 (UTC)


 * I have added what the page would like created, i hope that helps. 67.97.209.36 14:40, 9 June 2009 (UTC)
 * I have also sent an email to the users list for assistance.


 * Apparently I am not the first to want this.
 * http://groups.google.com/group/semantic-forms/browse_thread/thread/131fbc09a3dd3c55/ccf9bd970c19a093?lnk=gst&q=embed#ccf9bd970c19a093
 * 67.97.209.36 15:36, 9 June 2009 (UTC)


 * Don't know if this is any help, but you could create a dedicated page for each of your documentreferencerows (or whatever you want to include more than once) and then in the UISection template do an for all documentreferencerows pertaining to that UISection. Of course for that every documentreferencerow would have to know its UISection.


 * Or - if you want to push it a bit further - you could create pages for the documents (with name, date, author) and pages for the references (with "Has UISection", "Has document"). Thus you could reuse the documents for different UISections. Might save some effort on maintainance when a referenced document changes. F.trott 06:55, 10 June 2009 (UTC)


 * I am not sure i understand how i could create pages for these items separately. My understanding is a single form can only create a single page. these are items that are entered by a user, they are to be presented as table rows. The idea here is a single form, it is actually presented the same as our existing word doc that it used for documentation. I am actually figured out how using templates i could build this into a single template call in the resulting page, problem is with the new parser in media wiki you cannot build a template call from other templates, the result of the templates ends up being a literal string.97.100.99.167 11:45, 12 June 2009 (UTC)


 * Alas, you would not be able to do it all with one form. Instead you would have to first create the list of sections, then fill one form for each documentreferencerow. F.trott 22:47, 13 June 2009 (UTC)

Periods not used in automatic pagenames
I have a form, where the page name of the created page is derived from a text field. Alas, periods are not used and replaced by whitespaces instead. Is this a known problem? Or even a feature? :) Is there a known work around? F.trott 14:27, 19 May 2009 (UTC)


 * Any Suggestions on this? F.trott 15:02, 9 June 2009 (UTC)
 * Have you tried using the urlencode template? http://meta.wikimedia.org/wiki/Help:Parser_function#URLENCODE 67.97.209.36 15:09, 9 June 2009 (UTC)


 * Leads to closing curly braces appearing in the form and an infinite loop when I try to save the form. Since other characters are no problem (e.g. parantheses, ampersands, etc.) I do not think it's an encoding problem. I believe only the period gets replaced somewhere. F.trott 05:11, 10 June 2009 (UTC)


 * Ok, found the responsible str_replace in SF_FormPrinter.inc and just commented it out. Everything seems fine. Question is: The replace was put there explicitly. Why though? Did I just open a new problem? F.trott 06:07, 10 June 2009 (UTC)


 * Hi, sorry for not responding before. Yes, I've seen that same str_replace, and the thing is, I can't remember in the least why it's there. I'll try to figure it out, although I might take out that line anyway. I'm glad it worked for you. Yaron Koren 19:10, 10 June 2009 (UTC)


 * No problem. I'll report if I encounter any problems. F.trott 11:41, 11 June 2009 (UTC)

Illegal mix of collations
We installed SMW and Sematic Forms on MediaWiki 1.11.1. Installation went fine but when we attempted to use Special:CreateTemplate we received the following error:


 * Database error
 * A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:


 * (SQL query hidden)


 * from within function "SMW::getUnusedPropertySubjects". MySQL returned error "1267: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (latin1_bin,IMPLICIT) for operation '=' (***.***.com)".

I found bug 14931 which sounded related.

Our database was latin1 so we locked down MediaWiki ( $wgReadOnly = "..."; in LocalSettings.php) and connected to mysql and submitted

alter database wikidb CHARACTER SET latin1 COLLATE latin1_bin;

then unlocked. This resolved the problem for us. --DavidBiesack 16:17, 12 June 2009 (UTC)

CAPTCHA
Is there anyway to get a CAPTCHA embedded in the form? I have recently been targeted by spammers and need to add a layer of prevention. I am using the ConfirmEdit extension, but it sends users from the form page to the normal edit page.


 * SMF run as previous process, ConfirmEdit is executed when you try to "save" the document, it is possible to modify some options but all they are after submitting the form. Neoshinji 11:12, 24 June 2009 (UTC)

includeonly free text has side effects
"includeonly free text" does what is advertised: It places all template calls generated by the form within a " " tag. Alas ist also places the remaining text within " " with the effect that that text is not displayed on the original page anymore. I think the " " is unnecessary and could be removed. (Alternatively it could be replaced by ", making the " " unnecessary.) F.trott 14:54, 15 June 2009 (UTC)


 * Very interesting - I wasn't even aware of the "onlyinclude" tag until you mentioned it just now. That seems like an ideal solution for this feature - though it might mean that the SF parameter's name will have to change. :) Yaron Koren 01:21, 16 June 2009 (UTC)


 * F.Trott it is possible to need in some strange cases to use the includeonly for this purposes, if you to want to see a real case, please check the Mediawiki Support Desk (concretly the links generated when you post a new question), then I am sure you will understand why it is important this feature. ;) Neoshinji 11:05, 24 June 2009 (UTC)


 * I'm not sure that I understand what you mean. Mediawiki.org does not use semantic forms. F.trott 14:06, 24 June 2009 (UTC)


 * Okay, "includeonly free text" is now "onlyinclude free text" (though the old name still works), and it uses the "onlyinclude" tag, which definitely works better. Thanks for the suggestion. Yaron Koren 16:06, 26 June 2009 (UTC)

"uploadable" does not work with forced uploads
The "uploadable"-Option does not work when I try to upload a file with a bad file type (e.g. MSWord).

My wiki is set to allow forced uploads (i.e. issue a warning about a bad file type and allow to upload anyway). When I try uploading a file the warning is issued, the file uploaded, but I have to explicitly close the javascript window and the filename is not copied into the text field. F.trott 13:56, 24 June 2009 (UTC)


 * Yeah, that's a tough one... I don't know if there's a way around the problem, but thanks for the reminder. Yaron Koren 16:41, 24 June 2009 (UTC)


 * Have fun. ;-) I just switched off the file extension check. It's a risk, but a minor one - my wiki is in an intranet with a fairly small (hopefully not malicious) user group. Btw, is there a way to change the appearance of the upload page? F.trott 18:50, 24 June 2009 (UTC)


 * There hasn't been one recently, no... Yaron Koren 19:27, 24 June 2009 (UTC)


 * Ok, doesn't matter. Thx. F.trott


 * Oh, oops, I misread your question. The real answer is that you can make various CSS changes, through the MediaWiki:Common.css file. You could try adding "form#upload {background: gray}", for example. Yaron Koren 13:36, 28 June 2009 (UTC)


 * I'll try that. Thanks. F.trott 05:12, 29 June 2009 (UTC)

Hiding "view form"
I'd really like to be able to disable "view form" but I'm not quite sure where to do this. Any direction on this? Thanks! --Bsmithme 21:52, 27 June 2009 (UTC)


 * There's no way to do that. Why do you want to? Yaron Koren 13:24, 28 June 2009 (UTC)
 * In our setting we have no need to display "view form" to users who don't have access to the article. We are trying to trim down and clean up the pages so that it contains as few un-needed distractions as possible. --Bsmithme 17:55, 28 June 2009 (UTC)


 * Well, do you have, say, the "View source" or "History" tabs removed? If so, how? Yaron Koren 20:58, 28 June 2009 (UTC)
 * I have those removed using the CSS option and using the extension Dynamic Tabs. None of them apply to Semantic Forms, however, since it is independent. --Bsmithme 00:04, 1 July 2009 (UTC)


 * So Dynamic Tabs doesn't work on "formedit" when you try it? It seems like it might, but I wouldn't know. Yaron Koren 03:29, 1 July 2009 (UTC)
 * That's correct, DynamicTabs isn't setup to handle semantic forms tab (to my knowledge, there is no documentation). I am not that great with PHP code, but I think that if I modify (maybe comment-out) content on line 66+ of SF_FormEditTab.php I think it should be possible to eliminate "View Form"... But I am just not sure. --Bsmithme 21:05, 1 July 2009 (UTC)

Not to belabor the point, but just to clarify - did you try DynamicTabs with a "formedit" setting? Yaron Koren 21:21, 1 July 2009 (UTC)
 * Indeed I just rechecked and I do have "formedit" and also have "viewform" "viewsource" and even "edit" just to see if it would work, but "view form" still appears. --Bsmithme 23:08, 1 July 2009 (UTC)

Category Input Type: No tree displayed
Problem I created a template and a form based on DiscourseDB When I create a page using the form, I get a text box rather than the category tree selection displayed on DiscourseDB. Does Input type=category need to be enabled, or have I gone wrong somewhere?

My Versions The versions installed on my wiki are:
 * MediaWiki (1.13.2)
 * PHP (5.2.6)
 * MySQL (5.0.24)
 * Special pages
 * CategoryTree (Version r37574)
 * Replace Text (Version 0.3)
 * Semantic Forms (Version 1.3.8)
 * SphinxSearch (Version 0.6.1) Not working properly
 * Parser Hooks
 * CategoryTree (Version r37574)
 * ParserFunctions (Version 1.1.1)
 * Semantic MediaWiki (Version 1.4.0)

Template:CategorySelect This is the 'CategorySelect' template. It should be called in the following format: &lt;pre&gt;

&lt;/pre&gt; Edit the page to see the template text.

Form:CategorySelect This is the 'CategorySelect' form. To add a page with this form, enter the page name below; if a page with that name already exists, you will be sent to a form to edit that page.

Category:

This feature would be very helpful for what I am trying to accomplish.

Thanks!


 * Well, I certainly can't fault you for not giving enough information. :) You have an old version of Semantic Forms - if you upgrade, it should work. Yaron Koren 22:15, 30 June 2009 (UTC)
 * That was it. Thanks so much for the tip. The semantic extensions are powerful & elegant.

Forms terminate template calls with newlines
Form-created pages contain one template call per "for template". These template calls are terminates by newline characters. While this leads to good readability of the resulting page the newlines introduce unintended vertical space.

Example: I have a template that only sets an attribute ("document reference") without any resulting text. I use that with "multiple". This results in vertical spaces that get larger the more times I use the template, i.e. the more references I attach. F.trott 08:36, 2 July 2009 (UTC)

Case sensitivity for: field|autocomplete on category=category name
Whether this is a bug or just an omission in the documentation, users should be aware that for the various parameters of the field tag following the format:
 * autocomplete on category = Category name
 * values from category = Category name

The Category name must be capitalized. i.e. category = boats does not work but category = Boats does work

I can only assume the same applies to property = Property name and namespace = Namespace name

Najevi 23:11, 7 July 2009 (UTC)