Page MenuHomePhabricator

[SF] Special:RunQuery error takes down pages using it
Closed, ResolvedPublic

Description

I was adding fields to my Special:RunQuery form when its template suddenly stopped giving me #ask query results. I then added another identical #ask query as a test case to the template, and it took down the wiki pages that show the form, and failed with this lengthy error:

Internal error

Bad parser output text.

Backtrace:

#0 [internal function]: ParserOutput->replaceEditSectionLinksCallback(Array)
#1 /path/to/includes/parser/ParserOutput.php(160): preg_replace_callback('#<(?:mw:)?edits...', Array, '<p><br />?</p>?...')
#2 /path/to/extensions/SemanticForms/includes/SF_FormUtils.php(894): ParserOutput->getText()
#3 /path/to/extensions/SemanticForms/includes/SF_FormPrinter.php(418): SFFormUtils::getFormDefinition(Object(Parser), '<noinclude>?Thi...', 1975)
#4 /path/to/extensions/SemanticForms/specials/SF_RunQuery.php(81): SFFormPrinter->formHTML('<noinclude>?Thi...', true, false, 1975, NULL, NULL, NULL, true, false)
#5 /path/to/extensions/SemanticForms/specials/SF_RunQuery.php(31): SFRunQuery->printPage('Specimen_find', false)
#6 /path/to/includes/SpecialPageFactory.php(458): SFRunQuery->execute('Specimen_find')
#7 /path/to/includes/Wiki.php(226): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
#8 /path/to/includes/Wiki.php(626): MediaWiki->performRequest()
#9 /path/to/includes/Wiki.php(533): MediaWiki->main()
#10 /path/to/index.php(57): MediaWiki->run()
#11 {main}

That same error message is also produced by:

/path/to/extensions/SemanticMediaWiki/maintenance$ php SMW_refreshData.php -v

On a page with the RunQuery form embedded, this error was produced:

MediaWiki internal error.

Original exception: exception 'MWException' with message 'Bad parser output text.' in /path/to/includes/parser/ParserOutput.php:180
Stack trace:
#0 [internal function]: ParserOutput->replaceEditSectionLinksCallback(Array)
#1 /path/to/includes/parser/ParserOutput.php(160): preg_replace_callback('#<(?:mw:)?edits...', Array, '<p><br />?</p>?...')
#2 /path/to/extensions/SemanticForms/includes/SF_FormUtils.php(894): ParserOutput->getText()
#3 /path/to/extensions/SemanticForms/includes/SF_FormPrinter.php(418): SFFormUtils::getFormDefinition(Object(Parser), '<noinclude>?Thi...', 1975)
#4 /path/to/extensions/SemanticForms/specials/SF_RunQuery.php(81): SFFormPrinter->formHTML('<noinclude>?Thi...', false, true, 1975, NULL, NULL, NULL, true, true)
#5 /path/to/extensions/SemanticForms/specials/SF_RunQuery.php(31): SFRunQuery->printPage('Specimen_find', true)
#6 /path/to/includes/SpecialPageFactory.php(458): SFRunQuery->execute('Specimen_find')
#7 /path/to/includes/SpecialPageFactory.php(492): SpecialPageFactory::executePath(Object(Title), Object(RequestContext), true)
#8 /path/to/includes/parser/Parser.php(3129): SpecialPageFactory::capturePath(Object(Title))
#9 /path/to/includes/parser/Preprocessor_DOM.php(1044): Parser->braceSubstitution(Array, Object(PPFrame_DOM))
#10 /path/to/includes/parser/Parser.php(2861): PPFrame_DOM->expand(Object(PPNode_DOM), 0)
#11 /path/to/includes/parser/Parser.php(1033): Parser->replaceVariables('<div style="flo...')
#12 /path/to/includes/parser/Parser.php(340): Parser->internalParse('<div style="flo...')
#13 /path/to/includes/Article.php(1837): Parser->parse('<div style="flo...', Object(Title), Object(ParserOptions), true, true, 14680)
#14 /path/to/includes/Article.php(1759): Article->getOutputFromWikitext('<div style="flo...', false, Object(ParserOptions))
#15 /path/to/includes/Article.php(1012): Article->outputWikiText('<div style="flo...', false, Object(ParserOptions))
#16 /path/to/includes/Article.php(2002): Article->doViewParse()
#17 /path/to/includes/PoolCounter.php(183): PoolWorkArticleView->doWork()
#18 /path/to/includes/Article.php(547): PoolCounterWork->execute()
#19 /path/to/includes/Wiki.php(470): Article->view()
#20 /path/to/includes/Wiki.php(241): MediaWiki->performAction(Object(Article))
#21 /path/to/includes/Wiki.php(626): MediaWiki->performRequest()
#22 /path/to/includes/Wiki.php(533): MediaWiki->main()
#23 /path/to/index.php(57): MediaWiki->run()
#24 {main}

