Extension talk:Page Forms

Always display query string?
How can I make my form to display a query result page, so that the query string is always shown in the URL line? is there a simple setting for this? Osishkin (talk) 06:55, 1 March 2013 (UTC)


 * You mean, have Special:RunQuery show its values in the URL query string? I don't think so; why do you want that? Yaron Koren (talk) 13:40, 1 March 2013 (UTC)


 * I want to allow users to share (facebook, email etc) pages of query results using an AddThis button. But since the query string is not displayed (I assume due to using a POST request), this is not possible Osishkin (talk) 22:09, 1 March 2013 (UTC)


 * Hm, that's true. Maybe a "link to these results" link at the bottom of any set of results would fix the problem? Yaron Koren (talk) 14:19, 5 March 2013 (UTC)


 * I can create that manually, but it would be much better to simply have the results in the URL line, so the AddThis button may be used Osishkin (talk) 14:59, 5 March 2013 (UTC)


 * By the way, this would also be useful for tracking search queries with Google Analytics Osishkin (talk) 12:01, 9 March 2013 (UTC)

Create dynamic form
I am trying to create a form describing a multi-step process, where the number of steps isn't necessarily known (e.g. imagine a system for creating recepies, where the number of steps may vary). Is it possible to create a form which is dynamic, i.e. that it is possible to add new fields on the fly? (Similar to the CreateTemplate page where you have an "add field" button)

MathiasLidal (talk) 12:52, 5 March 2013 (UTC)


 * Yes - that's what multiple-instance templates are for. Yaron Koren (talk) 14:08, 5 March 2013 (UTC)

Preload of text input field with special string
Hello, I need to preload a text input field with a special string which is joined together by the string "hvg" plus the hexadecimal Unix timestamp. The PHP formula would look like:

$var = "hvg". dechex(time)

Can I do this without writing an own extension? If yes, how?

Many thanks in advance for any support!

Cheers...

--Sochin67 (talk) 15:46, 8 March 2013 (UTC)


 * For something that specific, I think you'd need an extension. Yaron Koren (talk) 20:32, 8 March 2013 (UTC)


 * Created my first little extension and it works ;-) --Sochin67 (talk) 20:38, 17 March 2013 (UTC)

Embedded template: list of values for field
I know how to define list of values for property so field for this property becames dropdown list with this list of values. But is it possible to define such behaviour for embedded template (with multiple) that defines subobject? Are subobject's fields real properties? Please, give me a clue or small example. Thanks


 * Yes, the fields in a #subobject call are real properties, and they should be defined on the wiki - including a list of allowed values where necessary. It could be, though, that Semantic Forms won't make the connection between a field and its property, if you use #subobject - if that's the case, you should add a parameter like "|property=property name" to each of those fields' tags.


 * Thanks, it works!

Subpage behaviour
Hello, In SF 2.5.1 I've noticed that pages within a subpage (Namespace:Basepage/Subpage) seem to ignore default form (in both NS and category). I think it didn't happen in some 1-2 years old versions. Is this an intended behaviour? If so, how should I fix this? Thanks! --Toniher (talk) 17:55, 13 March 2013 (UTC)


 * Yes, subpages no longer get the default form for their namespace - the thinking behind it was that subpages rarely have the same structure as main pages. As for the category not having an effect either - that sounds like a serious bug. Or do you just mean that page A belongs to a category, but page A/B doesn't get the form for that category? Also, out of curiosity, what namespace is this? Yaron Koren (talk) 21:12, 13 March 2013 (UTC)
 * Hi Yaron. It's a custom Namespace (Private). However, I'm wrong: it works with categories. No with subcategories (but I see you already commented it here). Mystery solved. Thanks! --Toniher (talk) 10:18, 14 March 2013 (UTC)

