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


Incorrect title being displayed for http://wiki.planetkubb.com/wiki/Event:Des_Moines_Fall_Kubb_Klassic_2013

I'm using f814d9e7e61e12cd171f05ff86fd984d765ff774 of Semantic Forms and had a user send me the following screenshot showing a page with incorrect title of "Some very long page name that will hopefully never get created ABCDEF123" being displayed. I had a 2nd user report that they saw the same thing. Hitting "edit with form" and resaving the page returns it to the correct title. A quick grep shows that this string is in SF_FormLinker.php.

Version: master
Severity: normal


bzimport set Reference to bz51479.
thingles created this task.Via LegacyJul 16 2013, 9:51 PM
Yaron_Koren added a comment.Via ConduitJul 16 2013, 10:00 PM

Are you sure that's not the right page name? LOL How was the page created?

thingles added a comment.Via ConduitJul 16 2013, 10:06 PM


That page itself has existed without edit since 2/12/2013 (http://wiki.planetkubb.com/w/index.php?title=Event:Des_Moines_Fall_Kubb_Klassic_2013&action=history) and it was edited today using Edit with Form and on save had that title.

bzimport added a comment.Via ConduitSep 19 2013, 7:09 AM

yvdbogert wrote:

(In reply to comment #1)

Are you sure that's not the right page name? LOL How was the page created?

This pagename has been generated by a function called createLinkedPage(), located in: semanticbundle/SemanticForms/includes/SF_FormLinker.php.

bzimport added a comment.Via ConduitSep 20 2013, 9:30 AM

yvdbogert wrote:

We've been able to do this on the scratchpad wiki:

First create a 'new' page with the following text:
[[Houses on 70th ave::foobar]]

View the page and the title will be 'Some very long page name that will hopefully never get created ABCDEF123'. If you refresh the page the title will be displayed correctly.

This also seems to be a fatal error with Approved Revs, it will end in a endless loop if you approve the page that created the other page. We even seen a couple of Apache crashes on this.

Rcdeboer added a comment.Via ConduitSep 20 2013, 1:20 PM

This seems to be related to the parser object. I found what I believe to be the cause of this behaviour. In SF_FormPrinter, several lines have been commented out:

(approx l.440)
// $oldParser = $wgParser;

$wgParser = unserialize( serialize( $oldParser ) ); deep clone of parser
// $wgParser->clearState();

(approx l. 1620)
// $wgParser = $oldParser;

With these lines enabled, the "Some very long..." title is no longer displayed.

However, this does not fix the problematic interaction with ApprovedRevs that Youri reported, although it is no longer fatal. Approving a page with a red link that creates another page now results in the error "Database serialization may cause problems, since the connection is not restored on wakeup." with the following stack trace:


#0 [internal function]: DatabaseBase->sleep()
#1 XXX/extensions/SemanticForms/includes/SF_FormPrinter.php(442): serialize(Object(Parser))
#2 [internal function]: SFFormPrinter->formHTML('XXX...', false, false, NULL, NULL, 'Some very long ...', NULL)
#3 XXX/includes/StubObject.php(58): call_user_func_array(Array, Array)
#4 XXX/includes/StubObject.php(77): StubObject->_call('formHTML', Array)
#5 XXX/extensions/SemanticForms/includes/SF_FormLinker.php(169): StubObject->
call('formHTML', Array)
#6 XXX/extensions/SemanticForms/includes/SF_FormLinker.php(169): StubObject->formHTML('XXX...', false, false, NULL, NULL, 'Some very long ...', NULL)
#7 XXX/extensions/SemanticForms/includes/SF_FormLinker.php(288): SFFormLinker::createLinkedPage(Object(Title), Array)
#8 [internal function]: SFFormLinker::setBrokenLink(Object(DummyLinker), Object(Title), Array, 'XXX...', Array, NULL)
#9 ...

Does anyone know why the parser-related lines had been commented out in the first place? Does it have anything to do with the ApprovedRevs error I just observed? Obviously, commenting out these lines is not a proper solution since it results in other problems and even fatal errors/endless loops, so I suggest re-enabling them and fixing the underlying issue. Any ideas?

Yaron_Koren added a comment.Via ConduitSep 20 2013, 3:09 PM

This bug report might be covering two or even more bugs at this point - I just cc'ed f.trott, who is in charge of the whole tricky parser copy/serialize/unserialize code. Any thoughts on this?

Rcdeboer added a comment.Via ConduitSep 25 2013, 3:10 PM

I have done some tests with a simple parser function that creates a new page. I encountered similar problems as the ones reported here. I get the impression that the problem lies in performing an 'edit within an edit' (creating a new page as part of the save routine of another page).

Apparently, when we wrap the creation of the new page (the execution of doEdit()) in a job and push it on the job queue all of these issues disappear. No need to invocate parser->clearState() in that case, and no more wrong titles 'leaking' via the parser object. ApprovedRevs seems happy too.

Rcdeboer added a comment.Via ConduitOct 13 2013, 10:05 PM

Hi, just wanted to draw your attention to a recent mailing list question related to this bug: "Is WikiPage->doEdit dangerous in a parser tag callback?"


Foxtrott added a comment.Via ConduitNov 29 2013, 9:17 AM

These lines were put in some MW versions ago to obtain a deep clone of the Parser object (i.e. clone of the parser and all of the contained objects). This parser clone is needed to parse the form with a properly initialized parser (e.g. also including all initialization steps done by any extension) while keeping the original parser state intact. Then in a later MW version people got all excited about the new features of newer PHP versions and included unnamed closures in the Parser (or was it ParserOptions) object. Which are alas not serializable.

The two easy solutions that obviously do not work are to just use the original parser and hope it does not break too badly, and to try to make the Parser serializable again. The first fails with the bug discussed here. The second fails because we will never ever convince anybody to merge a core patch to make the Parser serializable again and also because if any extension somehow managed to attach a closure to the Parser, e.g. via ParserOptions, it fails again.

So there remain two solutions. The first would be to somehow conjure a Parser object from scratch and get it into a state similar enough to wgParser, that it serves our purposes. This mostly includes setting the proper ParserOptions and getting extensions to include their JS and CSS. I do not know if this is even possible, but it would certainly be a major performance drain.

The second would be to finally completely rewrite that function so that it does not change the parser state in a destructive way. This however would probably end up in a complete redesign of SF. Good luck. :P

Rcdeboer added a comment.Via ConduitDec 3 2013, 12:56 PM

What about using the job queue (cf. Comment 7)?

Foxtrott added a comment.Via ConduitDec 6 2013, 3:06 PM

Great. Now I get this, too. I experienced this after introducing "Creates pages with form" on a property and then purging a page containing that property in a printout to a query. I.e. this page was not related to SF whatsoever except that it contained said query.

thingles added a comment.Via ConduitDec 7 2013, 11:54 AM

Now that you say that, I have only ever seen this issue on wikis I have that use that "creates pages with form" property.

bzimport added a comment.Via ConduitDec 20 2013, 3:41 AM

alj62888 wrote:

Fwiw, I am also seeing this and I too use [[Creates pages with form::<form-name>]]

Does a workaround exist?

bzimport added a comment.Via ConduitDec 20 2013, 9:58 PM

alj62888 wrote:

Refreshing the page or doing another save does not fix this (restore the proper title) for me most of the time.

This happens just about all the time now after upgrading to the latest SemanticBundle (and then upgrading SF to fix another bug and then fixing another bug myself).

Also, whenever this long title appears, all of the {{#info}} markup on the page are fully expanded-out and displayed inline on the page instead of hiding in the tooltip so the whole page looks broken.

This looks way over my pay grade to try and hack-a-fix for my new wiki launch. I really need some kind of solution or workaround that does not involve not using [[Creates pages with...]] since my site relies heavily on them.


Foxtrott added a comment.Via ConduitDec 20 2013, 11:17 PM

(In reply to comment #14)

Refreshing the page or doing another save does not fix this (restore the
title) for me most of the time.

You have to actually change the page on edit, else the editing is discarded. Inserting or removing a space or newline somewhere should do the trick.

bzimport added a comment.Via ConduitDec 20 2013, 11:55 PM

alj62888 wrote:

@Stephen, I was hoping for a programmatic fix/workaround so the user never sees this. I can't launch a new site like this. I really dread rolling all the way back to the SemanticBundle alpha release :(

Foxtrott added a comment.Via ConduitDec 21 2013, 12:06 AM


the fix should be straight-forward. In SFFormLinker::createLinkedPage before calling SFFormPrinter::formHTML set $wgParser to a new Parser and restore it afterwards.

However, while you already are at it, you may also consider moving that call to formHTML into the job. Keeping an expensive function like that outside the job defies the purpose of jobs.

And I am not sure it is necessary to use that bogus title. I had to stop digging, but shouldn'it be possible to use $title->getText() or something like that?

And of course there is the fact that if you have more than one property that defines a form to be used for one red-linked page only one of the properties will be successful. Without notice or warning and with the decision which form is used non-determined.

bzimport added a comment.Via ConduitDec 22 2013, 4:12 AM

alj62888 wrote:

For me, it looks like a new edit and save is not necessary to restore the correct title. It's restored after doing a *hard* refresh (CTRL-F5 in FF). No amount of soft refreshes in FF works.

bzimport added a comment.Via ConduitJul 29 2014, 4:00 PM

mitchell_neill wrote:

I'm also seeing this occasionally when creating pages with the one step process.

There does not seem to be any pattern to it. I'm running I'm running SMW 1.9.1 on MW 1.21.11 with SF 2.7.

Foxtrott added a comment.Via ConduitJul 29 2014, 4:07 PM

Raised priority.
Creating pages from red links will crash MW 1.24+. Not once, but all the time as soon as a page creation job is in the job queue.

bzimport added a comment.Via ConduitJul 30 2014, 10:53 AM

mitchell_neill wrote:

I think I see the pattern now. I use red link auto page creation as well on certain properties. So this appears to be triggered on page save if a new property value is added in the form.

Fannon added a comment.Via ConduitOct 18 2014, 3:26 PM

Guess I've found the same bug:

I've tried the "Creates pages with form" special property and this destroyes my wiki page where this property is used. It also gets a "Some very long page name that will hopefully never get created ABCDEF123" title.
If I revert the special property back to "Has default form", everything works fine again.

bzimport added a comment.Via ConduitNov 18 2014, 2:01 PM

tafinho wrote:


I'm new to SMW and MW development but, apart from the deprecation of $wgTitle how dirty is this fix?

$sfgFormPrinter->formHTML( $form_definition, false, false, null, $preloadContent, $wgTitle->getBaseText(), null );

Apparently it seems to quick fix this issue.

Foxtrott added a comment.Via ConduitNov 18 2014, 2:13 PM

I would expect this to result in the Title of the page containing the redlink being used as the title of the newly created page.

Foxtrott added a comment.Via ConduitNov 18 2014, 2:52 PM

No, you are right. However, try the following:

  1. Have a property that creates pages (e.g. call it someProp)
  2. On page Foo add the following text: '[[someProp::Bar]]'
  3. Go to page Bar.
  4. Delete that page.
  5. Go to page Bar again (if you use the Back button do not forget to refresh the browser)

Expected: Deletion and move log for the page Bar.
Observed: Fatal error: Maximum function nesting level of '100' reached, aborting!

Aklapper placed this task up for grabs.Via Bulk EditSep 2 2015, 3:54 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptVia HeraldSep 2 2015, 3:54 PM
Kghbln added a subscriber: Kghbln.Via WebSun, Jan 10, 12:03 AM

Add Comment