Extension talk:Page Forms

Where do forms get stored or loosing forms through update?
MediaWiki 1.17, Semantic Forms (Version 2.2.1), Semantic MediaWiki (Version 1.5.6)

Might it happen, that through updating from SF 1.8 to SF 2.2.1 I have lost my forms? Are there any update scripts that I should run and I'm not aware of? Where are forms stored (in case I'd like to re-create them from a backup)? Thanks a lot in advance,

--Francis


 * Each form is stored in its own page in the "Form:" namespace. There shouldn't be any danger of losing forms. Yaron Koren 23:16, 23 October 2011 (UTC)


 * Thanks for answering Yaron. Still in http://en.wiki-products.org/Special:Forms the forms that originally were there are missing. Should I recreate each form individually or is there a way I can retrieve them from a backup? For instance there should be a form called "deodorant". I'm using the $sfgNamespaceIndex = 150 maybe there is a mistake. Compare [Namespace in V1.4] --Francis


 * Ah - I guess try removing that setting, and see if the forms show up again. This sounds like a namespace issue. (Though I don't know why upgrading from 1.8 to the most recent version would have caused it...) Yaron Koren 14:43, 24 October 2011 (UTC)


 * Unfortunately not. So coming back to my former question: Can I retrieve forms from a database backup and if yes, where shall I look for it (given access with phpmyadmin). I think I would hand copy the about 10 forms from the database and create new forms again.

--Francis


 * The relevant database tables are "page" and "archive" - maybe the easiest solution is to find the relevant rows in those tables, and change the namespaces to the right value (either 106 or 150, I assume). Yaron Koren 19:16, 24 October 2011 (UTC)


 * Thanks Yaron, I have looked into that and could at least see, which articles are effected and that the namespace should be 150. Another point is: In SF (Version 1.8.5) which I had installed before, I called include_once( "$IP/extensions/SemanticForms/includes/SF_Settings.php" ); from the localsettings.php. Now in 2.2.1 I'm calling include_once("$IP/extensions/SemanticForms/SemanticForms.php"); and SF_Settings.php is not existend anymore. Is there the mere possibility that $sfgNamespaceIndex should be called differently from Version 2.2.1. (because I couldn't find in the extension any occurrence where the extension would use $sfgNamespaceIndex). --Francis

"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!

Multiple and "show on select" not working together
I've got a form that includes a dropdown field that gets filled with certain values based on selection from another dropdown field. I'm using on show on select= and have div id sections, and it works fine.

But when I indicate multiple for the form, the first record works fine, but the next few records show the fields cleared.

I created an example of what I’m talking about on Referata:
 * http://scratchpad.referata.com/wiki/TestMultipleShowOnSelect

Perhaps with multiple there are some instance problems, perhaps label issues that keeps this from working while editing. Is there any way to do the equivalent of what I'm doing with multiple, or do I have to change to saving my records on separate pages and using a query to make them appear on the same page? Is this a bugzilla candidate?

Thanks --Salquint 02:37, 22 October 2011 (UTC)


 * Hi - I see what you're trying to do, and unfortunately it can't be done. You can't include the same template field in a form more than once. I'm pretty sure that what you're trying to achieve is different allowed values for a "secondary" field based on a "primary" field. That unfortunately won't be possible until there's a "values dependent on" parameter, which is right at the top of the current planned features list. I don't know when it'll get done, though. Yaron Koren 16:15, 23 October 2011 (UTC)
 * Thanks for the verification Yaron, that makes sense. I'll skin this cat another way for now. --Salquint 21:41, 23 October 2011 (UTC)

Show on select not working
Hi all,

I can't get the "show on select" to work. II simply do not get a drop.-down menu but a simple text input. at the same time all the diifferent section are rendered. I have tried this with the code of the discoursedb, too. It is not working either.

I am running MW 1.16.0 and Semantic Forms 2.2.1

I have used firebug to copy some of the code from my wiki and from discoursedb.

My Wiki […] Publication type:     […]

discourseDB […] Publication type:     […]

I seems that in my wiki the wrong class for the field is used. I am no programmer, so I have no idea whre to go from here :-(

Any Help is appreciated,

Moritz, Karlsruhe, Germany 24.10.2011 14:15 GMT+1


 * If the input is a text input, not a dropdown, then "show on select" won't work - so that's the problem. You need to set the SMW property for that field to have a set of "allowed values" - maybe that's the issue? Yaron Koren 13:38, 25 October 2011 (UTC)