Exception caught inside exception handler: exception 'MWException' with message 'FauxRequest::getRequestURL() not implemented' in /path/to/includes/WebRequest.php:1106
Stack trace:
#0 /path/to/includes/WebRequest.php(1135): FauxRequest->notImplemented('FauxRequest::ge...')
#1 /path/to/includes/SkinTemplate.php(1033): FauxRequest->getRequestURL()
#2 /path/to/includes/SkinTemplate.php(498): SkinTemplate->buildContentNavigationUrls(Object(OutputPage))
#3 /path/to/includes/OutputPage.php(1856): SkinTemplate->outputPage(Object(OutputPage))
#4 /path/to/includes/Exception.php(183): OutputPage->output()
#5 /path/to/includes/Exception.php(209): MWException->reportHTML()
#6 /path/to/includes/Exception.php(392): MWException->report()
#7 /path/to/includes/Exception.php(471): MWExceptionHandler::report(Object(MWException))
#8 /path/to/includes/Wiki.php(536): MWExceptionHandler::handle(Object(MWException))
#9 /path/to/index.php(57): MediaWiki->run()
#10 {main}

  1. Blanking the form always alleviates the error condition.
  2. Restoring the form causes the error condition to return.
  3. Deleting the form lines 27 through 56 inclusive alleviates the error condition, but #ask queries still do not work.
  4. Restoring the form lines 27 through 56 inclusive does not cause the error condition to return, but #ask queries still do not work.

Form lines 27 through 56 look like this:

- class="mw-collapsible mw-collapsed" id="mw-customcollapsible-findHelp"

! style="text-align:left; font-weight:normal;" colspan="2" | <nowiki />
Everything below is optional, you may leave it blank if you choose. The information entered below will be preloaded for you when the search results allow you to enter in specimens that were not found. It will only work if ALL the certification numbers you enter above are identical for all of the below information. So, if you enter any of the below information, it must be correct for each certification number you entered above, or you will have to change it manually on the Specimen form. Only enter one bit of information for each field, except the '''Designation''' field, where more than one is allowed.

- class="mw-collapsible mw-collapsed" id="mw-customcollapsible-findHelp"

! Type:

{{{fieldTypesize=10values from property=Type }}}
- class="mw-collapsible mw-collapsed" id="mw-customcollapsible-findHelp"

! Certified by:

{{{fieldCertified byinput type=comboboxsize=30values from property=Certified by }}}
- class="mw-collapsible mw-collapsed" id="mw-customcollapsible-findHelp"

! Grade:

{{{fieldGradeinput type=comboboxsize=10values from property=Grade }}}
- class="mw-collapsible mw-collapsed" id="mw-customcollapsible-findHelp"

! Designation:

{{{fieldDesignationvalues from property=Designation}}}

