Extension talk:Page Forms

Can't seem to get "info|page name=" working?
I'm currently unable to get the "info" tag working partnered with a "page name" variable... My form code is copied below, any hints would be most welcome:



Free text:

and the call for the form:

Clicking the button just directs you to the "main" frontpage of the wiki site. Ashimema (talk) 12:06, 5 July 2012 (UTC)

-OK, I've just narrowed this down to being a problem with "link type=button".. if I leave that out it seems to work as expected? Ashimema (talk) 12:28, 5 July 2012 (UTC)


 * What version of SF are you using? Yaron Koren (talk) 18:15, 5 July 2012 (UTC)


 * Sorry Yaron, should have included that detail in the original post.. Silly me. MW 1.19.0, SMW 1.7.1 and SF 2.4.2 (Also have Results Formats 1.7.1 and Form Inputs 0.5 Installed to.. but don't think they're affecting this issue?) Ashimema (talk) 08:09, 6 July 2012 (UTC)
 * Correction to above, I noticed that Semantic Forms Inputs had a new release i hadn't spotted.. just updated to 0.6. Problem with button type is still apparent. Ashimema (talk) 08:18, 6 July 2012 (UTC)


 * It's definitely not related to SFI. Actually, my guess is that it's due to your URL structure, in one way or another. What's the URL it take you to when you press on the button - is it literally ".../Main_Page"? Yaron Koren (talk) 18:17, 6 July 2012 (UTC)


 * Had a feeling it wasn't anything to do with those related plugins but thought it worth adding them in to give a complete picture. Removing any extra parameters (i.e. pre-fill options) the URL the button takes me to is "http://wiki.sedar.org.uk/index.php?title=Main_Page". With any of the pre-fill bit's added, they just get appended to the url as expected (and work perfectly if no "link type=button" is present). It's a private wiki, but i don't think there' any sensitive data on there yet so I'de happily add you an account if it helps for tracking down the problem? Ashimema (talk) 07:26, 9 July 2012 (UTC)


 * Ah, I didn't know this was a public wiki. Yes, an account would be very helpful - please create an account, and send me the details at yaron57 -at- gmail.com. Yaron Koren (talk) 12:43, 9 July 2012 (UTC)


 * Cheers Yaron.. I've just sent requested login details to your email... Ashimema (talk) 12:57, 9 July 2012 (UTC)

For future reference: this turned out to be caused indirectly by the fact that the URL contains a '?'; so it's a bug in SF, but one that's somewhat difficult to fix. Switching to "link type=post button" made the problem go away. Yaron Koren (talk) 13:01, 10 July 2012 (UTC)

Unintended Behaviour of parameter?
When using a combination of input type=dropdown and values from category=category name I was expecting only the pages in said category to be displayed in the resulting dropdown field, however all pages and sub-categories were included instead. Is this the intended behaviour and if so, is there any way to achieve the behaviour I'm attempting to achieve explained above? --Ashimema (talk) 14:30, 12 July 2012 (UTC)


 * I can't reproduce that. Is this behavior viewable on a public URL, or could you replicate it on a public wiki? Yaron Koren (talk) 20:24, 12 July 2012 (UTC)

