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

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

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)