Separate multiple entries with a comma.<br />
Examples:<br />
'''Proof, Ultra Cameo'''<br />
'''Proof, Ultra Cameo, Star'''<br />
'''Proof, Cameo'''<br />
'''Proof'''<br />
'''Proof, Deep Cameo'''<br />
'''Proof-Like'''<br />
'''Deep Mirror Proof-Like'''<br />

- class="mw-collapsible mw-collapsed" id="mw-customcollapsible-findHelp"

! Conserved by:

{{{fieldConserved byinput type=comboboxvalues from property=Conserved by }}}
- class="mw-collapsible mw-collapsed" id="mw-customcollapsible-findHelp"

! Problem:

{{{fieldSpecimen probleminput type=comboboxvalues from property=Specimen problem }}}

I have not been able to figure out what exactly causes the error condition to appear, and I think it may not be directly related to anything the user (me) is doing. But, hopefully figuring out what causes it to alleviate will be sufficient for finding the cause in the code, and fixing the bug. I still don't know why #ask queries stopped working.

Still, the same situation repeated often enough that I don't think data entry is a factor. The error condition occurred even when just going to the Special:RunQuery form page, before any data was entered (I'm not 100% sure of that, since I can't get the error to repeat on command). In all tested queries, I only used the first field, while others were left blank (if present). Some queries I used were these:

http://www.coincompendium.com/w/index.php/Special:RunQuery/Specimen_find?Specimen_find%5BCertification%20number%5D=3495072-005&Specimen_find%5BType%5D=&wpRunQuery=true

http://www.coincompendium.com/w/index.php/Special:RunQuery/Specimen_find?Specimen_find%5BCertification%20number%5D=3495072-005,%202764410-002,%2016201810,%202765633-012,%202312213-013&Specimen_find%5BType%5D=&wpRunQuery=true

Since the first line of the errors seems to be related to the section edit links, I suspect this bug is actually a problem with magic words, since I have the magic word NOEDITSECTION in my template, and it does not function, as reported in this bug:

https://bugzilla.wikimedia.org/show_bug.cgi?id=33418


Version: unspecified
Severity: critical

Details

Reference
bz33424

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 12:01 AM
bzimport set Reference to bz33424.

Is there any way you can isolate this down further, to, say, a line or two whose presence or absence makes a difference?

I'll keep working on it. Since I don't know how to reliably trigger the bug, it's hard for me to experiment with it. I'll post more specific info as soon as I can get this bug to give it up to me.

It appears I have a conflicting hotkey setup with my clipboard manager that was sometimes causing me to paste forms into templates, much like in this bug report:

https://bugzilla.wikimedia.org/show_bug.cgi?id=33203

Now that I generally know what is triggering the bug, I can work to narrow them down in both that bug report and this one, so they can be validated in the Semantic Forms code.

Even though it was an embarrassing minor error on my part that caused the problems in both bug reports, since it takes down the pages where the error occurs (or the whole site in the case of bug 33203) it still needs to be fixed once it's isolated, to prevent the bugs from being exploited maliciously.

I've got to switch tasks for a while, but I'll come back and keep working on these two bugs until I find out exactly what triggers them, so that code path can be rejected.

Created attachment 9782
bug trigger

I got it! This exact text will trigger the bug when used in a Special:RunQuery form. I could not remove any more characters without the error going away, including the newlines. It seems to be some bizarre interaction between the MediaWiki parser, Semantic Forms RunQuery, and #formlink.

attachment cc demo bug 33203 SF RunQuery .txt ignored as obsolete

Created attachment 9783
correct bug trigger

looks like I accidentally uploaded the wrong file. This should be the correct one.

attachment cc demo bug 33203 SF RunQuery .txt ignored as obsolete

Dammit. I think I found a file upload bug in my browser. Bugs love me :(

I'll get you the correct text when I switch browsers.

Created attachment 9784
bug trigger 3

Hopefully this one uploads correctly.

Attached:

Were you able to reproduce this? I'm getting this error in another circumstance, that I'm currently working on isolating. So far, it does not appear to involve the trigger in attachment 9784.

No, I couldn't reproduce the problem. (By the way, you don't need to create an attachment for a single line.)

