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)