Hi again Yaron.. I seem to be asking allot of you at the moment, Sorry! I'll try to replicate this on a public URL, but as you've probably guessed this is on the same private wiki as the above query was related to (I've not yet updated it to use short url's as i'm not 100% familiar with how to do it in my subdomain setup). I've not yet removed your account on that wiki though so your welcome to take a look in there if it helps again? The form in question is --Ashimema (talk) 11:10, 13 July 2012 (UTC)


 * Hi, I just looked at the form - did you mean to say that the problem is that the input includes all pages in subcategories? And did you mean "in addition" instead of "instead"? If so, that's not a bug - that's the desired behavior, to include pages in subcategories as well. If you think that's bad behavior, it's worth discussing it - maybe there should be a setting for it. Yaron Koren (talk) 12:19, 13 July 2012 (UTC)

Hi Yaron, that is correct (Sorry for the poor description). I see now where I'm going wrong, I'de interpreted as in category to mean just those pages within the top level category, not the sub-categories as well. Now that I understand that, I can probably manipulate my category structure such that the problem is alleviated, although I do think an option would be an nicety on the feature itself. I wonder what anyone else thinks? --Ashimema (talk) 12:46, 13 July 2012 (UTC)

Conflict with xcache?!
I've added xcache to my php installation. And suddenly I cannot access SpecialPages main page, and get an error Fatal error: Cannot redeclare class SFUploadWindow2 in ...\extensions\SemanticForms\specials\SF_UploadWindow2.php on line 1117

Is there any explanation for that?! that is definitely the only change I've made. Once I remove xcache reference from php.ini, the problem is resolved. My wiki is on MW 1.18.0, PHP 5.2.17, IIS, SMF 2.3.2, SMW 1.6 Osishkin (talk) 03:25, 18 July 2012 (UTC)


 * Hi - other people have reported that problem before, but no one has come up with a solution yet. If you upgrade SF, you'll at least get a different error message - it'll refer to "SFUploadWindow" instead of "SFUploadWindow2". I have a hunch, though, that if you upgrade PHP, the problem will go away: in all three cases I know of now for that issue, PHP was at 5.2.17. Yaron Koren (talk) 03:57, 18 July 2012 (UTC)


 * I see. I'll try having a go at PHP 5.3 just in case, though that obviously may break other code...is there perhaps a simple hack to just remove the reference to the SemanticForms special page, so that SpecialPAges won't parse it? or is it embedded too much in the code?


 * You definitely don't want to remove the UploadWindow special page - it's important. Yaron Koren (talk) 01:21, 19 July 2012 (UTC)


 * I dont mind doing that, I have no use for it myself. Osishkin (talk) 04:36, 19 July 2012 (UTC)

One link->two autoedits?
I need to have a single link generate two autoedits, where the sequence is important. Is there a trick to doing this? So far, I have tried:
 * nesting two {{#sfautoedit tags (one is the link text of the other). Only the inside one runs; it looks like the HTML generated by the parser function gets all muddled.
 * creating a hook function on the ArticleSaveComplete hook of the first one, calling the second one from PHP. It appears that when ArticleSaveComplete is triggered, we are still inside the edit session, and mediawiki refuses to initiate one edit session inside another (I think).

Any other ideas? I'm thinking of creating a new parser function that will call the two autoedits from PHP in series, but I would prefer to put as much of it into wikicode as possible, rather than PHP.


 * My guess is that a new parser function would be the only way to do that, but I could be wrong. Yaron Koren (talk) 05:32, 23 July 2012 (UTC)

Different form behaviors when creating or editing
Hello,

I´d like to implement a different behavior to forms when they are creating a new register or editing an existing one. For example, when creating I want all fields to be non restricted, but once the page is created I´d like to block users from editing some fields (used to define the page name).

I´ve tried to use parserfunctions to echeck if the title had the Edit word but unfortunatelly doesn´t return anything.

Any suggestions?


 * I don't believe that there's any way to do that. But are you sure that it's a good idea in the first place? Obviously, it's good for the page name and the data on the page to match up. But on the other hand, if there's an error in one of those fields, shouldn't it be fixed? Yaron Koren (talk) 05:35, 23 July 2012 (UTC)


 * Yes, for sure! Unfortunatelly I couldn't find a way to change page's title after the creation process so any changes the user may add to the fields in question won't update the page's title. Two things I though about: using a GET variable and parsing it in the form so I can add the restricted parameter when required or using DISPLAYTITLE magic word, but this way the link for the page won't fit the title. (Gabriel Simões - 23 July 2012)

Creating Form issues
First let me just say that I LOVE this extension. It is amazingly helpful so please don't let my comments sound like an ungrateful jerk. I am having a couple of issues with wehn using the Special:CreateForm.

The first issue is the dropdown menu that appears when I try to "add a template" does not appear in alphabetical order most of the time.

Second, the values do not seemed to be mapped correctly. So if for the first field I give it a form label of "FIELD ONE", the second field I give a label of "FIELD TWO" and so on, Those labels get all jumbled up so that the first field has a label of "FIELD EIGHT" for example.

Finally, one thing that is very frustrating is that when I click on "show preview" I get a wonderful look at how the form will appear when I am done, and I can see the code associated with it, but I am no longer able to use the AWESOME form to create the form. One of the reasons I love this tool so much is the interface that it gives you to create a form. It would be nice to be able to continue to edit these forms using this same interface.

--Zackmann08 (talk) 16:32, 30 July 2012 (UTC)


 * Hi - great, I'm glad you like SF. For the first issue - that's an issue I hope to look into. The second issue sounds like a very major one, if true: are you saying that you select some value in the form, and then a different value shows up on the resulting page when you save? The third issue is true - you can only use Special:CreateForm to create forms, not edit them. The Page Schemas extension was created in large part to get around this issue - it might be worthwhile for you to try it out. Yaron Koren (talk) 19:05, 30 July 2012 (UTC)

SemanticForms_registerInputValidation under MediaWiki 1.19.1
I'm seeing a strange bug that I would appreciate some assistance with. While the information below may not be enough for you to diagnose the problem, I'll at least initially attempt to be brief in the hopes that somebody else will recognize that they have had a similar problem and solved it.

I am building a SematicForms input type extension. I need to do some custom validation on the field, so I am registering an input validation routine using SemanticForms_registerInputValidation. I am using SemanticForms version 2.4.2 with Semantic MediaWiki 1.7.1. Under MediaWiki 1.18.0, my code works fine. Under MediaWiki 1.19.1, all other things remaining the same, I find that the SemanticForms_registerInputValidation function is not being bound to my field. That is, when I use FireBug to examine jQuery('#input_2'), which correctly points to my field using both versions of MediaWiki, none of the SemanticForms_* routines that appear in the list of entries for the object under MediaWiki 1.18.0 are there under MediaWiki 1.19.1. Perhaps this is due to the different jQuery version? Here's the segment of code in question:

var field = jQuery('#input_2'); var registerInputValidation = field.SemanticForms_registerInputValidation; registerInputValidation(   input_2_sfuniqueproperty_validate,    ['info_2', 'ABC', 'Long Name', '']  );

In this code, field gets set correctly. However, the registerInputValidation function is undefined in MediaWiki 1.19.1 but correctly defined in MediaWiki 1.18.0. Any suggestions would be much appreciated.
 * I was able to fix the problem. There was a race condition where the code above was being called before the code that attaches SemanticForms_registerInputValidation to the input field was executed. I'm guessing that the change in jQuery version between MediaWiki 1.18 and 1.19 subtly changed the initialization order. My code was not following strictly the same pattern as that in SemanticFormsInputs. I went back and restructured my code using TimePicker as a model, and now it works perfectly. It appears that I was just lucky that it worked in MediaWiki 1.18.

WYSIWYG worked in SF 2.3 but is not working in SF 2.4
Hi,

I added the one-line-patch from ontoprise to get the WYSIWYG extension work for the free text field in SF 2.3 and it was working fine when adding ?mode=wysiwyg to the url. After updating SF to version 2.4 it is not working anymore.

Error message in Firebug (ResourceLoader in debug mode): uncaught exception: [CKEDITOR.editor.replace] The element with id or name "undefined" was not found.

Any idea? Thanks a lot for support! --Filburt (talk) 10:00, 1 August 2012 (UTC)


 * Hi - personally, I don't know anything about setting up the SMW+ stuff. Have you tried contacting the SMW+ developers? Yaron Koren (talk) 13:43, 2 August 2012 (UTC)


 * Hi Yaron, thanks for the reply. As I know ontoprise (the SMW+ developers) became insolvent in June, therefore it is not possible to contact them anymore. But there are some community folks making the WYSIWYG extension better and also working with MW 1.19. The mentioned patch for SF is only to add $output->addModules( 'ext.wysiwyg.core' ); in /extensions/SemanticForms/includes/SF_Utils.php line 292. Nothing else needed to be changed in Semantic Forms 2.3 that WYSIWYG was working with it. It would be really great to get it working again in SF 2.4 and independent from the former SMW+ stuff. Probably it needs only some samll changes in SF 2.4 ...


 * Thanks in advance!
 * --84.50.58.57 07:13, 3 August 2012 (UTC)

Conflict with Extension:Inputbox
I haven't done too much testing but after I added an  (namespace and form existing, of course) but to no avail.

Not compatible with 1.19.x? Or did I get something wrong?

Btw., the trick works with categories, but for some reason I need it in NS.

Thanks in advance for advise.

Bernhard


 * Hi Bernhard. I have a similar setup working on one of my local wiki's. The Wiki name is "Sedar" so there is a default namespace with that name (i.e. pages "Sedar:*")  It is in this namespace that your custom namespace definition needs to reside. Example: So, in my wiki, we've got a customer namespace defined called "Suggestion" (i.e. in the Localsettings.php file we have

define("NS_SUG", 500); define("NS_SUG_TALK", 501); $wgExtraNamespaces[NS_SUG] = "Suggestion"; $wgExtraNamespaces[NS_SUG_TALK] = "Suggestion_talk";
 * 1) Custom Namespace for Suggestions #


 * You may also want

$smwgNamespacesWithSemanticLinks[NS_SUG] = true; $smwgNamespacesWithSemanticLinks[NS_SUG_TALK] = false;


 * to enable semantics on in that namespace.


 * And then on the page - Sedar:Suggestion:

Has default form::Suggestion


 * Ashimema (talk) 08:48, 6 August 2012 (UTC)