Wikimedia Bugzilla is closed!

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

:-)

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.

(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.

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.

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:

Backtrace:

#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?

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?

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.

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

http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg71816.html

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

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

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.

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

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

Does a workaround exist?

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.

Thanks

(In reply to comment #14)
> Refreshing the page or doing another save does not fix this (restore the
> proper
> 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.

@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 :(

Yaron,

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.

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.

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.

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.

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.

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.

Hi,

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.

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.

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!