Page MenuHomePhabricator

Catchable fatal error: Argument 1 passed to Article::__construct() must be an instance of Title, null given, called in SF_AutoeditAPI.php on line 318
Closed, DuplicatePublic

Description

Author: alj62888

Description:
Semantic Bundle (Version 1.8.0.5)
Semantic Forms (Version 2.5.3)
Semantic Forms Inputs (Version 0.7)
Semantic MediaWiki (Version 1.8.0.5)

Just upgraded to SemanticBundle 1.8.0.5. Can't save a form for a new page at all.


Version: REL1_20-branch
Severity: blocker
OS: Linux

Details

Reference
bz58022

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 2:20 AM
bzimport set Reference to bz58022.

Upgrading to SF 2.6 may or may not help. In any case - does this happen for all forms, or is it something specific to this form? And if it's the latter, could I see the form definition text in one way or another?

alj62888 wrote:

Hi Yaron,

Something strange has occurred while testing this. Using same the form (but with different values), a page got created with the title:

"Some very long page name that will hopefully never get created ABCDEF123"

The above shows on the page and in the browser tab even though the pagename in the URL has the correct page name.

Then, following the above, all of the {{#info}} boxes on the page are such that their text contents are fully expanded out into the page (not hidden in tooltip).

I'm overriding the display title with:
{{DISPLAYTITLE:<span style="display:none; visibility:hidden">❝{{#show:{{PAGENAME}}|?Statement Under Scrutiny}}❞</span>}}

As you can see, it should be hidden on the page but show in the browser tab and also be the result of a query, yet it has been ignored and the wrong title is on the page and in the browser tab.

Maybe this is related since the error for this bug contains a Title error.

To answer your question, another form that is similar doesn't seem to have the same problem but not sure now.

alj62888 wrote:

The "Some very long..." title issue cannot be reproduced and a refresh of the page restored the correct title.

But, it looks like the original catchable fatal error only happens when going through a captcha screen. Not seeing it when I'm logged-in and skipping the captcha.

Catchable fatal error: Argument 1 passed to Article::__construct() must be an instance of Title, null given, called in /usr/local/apache2/htdocs/wiki/extensions/SemanticForms/includes/SF_AutoeditAPI.php on line 318 and defined in /usr/local/apache2/htdocs/wiki/includes/Article.php on line 115

I'm using the reCAPTCHA of ConfirmEdit (Version 1.1).

I may try SF 2.6 if you think it's pretty stable.

alj62888 wrote:

I think I've narrowed something down... new error but still related to the Title or page name.

I upgraded to SF 2.6 and now, instead of getting the "Catchable fatal error", and when going through the captcha page, I get returned to the same form with a red-text error message near the top that says:

"The specified target page _ is invalid."

and all field values for the form have been reset.

Now, in the form I do the "one-step process" and set the page name myself with the SF markup:

{{#nextpagename}} is a parser function that returns a page name. This works fine after the initial submit but after the final "submit" from the captcha screen, the name argument that gets passed to nextpagename is null and so it returns an empty string. This worked before the upgrade with the same captcha setup.

  • So, <SusForm[Statement Under Scrutiny]> evaluates to null when submitting from a captcha screen.

Ah, it's a CAPTCHA thing. (By the way, reCAPTCHA doesn't work that well any more - you might have better luck with QuestyCaptcha. Although maybe for you it's working fine.)

Where is #nextpagename defined? I've never heard of it. And are you saying that, when you used #nextpagename in that way with SF 2.5.3, none of the problems you're describing happened?

alj62888 wrote:

Thanks for tips. I don't suspect the captcha is the cause here, but I'll try another one to see.

#nextpagename is just my own parser function to basically truncate the string passed-in to a legal size and then add an increment digit if needed. I mainly need it for the truncation part since using the following didn't work:

{{{info |page name={{#sub:<SusForm[Statement Under Scrutiny]>|0|56}}}}}

If I had a way to truncate the value returned from <SusForm[Statement Under Scrutiny]> I would surely use it.

alj62888 wrote:

I just tried it with QuestyCaptcha and got the same result descirbed in Comment 4 above.

If you have any suggestions on what to look at, I try to debug.

alj62888 wrote:

Update

I've tracked it down to this line in SF_FormPrinter.php (around line 595):

$template_instance_query_values = $wgRequest->getArray( $query_template_name );

On the first submit, it returns the value for the template field <SusForm[Statement Under Scrutiny]>. But, on the second submit from the captcha page, it returns null.

Printing the array contents of WebRequest.data at both points show the template field and its value present both times, but on the second time it contains other captcha info so I don't know if the field is wrapped in another array or what and now it's starting to get complicated for my skill level.

I hope this info helps so perhaps I can get a patch or else I'll have to fall all the way back to SemanticBundle 1.8alpha.

Thanks,
Al

alj62888 wrote:

Entering a separate bug for the comment #2 issue with "Some very long page name that will hopefully never get created ABCDEF123" since it still happens even after disabling the captcha so seems unrelated.

Al Johnson: Does this problem still happen in a supported MediaWiki version (1.19, 1.22, 1.23 currently)?

alj62888 wrote:

I only know about 1.20.2.

eoord wrote:

Hi guys,

I found this bug too. It appears to be caused by an error in the <info|page name=...> tag. If you misspell the template name in that tag (in other words, when the template name in the tags no longer corresponds to a template name used in the form body), the bug appears. For example:

{{{info|page name=<ThisTemplate[MyField]>}}}
.
.
.
{{{for template|OtherTemplate}}}
.
.
.

Obiously, SF can't solve misspellings, but it would be nice if it returns a user friendly message.

alj62888 wrote:

A misspelled template would not be the only cause since that would permanently break the form for whatever SMW version and the issue only appeared with known working forms after an upgrade.

Krinkle subscribed.

Fixed by 97a337d3242cdefce917285021eed88aea6a56a5.