Autocomplete on categories with SQLStore3
There is aapparently problem with the "values from category" option. I use it with a combobox, but it pulls every page in the wiki on autocompletion instead of restricting it to the pages from the appropriate category.


 * MediaWiki: 1.20.2
 * Semantic Forms: 2.5.2
 * Semantic MediaWiki: 1.8
 * SQLStore3

--- I'm seeing the same thing too (also with "values from property"). It affects the parameter values for the invoked template.
 * MW 1.20.0
 * SF 2.5.1
 * SMW 1.8rc1
 * SQLStore3


 * That one is less surprising - only SF 2.5.2 (and newer versions, once they come out) is supposed to fully support SQLStore3.


 * Okay, I checked out SF 2.5.2 and am still seeing same thing.


 * I tried to duplicate this, and looked into the code, and now I really can't understand what's going on. "values from category" works fine for me; and in fact, the code doesn't use SMW querying at all, so the use of SQLStore3 shouldn't be affecting it. A few questions: are these wikis where the problem is occurring public? And if not - is this using "remote autocompletion"? And does it really seem to match on every page, or is there some pattern to the set of pages that get matched? Yaron Koren (talk) 15:49, 1 April 2013 (UTC)

Delete a page using a form
Hi Yaron,

thanks for the great work! I use SF 2.5.1 on SMW 1.8/MW 1.20 with formlink and popup to create and edit items on a list (saved as subpages). Do you see a possibility to delete a page as well using SF, maybe using a standard input or a parameter for the formlink? Or could one set a link with parameter action=delete and enable popup for it as well?

Thanks in advance

--80.149.87.126 13:57, 15 March 2013 (UTC)


 * I don't think there's any way to do that - you would need a separate parser function to handle deletions. (Though it may not be a good idea anyway.) Yaron Koren (talk) 22:12, 15 March 2013 (UTC)


 * Ok, I can see that. Would it in general be possible to popup a regular link to an internal (or external?) page? Currently I have set a link to the regular ::action=delete page (users have the right here), but it somewhat destroys the user experience by not opening the page in a popup.


 * Thanks! :) 80.149.87.126 08:49, 18 March 2013 (UTC)


 * That's an interesting idea, but I'd say it's outside the scope of Semantic Forms. Yaron Koren (talk) 12:16, 18 March 2013 (UTC)

Form to create Google map with multiple markers
Dear Yaron,

I'd like to set up a semantic form to create one Google map with multiple markers and - if possible - separate labels for each marker.

I have managed to put together a form that creates one map with one marker and I also added an additional text field for defining a label for that marker. I could also make this map template "multiple" but of course this adds more maps rather than additional markers inside one map. Could you give me a hint how to tackle this?

Many thanks!

--Sochin67 (talk) 20:36, 17 March 2013 (UTC)


 * I don't fully understand your setup, but you could have the multiple-instance template store the data, and the "main" template (if there is one) query that same data, and display it in a map. Yaron Koren (talk) 20:49, 17 March 2013 (UTC)


 * Hi Yaron, I thought it wasn't a good idea to store and query data on the same page, because the query might not produce the right result? --AdSvS (talk) 11:46, 18 March 2013 (UTC)


 * It should be fine - the issues only come if you then try to store those query results. Yaron Koren (talk) 12:14, 18 March 2013 (UTC)

use dropdown broken on input type category?
Hi Yaron,

input type category will not show up as a dropdown using SF 2.5.1 on SMW 1.8.0.2 and MW 1.20.2. only shows up as category tree. Is this a bug, or do I need some more configuration? Additionally: Is it possible to use show on select on a category tree using dropdown? Thanks for your support!

Kind regards --80.149.87.126 09:05, 18 March 2013 (UTC)


 * You just need to upgrade - that feature was only added in SF 2.5.2. I don't know if "show on select" will work with it, actually... Yaron Koren (talk) 12:12, 18 March 2013 (UTC)


 * Thanks Yaron - that did it. I didn't see, that it has just been added recently. I tried show on select, and it does not work out of the box, maybe, it can be added in the future? --80.149.87.126 13:30, 20 March 2013 (UTC)


 * Okay - yes, it's not surprising that it doesn't work. And I agree that it would be great if it could work in the future. Yaron Koren (talk) 18:51, 20 March 2013 (UTC)