It's not a single line, it's exactly 3 lines (plus maybe an EOF or something). Try reproducing it with the full text, including line breaks.

Still nothing. Could you reproduce this on scratchpad.referata.com?

It didn't reproduce when I tried it on scratchpad.referata.com, so there's something more complex going on that needs to be narrowed down further. It might turn out that this bug is rare enough to be ignored for now, if I eventually discover that it's some unusual combination of extensions, settings, etc - we could just add it to a known bugs list, and call it good, if I find an easy fix.

I'll keep working on it. I'm starting with a fresh test wiki to see if I can break it.

I was able to reproduce this on the first try with a fresh install of MW 1.18, SMW 1.7, and SF 2.3.2 at a completely different host, under a different OS (linux and solaris):

http://www.coincompendium.net/w2/index.php?title=Special:RunQuery/Bug_33424

Here's the form:

http://www.coincompendium.net/w2/index.php?title=Form:Bug_33424

So, there's nothing unusual about my install as far as I can tell. The bug seems to be reproduceable right out of the box. If you need more info, let me know. I can repeat the process on your own system if you want, so you can better observe what is happening.

For your convenience, here's my Special:Version at the test system I set up just for this bug:

http://www.coincompendium.net/w2/index.php?title=Special:Version

I'm going to get to work on the other bugs that seem to be related. One of them is causing all pages that point with a property to newly created pages to refuse to display. I haven't narrowed that one down to SF versus SMW yet though, but I'm able to get similar errors when I view a diff of the change history. Here's an example (login with Demo/test):

http://www.coincompendium.com/w/index.php?title=CC336&action=historysubmit&diff=15590&oldid=15589

If I remove the "Type" property, or change it to an older page, the problem resolves and I can view the CC336 page again:

http://www.coincompendium.com/w/index.php?title=CC336&action=edit

Here's the test on referata:

http://scratchpad.referata.com/wiki/Special:RunQuery/Bug_33424
http://scratchpad.referata.com/wiki/Form:Bug_33424

I don't know why it doesn't trigger the bug on referata. It seems to be heavily customized, even the Special:Version page is different from what I'm used to, so I wasn't able to come up with a guess about why the bug won't trigger at referata. I'm curious to know your thoughts, if you have any about that.

Let me know if need me to do anything else for this.

I have some more information. Every time I edit a page with Semantic Forms, the same "Bad parser output text" error appears, and the page refuses to load. Look at this example (login with Demo/test):

http://www.coincompendium.com/w/index.php?title=File:Vulture.jpg&action=history

I edited that today, January 9th, and now it won't load. But, you can still view the previous version from December 11th, no problem. If you try to view the diff, that's when you get the "Bad parser output text" and backtrace error:

http://www.coincompendium.com/w/index.php?title=File%3AVulture.jpg&action=historysubmit&diff=16655&oldid=13809

Any ideas what might cause that behavior, and how I can troubleshoot this further? There are other reported instances of this similar error occuring, besides this bug 33424, but I'm having trouble figuring out what they have in common other than they all occur after an edit:

http://wikimedia.7.n6.nabble.com/Bug-after-upgrading-to-SMW-1-7-td3154555.html

https://bugzilla.wikimedia.org/show_bug.cgi?id=33203

I'm not sure if they're related though. Any ideas?

I don't know - I'm not seeing errors on any of these links.

That's very odd. I undid the revision that made the file inaccessible, under the assumption that the older broken revisions would still be broken. Somehow the most recent revision is affecting older revisions. I undid the undo, and the errors have returned.

Still, disabling Semantic Forms alleviates the error condition, but I'm starting to wonder if there's something deeper going on within MediaWiki that is interacting with Semantic Forms to produce the error.

