Re-assigning to Stephan - this seems more like your territory. What do you think?

smw wrote:

Looking at the actual code, there's clearly no wfRunHooks call along the code path invoked by this function, so it's not a matter of a bug.

It would seem to be a fairly simple problem to solve -- just add in the wfRunHooks call before the call to formHTML() in... uh... whatever function I saw that was invoked in response to the Creates_pages_with_form property.

However, my nice little attempted patch didn't work. And furthermore, replacing the variable with 'WHEEEEEEEEEEEEEE!!' still led to pages created with e.g. {{Form_Template|param1=arg}} rather than the expected 'WHEEEEEEEEEEEEEE!!' (or even containing that string at all... I thought it might be thrown in free text or something, but it wasn't).

In other words, there's something going on in formHTML() that I hadn't anticipated, and I don't have the patience or knowledge to tinker with that function :/

smw wrote:

Not that you don't know any of that, but I thought I'd mention it to show I'm making a good-faith effort to contribute and not just whining :)

Change 93813 had a related patch set uploaded by Foxtrott:
fix bug 56569 ("Create pages with form" and sfEditFormPreloadText)

https://gerrit.wikimedia.org/r/93813

Nathan, could you try, if the patched version works as expected?

Change 93813 merged by Yaron Koren:
fix bug 56569 ("Create pages with form" and sfEditFormPreloadText)

https://gerrit.wikimedia.org/r/93813

smw wrote:

Sorry, folks, it doesn't work for me.

It doesn't seem as though SFFormLinker::createLinkedPage() or SFCreatePageJob go through the API, but that could just be my lack of familiarity with the code and using a glorified text editor instead of a real IDE :/

Change 93865 had a related patch set uploaded by Foxtrott:
fix bug 56569 ("Create pages with form" and sfEditFormPreloadText)

https://gerrit.wikimedia.org/r/93865

Seems I fixed a different bug with the first patch. Could you try the new patch, please?

smw wrote:

Still not working. For the record, that's very close to the patch I attempted and mentioned briefly in comment #2. formHTML() hates my guts?

FWIW, the pages created for this test previously existed but were deleted (since they didn't contain the desired data). Just in case the presence of a deleted article is a possibly confounding issue...

smw wrote:

Actually, just noticed that Change 93813 seems to break my extension -- from what I can tell, the $preloadContent variable is populated correctly but never inserted. Never utilized by formHTML()?

smw wrote:

To reiterate, I think this commit may break all sfEditFormPreloadText extensions.

smw wrote:

A new sfEditFormPreloadText extension doesn't work either. This is with the latest commit (#c1b52276c2492a51 or so).

smw wrote:

Still doesn't work. Am I the only person who uses sfEditFormPreloadText?

Maybe what I should do is turn my extensions into regular text preloading extensions, create and save the page, *then* edit it with the form.

You are not the only one. An important feature of SNPedia is impacted by this.

This is a regression of
https://bugzilla.wikimedia.org/show_bug.cgi?id=47150

smw wrote:

Thanks for the information, cariaso. I'm glad to have some more of the context to flesh out this cluster of issues.

I spent some time looking at this, and am confident that the function which is hooked to 'sfEditFormPreloadText'

is being called for existing pages

is _not_ being called for non existent pages

The problem originates near
SF_FormEditAction.php Line 157

static function displayForm( $action, $article ) {

	        // @todo: This looks like bad code. If we can't find a form, we
		// should be showing an informative error page rather than
		// making it look like an edit form page does not exist.
                $title = $article->getTitle();
		$form_names = SFFormLinker::getDefaultFormsForPage( $title );
                if ( count( $form_names ) == 0 ) {
	                return true;
		}

notice the @todo comment, suggesting this code was never quite finished. returning true here, bails out before the

SFFormEdit::printForm( $form_name, $page_name );

a few lines further down in the code.

for pages which exist, they eventually get down to the hook code via this route.

#0 [internal function]: prefillForm(string, Title, Title)
#1 /var/www/html/includes/Hooks.php(206): call_user_func_array(string, array)
#2 /var/www/html/includes/GlobalFunctions.php(4004): Hooks::run(string, array, NULL)
#3 /var/www/html/extensions/SemanticForms/includes/SF_AutoeditAPI.php(834): wfRunHooks(string, array)
#4 /var/www/html/extensions/SemanticForms/includes/SF_AutoeditAPI.php(116): SFAutoeditAPI->doAction()
#5 /var/www/html/extensions/SemanticForms/specials/SF_FormEdit.php(92): SFAutoeditAPI->execute()
#6 /var/www/html/extensions/SemanticForms/includes/SF_FormEditAction.php(173): SFFormEdit::printForm(string, string)
#7 /var/www/html/extensions/SemanticForms/includes/SF_FormEditAction.php(27): SFFormEditAction::displayForm(SFFormEditAction, Article)
#8 /var/www/html/includes/Wiki.php(428): SFFormEditAction->show()
#9 /var/www/html/includes/Wiki.php(292): MediaWiki->performAction(Article, Title)
#10 /var/www/html/includes/Wiki.php(588): MediaWiki->performRequest()
#11 /var/www/html/includes/Wiki.php(447): MediaWiki->main()
#12 /var/www/html/index.php(46): MediaWiki->run()
#13 {main}

however empty pages bail out early, and never get the chance to prepopulate their page text.

Change 93865 had a related patch set uploaded by Qgil:
fix bug 56569 ("Create pages with form" and sfEditFormPreloadText)

https://gerrit.wikimedia.org/r/93865

Change 93865 merged by Yaron Koren:
fix bug 56569 ("Create pages with form" and sfEditFormPreloadText)

https://gerrit.wikimedia.org/r/93865

smw wrote:

As far as I can tell, this still breaks all sfEditFormPreloadText extensions.