Dropdown menu with blank spaces
Hi Yaron,

I updated from SF 1.8.3 to SF 2.5.2 (along with MW from 1.14 to 1.19, and SMW from 1.5g to 1.8.0.4). SMW's data was repaired after the update and Semantic Drilldown seems to indicate that the new data is fine. I had several dropdown menus created with the "values from category" option that didn't show any more, but I took that as a change in functionality that I could fix that by adding "input type=dropdown" to the template. However, categories with spaces in those fields cannot be searched now. Whether I use the dropdown menu or go back to the text box, the search returns no value. Categories without spaces do work. I'm rather shocked that no one else has the same problem. It must be me doing something wrong, but I've failed to find it. My first contact with SF has been this update.

Is there anything one should do to be able to use categories with spaces in search fields?

Many thanks in advance!

Best,

Oscar


 * By "search", do you mean the standard MediaWiki search? If so, it doesn't sound like a Semantic Forms issue. Yaron Koren (talk) 12:13, 18 March 2013 (UTC)


 * No, no, I mean the query search. The "Run query" button in the form that I created. Sorry about the confusion. If I select anything with a space from a dropdown menu, "Run query" returns no result. If I turn the dropdown menu into a text box or a combo box and enter the first non-space characters of that same entry, it does return the correct results. Entries with no spaces in the dropdown menu do work as well. It really looks like it doesn't like the spaces for some reason. Thanks!


 * Hi Yaron, I was wondering whether you would have some hint that I could try and see if it helps. Thanks! --141.5.11.5 09:30, 25 March 2013 (UTC)


 * Hi - this actually still doesn't sound like a Semantic Forms issue; it sounds like a Semantic MediaWiki issue. If you call the relevant #ask query directly, and pass in those same parameters, you should see the same problem. Yaron Koren (talk) 13:50, 25 March 2013 (UTC)


 * Hi Yaron, I'll check with them. Thanks for the hint. I took for granted that SF was running the search using SMW, not that it was kind of a front-end to SMW's search functions. I'll drop a line when they answer, so that this thread can be consider closed. --141.5.11.5 09:16, 26 March 2013 (UTC)

Semantic Forms with MathJax
Was not a Semantic forms issue, see Semantic Mediawiki with MathJax for details.


 * The whole thing sounds strange - especially the MathJax part. What are the full contents of the "Machineinfo" template? I'm guessing #forminput is not the issue. Yaron Koren (talk) 15:47, 18 March 2013 (UTC)


 * Hello Yaron. I can reproduce the fault on a clean Wiki (1.20.3) with only the Semantic Mediawiki and MathJax extensions enabled. In this case it does not matter if Semantic Forms is enabled or not and it seems that it is solely a MathJax issue. Because it belongs on the Mathjax page I moved this discussion to the MathJax talk page (Semantic Mediawiki with MathJax. I was so free to clean up the rest of this discussion so people do not get confused. Thanks regards, --Jongfeli (talk) 11:07, 21 March 2013 (UTC)

Form adds '}' on each save
Hi Yaron,

I have a pretty big form (there are about 60 fields in several templates). The problem is that each time that I edit a page with the form, it adds a '}' and several newline chars at the end of the page. So, if I edit it n times, I get n '}' (and newlines as well). I haven't figured out why. I dont think it is a typo in the templates (it wouldnt accumulate the '}'). I would appreciate any help :) Thanks in advance.

Benjamin. --201.217.136.181 16:20, 18 March 2013 (UTC)


 * That sounds very bad. Could you try to duplicate this problem on a public wiki, like http://scratchpad.referata.com? Yaron Koren (talk) 18:17, 18 March 2013 (UTC)


 * Well, we found the error finally. It was a typo! We had an extra '}' in a field declaration in the form:

