Extension talk:Page Forms

"Minor edit" and "watch" Buttons in form do not work
My settings:

MediaWiki 1.16.1, Semantic Forms (Version 2.2.1), Semantic Forms Inputs (Version 0.4.1), Semantic MediaWiki (Version 1.6), WikiEditor (Version 0.2.0), Vector (Version 0.2.0). When editing a page with a form the buttons don't show up but some html-code like  minor edits Could there be some incompatibility with another extension? Some "neighbor-wiki" of ours does not have this problem, the do have older versions of Semantic Forms and SMW. Thanks --Eilan Ardanos 14:42, 7 October 2011 (UTC)


 * Hi - that's bad. Could you try temporarily un-including the WikiEditor and/or Vector extensions, and see if the problem persists? My guess is that it's the interaction with one or both of those that's causing it. Yaron Koren 14:45, 7 October 2011 (UTC)


 * Hi, thanks for the quick response. I enabled WikiEditor: same problem. Then I enabled Vector: same problem. Then I enabled both: still same problem. Maybe I should enable all my extensions one by one and see if any other extension is causing it. I will try next week again and report my findings. --Eilan Ardanos 15:00, 7 October 2011 (UTC)


 * Okay, that's helpful. Though I assume you meant "disabled". :) Here's another question: do you have more than one form on your wiki, and if so, does this problem happen for all of them? Yaron Koren 15:44, 7 October 2011 (UTC)


 * Oh, sorry, I did mean "disabled". I do have more then one form and the problem appears in all of them. --Eilan Ardanos 11:50, 10 October 2011 (UTC)

Unclear includeonly/noinclude behavior for preload
Hi, I would enjoy the 'onlyinclude free text' tag in a form if it would mean that only the freetext is included in the preload of the free text on another form. But that doesn't happen. It seems that only the 'noinclude' tag in a page prevents parts of the page to be included in a preload. Other tags such as includeonly and onlyinclude (why having these two tags anyway?) don't seem to have any effect.

My favorite would be that the 'onlyinclude free text' feature does the trick, because it is easy then to create preload pages with a form that takes care of the semantic properties of that preload page.

--AdSvS 06:54, 11 October 2011 (UTC)

Heads-up regarding autoedit and Abuse Filter
This is just a heads-up regarding Extension:AbuseFilter; it seems that if you have a rule setup that will trigger on an autoedit, and which rule either kills an edit OR prompts a notice, an attempt to use #autoedit will fail with "Error: A MediaWiki extension prevented the modification of the target page." I was testing the autoedit functionality when I discovered this, whereas I have a rule setup to notify users who haven't entered edit summaries. I'm not yet sure how to circumvent this problem since it doesn't appear that SF will allow me to specify an edit summary for autoedits, or since AbuseEdit can't differentiate and allow this type of edit. Thorncrag   21:39, 11 October 2011 (UTC)
 * So I've been thinking about this, and it seems to me that it would make sense that the autoedit should leave some kind of edit summary - that seems to be the standard. Also it makes sense from a page history perspective, to ascertain which edits were made by the automated process and which were not.  What do you think about adding summary as a parameter to the autoedit parser?     Thorncrag    17:44, 12 October 2011 (UTC)


 * Good idea. Will do that. Cheers, F.trott 08:38, 17 October 2011 (UTC)
 * In the latest SVN you can now use the summary parameter with the autoedit parser function. If you omit it, a standard summary is inserted. F.trott 07:24, 18 October 2011 (UTC)
 * Just tested this and it works perfectly - thanks! By the way, this solves some issues I had finding a way to better automagically create pages with templates so double thanks.    Thorncrag    17:14, 18 October 2011 (UTC)

Okay so I'm here brainstorming. I'm thinking about splicing the functionality of forminput and autoedit. The goal would be to have a form input where you specify the target page (instead of having it hard-coded in the autoedit tag) and the autoedit which makes the automatic editing for that page. This could have numerous useful applications like quickly creating new lightweight tools such as for maintaining pages. Is this something that can be cobbled together already? Thorncrag   17:34, 18 October 2011 (UTC)


 * That's an interesting idea, though somewhat weird - it would basically apply the same set of changes to any page name that was typed in, even a string typed in in error. Maybe a better idea would be to put add one or more #formedit links to each of the relevant pages, via a template, so that users can apply those automatic edits only to pages where it makes sense to do it? Yaron Koren 18:16, 18 October 2011 (UTC)
 * There are two examples I can think of - and perhaps there's already a better way of doing this that I'm not grasping. One would be, let's say you wanted to create candidate and ballot pages, you would enter the name of the page (the candidate) and the page would be created automatically.  Another example might be to create report pages so that the input would be the name of the page to be created.      Thorncrag    16:46, 19 October 2011 (UTC)


 * That's reasonable, yes - though, in both cases, wouldn't there be a good chance that the user would want to add some information in about the candidate/report/etc. at the same time? Yaron Koren 16:51, 19 October 2011 (UTC)
 * That's a fair point. I think I'm stuck on the notion that the created page might transclude other templates and pages with bits of information.  In my case, I was thinking of a way of guiding the user through a process where they would create a "landing page" using the autoedit process, and that landing page would guide them through a series of other processes and components.  But I suppose that's not a very common way of using these features.     Thorncrag    17:00, 19 October 2011 (UTC)

Fatal error: Unsupported operand types
MW 1.17/Semantic Forms:2.2.1

I am trying to create an upload field and get the following error when I upload an image:

Fatal error: Unsupported operand types in /home/offgrido/public_html/foreclosurepedia/includes/parser/LinkHolderArray.php on line 41

My code is: ! Image

I run the wiki on https and the lock does appear next to the upload button. My site is here. The form cannot be accessed by the public though. Any help would be appreciated! --Coffeehound 03:58, 17 October 2011 (UTC)

Spoke with Yaron on #MediaWiki and was told this may have something to do with an issue surrounding Semantic Maps and may be corrected by the next build in Semantic Bundle. Will report back when I install the new build. --Coffeehound 04:32, 17 October 2011 (UTC)

Upload fancyBox asking me to log in?
When i click upload next to my field for an image, i get fancy box showing the message "You must be logged in to upload files" with a login link. If i click the link i get a blank fancy box window. I had this working somehow earlier on a different form but deleted it. My Property type is text is that ok? Heres my field code...

! Image:

Image property is set to "This is a property of type Has type::String." does this need to be anything special for a file? I sometimes get session data dropped while i'm working but don't know how to track it down, that is the only other thing i could think would cause it. I tried using admin, sysop, and user logins and all had the same problem.

Thanks!