Last modified: 2011-11-24 04:07:46 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T34485, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 32485 - SemanticForms: Creating new articles with `page name' formula is broken.
SemanticForms: Creating new articles with `page name' formula is broken.
Status: VERIFIED FIXED
Product: MediaWiki extensions
Classification: Unclassified
SemanticForms (Other open bugs)
unspecified
All All
: Unprioritized critical (vote)
: ---
Assigned To: Yaron Koren
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-19 08:34 UTC by Van de Bugger
Modified: 2011-11-24 04:07 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Van de Bugger 2011-11-19 08:34:30 UTC
I have a form:

    {{{ info | ... | page name = <unique number;start=1> }}}
    ...

This worked before, but recently broken. It r102365 "strict comparators for empty strings" caused regression. Look at `specials/SF_FormEdit.php':

    function execute( $query, $redirectOnError = true ) {
        global $wgRequest, $wgOut;
        wfProfileIn( __METHOD__ );
        $this->setHeaders();
        $this->mForm = $wgRequest->getVal( 'form' );
        $this->mTarget = $wgRequest->getVal( 'target' );

If I create a new page and want a name is calculated by formula,  I do not specify target name, so $target->mTarget is null. Before it was not a problem, because `( $this->mTarget == '' )' evaluates to true. But not most (all?) of comparisons converted to `==='. `( $this->mTarget === '' )' evaluates to false, so execution goes by a path as page name is specified, while actually is not. I can edit the page, but pressing `Save' causes error …someting about empty title.

Quick workaround for the problem could be:

    if ( is_null( $this->mTarget ) ) {
        $this->mTarget = '';
    }
Comment 1 Yaron Koren 2011-11-20 00:31:41 UTC
Thankfully, this error wasn't as severe as it seemed - it only happened in cases where the page name formula consists only of a "<unique number...>" tag. But diagnosing the problem - I just checked in what I believe is a fix.
Comment 2 Van de Bugger 2011-11-20 22:14:22 UTC
> Thankfully, this error wasn't as severe as it seemed - it only happened in
> cases where the page name formula consists only of a "<unique number...>" tag.

Yes, but it is a showstopper for my site.

> But diagnosing the problem - I just checked in what I believe is a fix.

What revision? I just updated sources to r103790, and still cannot create a page:

> Error: The inserted data results in an empty page title.
Comment 3 Yaron Koren 2011-11-23 03:02:11 UTC
Ah, that's too bad. The relevant change was this one, r103718:

r1=103129&r2=103718">http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/SemanticForms/specials/SF_FormEdit.php?r1=103129&r2=103718

It happened before the revision you updated to, so it really should have worked. Could you check, just in case, to make sure that this change is in your code?
Comment 4 Van de Bugger 2011-11-23 19:05:13 UTC
Hmm… r103718 looks like a good fix, but it does not help in my case (checked on r104063). My problem is caused by `SF_FormEdit.php' line 110:

> if ( $target_name === '' ) {

This is the first fork where execution goes to wrong direction. Note: This is the first, but not last. If I fix this one 

> if ( $target_name == '' ) {

I have another error:

Fatal error: Call to a member function getUserPermissionsErrors() on a non-object in /var/www/ocw/mediawiki-1.17.1/extensions/SemanticForms/includes/SF_FormPrinter.php on line 390 

I tried to debug further but later I decided 

> if ( is_null( $this->mTarget ) ) {
>     $this->mTarget = '';
> }

in the beginning of `execute' is the easiest workaround.
Comment 5 Yaron Koren 2011-11-23 19:52:07 UTC
Okay, I get it. I took your advice, but put in very similar code SF_FormEdit.php, instead of SF_FormPrinter.php, because it seemed like the more general solution. I checked it in to SVN - does this fix your problem?
Comment 6 Van de Bugger 2011-11-23 20:24:00 UTC
> I took your advice,…

No, that was not an advice. That was description of my attempt to get my site works after an update, and spend not too much time debugging the code.

> …does this fix your problem?

Yes, not it works. Checked on r104081. Thanks.

BTW, please pay attention to bug 32533 -- it requires 3 characters (`\s*') to be fixed. Thanks again.
Comment 7 Yaron Koren 2011-11-24 04:07:46 UTC
Well, your description was still pretty good advice. :)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links