... } ...
 * that went into the invocation of the template, and resulted in the described behavior. Thanks for the quick response and your great work :)


 * Cheers, Benjamin.

Advice welcome for Wikiteck/MediaWiki community proposal
Hi, I'm drafting a proposal to improve the ways we reach out to contributors and connect them to MediWiki/Wikimedia people and tasks. So far the proposal is relying a lot on Semantic Forms for a first implementation. However, I lack the expertise, so our advice would be more than welcome. For instance, I'm wondering whether Semantic Forms would be the way to go for user groups. Please watch that page and feel free contributing feedback and help. Thank you!--Qgil (talk) 01:16, 24 March 2013 (UTC)

Edit with form on main namespace
Hi Yaron,

I want to show a form for all articles located in my main namespace. My wiki name is "Test-Wiki". I tried to place "has default form" on the following pages, but wasn't successful so far (Seiten is the German Main Namespace): Test-Wiki:Seiten, Test-Wiki:(Seiten), Test-Wiki:Main, Project:Seiten, Project:Main.

I tried other namespaces like User (Test-Wiki:Benutzer) and Templates (Test-Wiki:Vorlage) and the "edit with form" worked fine. So it seems to be an issue with the main namespace only. Do you have any idea? Thanks! --Stefahn (talk) 11:30, 26 March 2013 (UTC)


 * It should be "Test-Wiki:Startseite". That's the current German-language value; I don't know if "startseite" is a good translation for "main". In any case, the SF code should always handle the English-language value as well; that would make things easier. Yaron Koren (talk) 12:23, 26 March 2013 (UTC)


 * Thanks. With Startseite it works. Startseite means Homepage. Don't really understand why it's not "Seiten" since this is the name of the main namespace - "(Seiten)" also shows up in the advanced search... Thanks anyway :) --Stefahn (talk) 14:14, 26 March 2013 (UTC)

Autocomplete only works after hitting space bar
Hi again,

On several forms I use #arraymap to allow multiple values for the same field (with coma as delimiter). Also I use the beautiful autocomplete function. Now if I come back to an article and want to add another value to the field, I first have to hit the space bar before I get autocomplete suggestions. If I just start typing letters I don't get suggestions. Is this the way it should work? Is there a workaround so that one doesn't have to hit space? Thank you so much for your excellent work! --Stefahn (talk) 14:42, 26 March 2013 (UTC)


 * That's true - you need a comma and a space before a value for that value to get autocompleted on. I never really thought about it, but I can see how it could be annoying, or confusing. I'll try to look into it. Yaron Koren (talk) 16:12, 26 March 2013 (UTC)

I noticed one more thing today: It seems unpossible to edit older revisions of a page when using "edit with form". Is that true? If I select an old version and click "edit with form" I am always redirected to the latest version. PS: I only need this option if I want to revert some changes sometimes. Stefahn (talk) 18:28, 26 March 2013 (UTC)
 * Thanks for looking into this. Love your work and support!


 * Thanks! Yes, there's no way to do "edit with form" on an older revision - I just thought it would add confusion without any clear benefit. How would this help, when reverting changes? Yaron Koren (talk) 19:25, 26 March 2013 (UTC)


 * Okay, thanks for the clarification. I only need this if I test things (like Common.css for example) and want to switch back to an older revision that I saved before I started testing. I can still use "edit source" for that. Have a nice day :) Stefahn (talk) 09:00, 27 March 2013 (UTC)

FWIW
The #autoedit function is wonderful! I hadn't used it before, but found a use for it while creating a multiple-instance form with which to create multiple pages. Basically, the audoedit function was embedded in a template, using parser functions such as #if and #var from the Variables extension (the latter for assigning values that are shared by every new page, as opposed to values that are unique to them). Once the page is saved using the form, you can check if the information is correct and if the target pages do not already exist and confirm that the pages can be created. When all is done, you can simply blank or delete the page.