Unfortunately, I can confirm the "Bad parser output text"/backtrace error, which occurs with some but all of my forms. I'll let you know as soon as I'm able to isolate the line which triggers the error.

Correction: NOT all of my forms

Both the template and the form are too complex to allow for any easy inspection. As in Badon's case above, the first line under "Backtrace" reads:

[...]includes/parser/ParserOutput.php(160): ParserOutput->replaceEditSectionLinksCallback(Array)

(Removing NOEDITSECTION does not solve anything I'm afraid)

I was able to trigger the bug reliably with attachment 9784 in comment 7. With that, no template is needed, since you just plop it into a page in the "Form" namespace, and then load it with Special:RunQuery/Form:Your_form_Name

There could be multiple triggers for the same bug - I'm not sure. Either way, similar error messages seem to be fairly common with the Semantic Forms 2.3.2 and MediaWiki 1.18 combination I've been testing. Referata uses different versions, and I was not able to trigger the bug on it.

I'm not sure how the backtrace info is supposed to be read, but I think it's supposed to be read in reverse order. Beyond that, or how to make use of it, I don't know. The only reason I blame this bug on Semantic Forms is because the errors alleviate when I disable Semantic Forms. However, it could be some strange interaction between particular versions of SF, SMW, and/or MW.

That's the limit of what my bug testing skills can tell me since I'm not familiar enough with the code to guide me towards better guesses, or further tests. Of course a fix is beyond my capability too, for now.

Oh, per comment 17 I thought this was about Semantic Forms in general, regardless whether one is using query forms through the special page or regular editing forms. In my case, with MW 1.18 and the latest versions of SMW/SF/etc. instslled, the bug renders at least one of my editing forms useless.

I see that SIO is misbehaving as well, so that seems to require a closer look.

OK, I think Badon's report and mine basically come down to the following:

Since SF 2.3.2 (MW 1.18?) semantic forms - whether editing forms or query forms - refuse to load when they contain section headers.

Badon, could you - by way of testing - eliminate all section headers and see if the form loads for you. If so, I would suggest renaming this bug report to something like "Section headers prevent semantic form from loading" (or else, start a new one and link back to the current report).

So far I've only isolated the bug on a Special:RunQuery form. The other
problems with SF could be the same bug triggered in different ways, or they
could be entirely different bugs. We need to do more testing to figure that
out, if Yaron hasn't figured it out already.

If I had more familiarity with the inner workings of SF, I'd probably be much
more effective at testing for bugs and isolating them when found, since I would
know what the code is doing, and how to poke it to get it to misbehave.

For example, I don't know exactly what makes a Special:RunQuery form different
from any other form. If there is no difference, then I'd come up with a way to
try my bug trigger on regular forms and see what happens. If they're different,
I might have a guess about how to trigger it on different forms.

I've got a lot of studying to do, I suppose. Eventually I'd like to be able to
fix these bugs instead of just reporting them. I'm not familiar enough with PHP
yet to do that, so I need to find a few months of dedicated time for study and
practice to get up to speed. I'm not sure when or if that will happen.

In the meantime I need to improve my bug testing methodology. I have experimented with keeping a record of each test and the result, in the order they occur. Once I've got a good habit-system of doing that, I'll be able to tell you right away what I did and didn't do. I'm not sure if I've tested section headers yet or not - I'm pretty sure I did, which is how I found my bug trigger - but I'll have to do it again to test your hypothesis.

I think I'll have time to focus today on more tests of Semantic Forms. I'll report my results. I need to study the issues Ryan Lane was having, since I think he found a couple of bugs I had encountered, but haven't isolated yet.

By the way, I couldn't reproduce it on Referata either. The exact same form that you can see on the following page does not load for me on my (private) website, but it loads without any trouble on Scratchpad:

http://scratchpad.referata.com/wiki/Form:Cav

Any guesses about what's different between standard installations and Referata?

Apart from the difference between the official versions and the latest revisions in SNV or SVN (I forget which), I really don't know.

I'd like to try SF 2.4-alpha and maybe other revisions just to check whether by any chance the issue has not already been dealt with, e.g. without us knowing that the present bug was related to an older one. But I can't download the files except by going through the list one by one, which is obviously a very tedious and time-consuming process.

You just reminded me. I recorded a bug in SF 2.2.1 that may be related. When saving SF 2.2.1 forms, I would get these error messages:

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/specials/SF_FormEdit.php on line 312

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/specials/SF_FormEdit.php on line 312

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/specials/SF_FormEdit.php on line 320

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/specials/SF_FormEdit.php on line 320

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 897

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 898

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 901

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 904

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 907

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 910

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 913

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 914

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 917

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 920

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 923

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 926

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 929

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 930

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 933

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 936

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 937

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 938

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 939

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 940

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 941

Notice: Object of class Status could not be converted to int in /path/to/extensions/SemanticForms/includes/SF_Utils.php on line 942

Warning: Cannot modify header information - headers already sent by (output started at /path/to/extensions/SemanticForms/includes/SF_Utils.php:939) in /path/to/includes/WebResponse.php on line 38

Warning: Cannot modify header information - headers already sent by (output started at /path/to/extensions/SemanticForms/includes/SF_Utils.php:939) in /path/to/includes/WebResponse.php on line 38

Warning: Cannot modify header information - headers already sent by (output started at /path/to/extensions/SemanticForms/includes/SF_Utils.php:939) in /path/to/includes/WebResponse.php on line 38

Warning: Cannot modify header information - headers already sent by (output started at /path/to/extensions/SemanticForms/includes/SF_Utils.php:939) in /path/to/includes/WebResponse.php on line 38

Warning: Cannot modify header information - headers already sent by (output started at /path/to/extensions/SemanticForms/includes/SF_Utils.php:939) in /path/to/includes/WebResponse.php on line 38

Warning: Cannot modify header information - headers already sent by (output started at /path/to/extensions/SemanticForms/includes/SF_Utils.php:939) in /path/to/includes/WebResponse.php on line 38

Then, after those error messages displayed, I would get this as the sole page content, in red:

&lt;internalerror_text&gt;

I searched for that text in the code to see what was producing it, but I've forgotten what I found. If I remember correctly, it was just an end point for the code execution, so I would need to work backward from there to find the trouble spot, and without familiarity with the code, I would not know what I am looking for.

Well, I don't see any clear parallels with the current situation, but then I'm not the 'tech guy'. What I do know is that the form loads again once I've removed "==More information==" from it (http://scratchpad.referata.com/wiki/Form:Cav). The h1 headers used for Header tabs, on the other hand, seem to be fine.

Any word from Yaron? Or are you still as much in the dark as we are?

contrafibularity - so literally any form that contains a section header leads to an error, when using either Special:FormEdit or Special:RunQuery? Even a very simple form? And does it happen with both '=header=' and '==header=='?

And what version of PHP are you using?

PHP 5.2.17 (cgi-fcgi) with MySQL 5.1.58. I did a few more tests to see if section headers were the sole culprits or whether it was some combination with other forms of wiki syntax which triggered the bug.

The latter now appears to be the case. The page loads again if either all references (<ref>...</ref>) and reference lists (<reference />) or all section heades (at least h2 and h3, not yet sure about h1) are removed. Or both of course.

Badon, can you confirm this behaviour on your wiki, or is it something else entirely?

Hm - it might be due to the PHP 5.2. You're both using that, whereas Referata uses 5.3. That's my only guess at the moment.

My test wikis use PHP 5.3 (login with Demo/test):

http://www.coincompendium.net/w/index.php?title=Special:Version
http://www.coincompendium.net/w2/index.php?title=Special:Version

My "production" wiki uses PHP 5.2 (login with Demo/test:

http://www.coincompendium.com/w/index.php/Special:Version

Has anyone else confirmed attachment 9784 as a bug trigger? I was able to reproduce it on each of those three systems, as mentioned in comment 14. The "w2" system is a completely fresh install, on a different OS, with different versions of Apache and MySQL, too.

I have had to put bug testing on the back burner unexpectedly. I'm not sure when I'll get the time to do more tests. contrafibularity, you are welcome to try reproducing your line of testing on my "w2" fresh install:

http://www.coincompendium.net/w2/index.php

Some interesting info I think I forgot to mention here:

http://china-mint.info/forum/index.php?topic=4588.msg27393#msg27393

In short, it appears one part of the problem occurs only with recently created pages that are linked via SMW properties to another recently created page. Pages that were created before the upgrade to SF 2.3.2 (and/or SMW 1.7, MW 1.18) do not produce errors, it seems.

Is there anything more I should be doing with this bug? I don't think anyone has explicitly confirmed that they're able to reproduce my bug trigger in attachment 9784. I'm not sure if spending more time on testing for this bug will be helpful or not, or if there's still not enough info about it to fix it.

I assume it's on Yaron's to-do list. So, I'll wait to put more time into it until Yaron says he needs more info. It seems we've found a few different circumstances where very similar errors are produced, and I think they're all probably the same bug. If not, contrafibularity and I will have to dig deeper to separate them out.

The trigger you sent us is "===", i.e. one part of the h3-level section header. I assumed that's what we were talking about, right?

I couldn't reproduce the issue on your test wiki, for which the PHP version is 5.3. Could you copy the two pages (Form:Cav and Template:Cav) to your production wiki and see if the trouble occurs there?

No, that's not right. There are 3 lines in the trigger text, and the first one is blank with just a newline. You need to copy the text directly from the file, exactly as it is, or the bug won't trigger.

Also, if I remember correctly, spaces were allowed in the "===" part, and it would still trigger. You can try it with something like "== =" instead of "===", and I think the trigger will still work.

Once you're able to reproduce my trigger, I can look over your code. I suspect it may actually be equivalent to mine.

Yes, if I place that line in the form (under <div id="wikiPreview" .... </div> {{{for template|<name of template>}}}, an error message is shown. I wonder though if "#formlink" is at all allowed at this point in the form.

Yes, #formlink is allowed. Other than in this bug situation, #formlink works very well, with few bugs found for it. I will have a look at your code to see if I can glean any new information from it.

solbrig.harold wrote:

Changing line 911 on SF_FormEdit.php to read:

$saveResultCode = $editor->internalAttemptSave( $resultDetails )->value;

Appears to fix the problem. Apparently the return class of the editor write functions were changed to "class Status" in a recent MediaWiki release. Note that this fix is probably not backwards compatible...

I took a look at my Semantic Forms 2.3.2 /specials/SF_FormEdit.php and I only see 390 lines. What version of the file should I look at?

I haven't counted the lines (who would want to do so anway?), but whatever the exact line number (91?), this bit only occurs in older versions of the file (at least SF 2.2.1):

$saveResultCode = $editor->internalAttemptSave( $resultDetails );

No such thing is present in SF 2.3.2. Are you sure, Harold, that you posted in the right place?

solbrig.harold wrote:

Whoops - sorry about the line number. Must have been thinking about emergencies or some such thing. It should have read "311". In any case, yes - it is the line above. The return type of internalAttemptSave used to be an integer, but it got changed into a class named "Status".

I just checked out 2.4-alpha from SVN and it appears that the issue has been corrected (correctly). If you look for "internalAttemptSave" in SF_FormEdit.php, you will note that the following lines have been added:

// Return value was made an object in MW 1.19
if ( is_object( $saveResult ) )

$saveResultCode = $saveResult->value;

} else {

$saveResultCode = $saveResult;

}

Apparently the return value was made into an object a bit earlier, as I'm running 1.18. Again, if you're getting the "Object of class Status..." message pasted earlier in this thread, the fix above or, if you're just trying to get a local wiki running:
change: $saveResult = $editor->internalAttemptSave( $resultDetails );
to: $saveResult = $editor->internalAttemptSave( $resultDetails )->value;

Harold - that correction has been in SF since September, i.e. since version 2.3, so I don't know if that's the issue here.

I just checked my 2.3.2 and I find this, beginning on line 321:

Try to save the page!
$resultDetails = array();
$saveResult = $editor->internalAttemptSave( $resultDetails );
Return value was made an object in MW 1.19
if ( is_object( $saveResult ) ) {
$saveResultCode = $saveResult->value;
} else {
$saveResultCode = $saveResult;
}

Harold's line of code from comment 43 is on line 323 of Semantic Forms 2.3.2 /specials/SF_FormEdit.php

This is on line 323:

$saveResult = $editor->internalAttemptSave( $resultDetails );

and I ran a test by changing it according comment 44, to:

$saveResult = $editor->internalAttemptSave( $resultDetails )->value;

But I noticed no change. Harold, are you using a version of Semantic Forms that is older than 2.3.2? I need to figure out how to get into things with SVN, so I can test 2.4 alpha.

One thing I did notice is that the backtrace error described in comment 17 occurs instantly (login with Demo/test):

http://www.coincompendium.com/w/index.php?title=File%3AVulture.jpg&action=historysubmit&diff=16655&oldid=13809

While other pages that were recently created or edited with Semantic Forms will time out without loading or showing any error. I'm not sure if that difference is a useful clue or not.

(In reply to comment #27)

By the way, I couldn't reproduce it on Referata either. The exact same form
that you can see on the following page does not load for me on my (private)
website, but it loads without any trouble on Scratchpad:

http://scratchpad.referata.com/wiki/Form:Cav

I just tested that form on my wiki, and it loads for me (login with Demo/test):

http://www.coincompendium.com/w/index.php/Form:Bug_33424_Cav

Do you have a link where I can examine the issue you're having?

I just tested Semantic Forms 2.4, and the crashed pages problem seems to be resolved as of r110786, for pages that are not on Special:RunQuery. However, the trigger posted in comment 7 still causes an error condition, as demo'd in comment 14 (login with Demo/test to see the demo):

(In reply to comment #14)

I was able to reproduce this on the first try with a fresh install of MW 1.18,
SMW 1.7, and SF 2.3.2 at a completely different host, under a different OS
(linux and solaris):

http://www.coincompendium.net/w2/index.php?title=Special:RunQuery/Bug_33424

Here's the form:

http://www.coincompendium.net/w2/index.php?title=Form:Bug_33424

So, there's nothing unusual about my install as far as I can tell. The bug
seems to be reproduceable right out of the box. If you need more info, let me
know. I can repeat the process on your own system if you want, so you can
better observe what is happening.

Note that I also tested SF 2.4 with Semantic MediaWiki 1.7.0.2.

Whoops, I just realized those links are to the .net test server. I just ran the test again on the .com, and the bug seems to be fixed as of r110786. Thanks to the Semantic Forms team!

For a demo of my test, see here (login with Demo/test):

http://www.coincompendium.com/w/index.php?title=Special:RunQuery/Bug_33424

http://www.coincompendium.com/w/index.php?title=Form:Bug_33424

I can confirm that this particular issue has been fixed in the SF 2.4!

Unfortunately, a new problem arose.

Fatal error: Call to undefined method SFParserFunctions::loadScriptsForPopupForm() in [...]/extensions/SemanticForms/includes/SF_ParserFunctions.php on line 222

but that's for another bug report.

keep me updated when you make your bug report. I may want to try to confirm the bug, or help you pin it down, if I can. I haven't seen that issue yet myself.