Even if the route, from a form to a page with 'formlinks' to multiple pages, does not look very straightforward, it's a great time-saver when you need to create a whole series of pages.

I wouldn't be me if I didn't have a couple of odd things to point out: Cavila (MW 1.19.2, MySQL 5.1.66, Php 5.3.3-7, SMW 1.8, SF 1.5.2} 16:48, 26 March 2013 (UTC)
 * URLs passed through the #autoedit function end up being rendered incorrectly. I don't recall the exact code, but I think there is some html code added to the URL string.
 * Wiki-style italics are converted to html-style italics. No problem there though.
 * All parameters in the template, even those for which the fields were left empty, are represented in the new pages. Not really an issue either, but it can be inconvenient when there's lots of them. One possible solution here is to press the same button with which the page was created and the empty parameters will be removed.


 * Hi Cavila - could you create one or more bug reports on Bugzilla for these issues? It would be very helpful in getting them fixed. Maybe two would be good - one for the formatting problems, and one for the empty parameters? Yaron Koren (talk) 13:04, 28 March 2013 (UTC)

"Show changes" fails / redirects to normal edit view
Hi Yaron,

I noticed some strange behavior with "Show changes" when editing with a form: Thanks! Stefahn (talk) 14:27, 27 March 2013 (UTC)
 * On two of my wikis if I click the button, there is no diff view but all my changes (in the form) get deleted.
 * On another wiki if I click the button, it takes me to normal edit view (with diff view). Is this the normal behavior? Can you think of something that goes wrong with my two other wikis?


 * What version of MediaWiki and SF are these different wikis running? Yaron Koren (talk) 16:26, 27 March 2013 (UTC)


 * All wikis run MW 1.19.2. The two wikis, on which the preview fails, run SF 2.5.2 alpha - the wiki where it takes me to normal edit view runs SF 2.5. Should I update all SF versions to the latest one? Thanks for your help! Stefahn (talk) 10:16, 28 March 2013 (UTC)


 * Hi - that might be the issue. I would try upgrading one or both of the failing wikis to 2.5.2, and see if that fixes the problem. Yaron Koren (talk) 13:07, 28 March 2013 (UTC)

I found another issue with "show preview". In the main namespace it works fine, but in my custom namespace "Link" the preview fails and says "The page bla.de 1 does not exist". In "edit source" mode the preview works fine. BTW: In the template I use parser functions #if, #explode and #titleparts - maybe that interferes with SF somehow? Thanks. Update: Found out that the preview works when first creating the page, but fails when editing the page... Maybe that helps. Stefahn (talk) 13:03, 1 April 2013 (UTC)
 * Okay, updating / downgrading to 2.5.2 did the trick. Thanks.

Partial form bug in SF 2.5.2
Hi, we recently upgraded to SF 2.5.2 and noticed that when saving partial forms, the entire page would get overwritten with just the partial form content (in our case subobjects). This occurs across several different partial forms. We did not have this problem with the previous version of SF using the same partial forms. Longphile (talk) 02:32, 28 March 2013 (UTC)


 * Ah... there have long been problems with partial forms, but I guess they've gotten worse. I've actually been planning to get rid of partial forms for a while, due to all their problems - maybe this will speed up the process. If it's possible, you should switch to using regular forms, that only happen to include the fields that you want to edit, if that makes sense. Yaron Koren (talk) 14:56, 28 March 2013 (UTC)


 * We removed the partial form tag and switched the forms to regular forms with just the partial fields and it works fine. Longphile (talk) 00:00, 29 March 2013 (UTC)


 * Cool. Yaron Koren (talk) 01:37, 29 March 2013 (UTC)

"Subforms" through templates?
In an older version of SMW (MW 1.15.0 with SF 1.7.3) I'm using a hack based on HTML entities to make my forms more DRY. A dozen or so forms have the same structure so I decided to avoid overlapping and I managed to do this by using HTML entities in a template, e.g. {| class="formtable" ! Geldigheid: }} Unfortunately my hack doesn't work anymore with Semantic Bundle 1.8alpha. Is there another way to do this? I could also turn all the forms into one form but this is probably more work to figure out. Guaka (talk) 15:18, 28 March 2013 (UTC)
 * &amp;#123;&amp;#123;&amp;#123;field&amp;#124;Geldigheid-begin&amp;#124;input type=date&amp;#125;&amp;#125;&amp;#125; t/m &amp;#123;&amp;#123;&amp;#123;field&amp;#124;Geldigheid-einde&amp;#124;input type=date&amp;#125;&amp;#125;&amp;#125;


 * Hi - those just look like regular curly brackets when your comment is displayed, but I know you typed in stuff like "&amp;#123;" instead. Anyway, it's strange that it doesn't work any more. Do the same templates that used to work no longer work, and are you sure that it's due to the escaping thing? And if so, what if you used something like "&lt;nowiki&gt;{{{&lt;/nowiki&gt;field..." instead? That should also work. Yaron Koren (talk) 15:23, 28 March 2013 (UTC)


 * I found out it's because of some JS (and/or CSS) that broke with the upgrade: class="fold-content" style="display:none;". But I'm happy to know about the &lt;nowiki&gt;{{{&lt;/nowiki&gt; trick, might look better than HTML entities. Your "Working with MediaWiki" has been a good read by the way, תודה! Guaka (talk) 10:28, 29 March 2013 (UTC)


 * Bevakasha! Yaron Koren (talk) 02:47, 1 April 2013 (UTC)

Some guidance on different attachment behaviour with Semantic Forms
My semantic forms are working quite well; I can fill in a form (with a map) which creates a page based on my template.

Now I'd like to extend it so users can optionally add one or more files. I can get one file attachment working quite well.

There's two things I'm trying to figure out:

- is there a way for me to override the default upload form? I'd like to override the usual description / licensing / watch this file dialog and use my own semantic properties (author, publication date, etc).

- how can I make a form that ask the user for one attachment, but there's an 'add another' button which expands the form for a new entry?

Hopefully that make sense. And I really appreciate Semantic forms.

Alexthepuffin (talk) 19:50, 30 March 2013 (UTC)


 * Hi - for the first one, if you're talking about using an SF form to create the file page, I'm pretty sure there's no way to do that at the same time that you're uploading the file from within another form. However, you can associate a form with the "File:" namespace, which will make it easier to add that information as soon as the user goes to edit the file page.


 * For the second question, you can either have the "uploadable" field allow multiple values (use #arraymap in the template for that), or have a multiple-instance template for the uploaded files. If that makes sense. Yaron Koren (talk) 02:46, 1 April 2013 (UTC)


 * Okay! I'm on the right track, thanks. I'm really just following the instructions here: http://www.mediawiki.org/wiki/Extension:Semantic_Forms/Manual/Using_Semantic_Forms_for_file_pages_and_uploads#The_one-step_process .  It explains how to add a field to an uploaded file, and I'll use that to include a gallery of files associated with that page.


 * I'm not there yet, but I'll use multi-instance templates to handle multiple files. Thanks. Alexthepuffin (talk) 02:46, 2 April 2013 (UTC)

Problems with passing fields as a query string to FormEdit
I'm having a problem getting a #formlink to pass on a value to preload into a form.

You can see the #formlink I'm using here: http://developingottawa.ca/index.php?title=Fsdf. It looks like this:

It is supposed to pass to the form 'Document form' the value of the page name to the field 'Location'. It calls the URL:

http://developingottawa.ca/index.php?title=Special:FormEdit/Document_form&Document_form%5BLocation%5D=Fsdf

That URL looks correct.

But the form doesn't fill in the field 'Location' at all.

The form includes:

What am I doing wrong? Alexthepuffin (talk) 03:04, 2 April 2013 (UTC)


 * The fact that this wiki is public makes debugging much easier. :) It's because the query string should have the name of the template, not the name of the form - so it should be "Document template[location]". Yaron Koren (talk) 14:47, 2 April 2013 (UTC)
 * AHA! Thanks for debugging this for me. It is what I get for not using the same names for my forms and templates. Alexthepuffin (talk) 21:25, 3 April 2013 (UTC)

'Serialization of 'Closure' is not allowed'
Hi, I am trying to create forms using SemanticForms and it seems that there is a bug or problem with the SemanticForm creation.

If you go to this website: http://semantic-mediawiki.org/wiki/Demo:Event_calendar/Create_events_using_a_form and click the button Create Form.

After you click that button it directs you to: http://semantic-mediawiki.org/wiki/Special:FormEdit/Event_calendar_item?

Error:

Unexpected non-MediaWiki exception encountered, of type "Exception" exception 'Exception' with message 'Serialization of 'Closure' is not allowed' in /srv/semantic-mediawiki_org/www/core/extensions/SemanticForms/includes/SF_FormPrinter.php:440 Stack trace:
 * 1) 0 /srv/semantic-mediawiki_org/www/core/extensions/SemanticForms/includes/SF_FormPrinter.php(440): serialize(Object(Parser))
 * 2) 1 /srv/semantic-mediawiki_org/www/core/extensions/SemanticForms/includes/SF_AutoeditAPI.php(838): SFFormPrinter->formHTML(' / includeonly /doAction
 * 4) 3 /srv/semantic-mediawiki_org/www/core/extensions/SemanticForms/specials/SF_FormEdit.php(90): SFAutoeditAPI->execute
 * 5) 4 /srv/semantic-mediawiki_org/www/core/extensions/SemanticForms/specials/SF_FormEdit.php(46): SFFormEdit::printForm('Event_calendar_...', '', NULL, true)
 * 6) 5 /srv/semantic-mediawiki_org/www/core/includes/SpecialPage.php(613): SFFormEdit->execute('Event_calendar_...')
 * 7) 6 /srv/semantic-mediawiki_org/www/core/includes/SpecialPageFactory.php(499): SpecialPage->run('Event_calendar_...')
 * 8) 7 /srv/semantic-mediawiki_org/www/core/includes/Wiki.php(291): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
 * 9) 8 /srv/semantic-mediawiki_org/www/core/includes/Wiki.php(565): MediaWiki->performRequest
 * 10) 9 /srv/semantic-mediawiki_org/www/core/includes/Wiki.php(458): MediaWiki->main
 * 11) 10 /srv/semantic-mediawiki_org/www/core/index.php(59): MediaWiki->run
 * 12) 11 {main}

I have installed on this wiki and get this error also. It is strange since it happens both on semantic-mediawiki main wiki website. It does not seem to be isolated to my server. Anyone else having this problem. Could someone please help with this. Thanks!


 * Looks like this is discussed on stackoverflow: []. Maybe you can find that in SF_FormPrinter.php, line 440 99.246.162.126 12:42, 2 April 2013 (UTC)


 * Thanks!, Here is the code:

438          $oldParser = $wgParser;

440		$wgParser = unserialize( serialize( $oldParser ) ); // deep clone of parser 441		$wgParser->Options( ParserOptions::newFromUser( $wgUser ) ); 442		$wgParser->Title( $this->mPageTitle ); 443		$wgParser->clearState;

Line 440 gives the error and it says its a deep clone of parser. It is strange that it serializes it and then unserializes it..


 * Yes, I'm aware of the problem. That code is necessary in order to do a deep clone, but it fails with the latest versions of MediaWiki. It's something that I hope will be fixed soon. Yaron Koren (talk) 15:58, 2 April 2013 (UTC)


 * OK Thanks I'm using the newest version of MediaWiki. I'm looking forward to using the Forms when it's fixed.. they look really useful!