Last modified: 2008-07-10 12:31:49 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 11820 - enumerated Property:Page only works for first allows_value
enumerated Property:Page only works for first allows_value
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
All All
: Normal major (vote)
: ---
Assigned To: Markus Krötzsch
Depends on:
  Show dependency treegraph
Reported: 2007-10-30 22:15 UTC by S Page
Modified: 2008-07-10 12:31 UTC (History)
3 users (show)

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


Description S Page 2007-10-30 22:15:56 UTC
Yaron Koren in pointed out that there's a bug in the handling of properties of type "Page" that are enumerations - fields that have this property get a "not on the list of possible values" error on the screen if they have a value other than the very first one on the list.

I reproduced, see URL.

Yaron comments:

I traced this problem, and found the issue: a variable is created, in "SMW_DataValue.php", to loop through the list of allowed values, checking each one against the current value. In the case of a wiki page, however, that variable keeps a cached version of its title, that is set the very first time and then is never reset. There are are various ways to solve this problem, but the easiest might be to change the function parseUserValue() in the file "/includes/SMW_DV_WikiPage.php". You can add a new line after line 26, so instead of

                        $this->m_value = $value; now reads

                        $this->m_value = $value;
                        $this->m_title = null;

This will prevent the old value of "m_title" from getting read and used in place of the actual value.

skierpage comments:
This fix works great for me.  However, there are other member variables that parseUserValue() may leave untouched, though mainly in an error case where maybe it doesn't matter.  Which functions should reset a datavalue, setUserValue() or parseUserValue(), or both?
Comment 1 S Page 2007-10-30 22:51:41 UTC
I checked in Yaron's fix to SMW_DV_WikiPage.php, revision 27069.
Comment 2 S Page 2008-01-05 13:13:01 UTC
James McMurtrie found this issue broke again, see

I confirmed with the same URL, so reopening.

The issue is exactly the same as before.  The datavalue variable that loops through the allowed values doesn't reset and/or update all its state on setUserValue(), so only the "first" allows value (as with any special property, the values return from the database in random order) matches.

I don't know the general way to fix this.  To repeat:

'''Which functions should reset a datavalue, setUserValue() or parseUserValue(), or both?'''
Comment 3 S Page 2008-01-05 13:45:10 UTC
*IF* parseUserValue() is the place to reset, then *A* fix is in SMW_DV_WikiPage.php's parseUserValue(), before it calls getTitle(), set $this->m_dbkeyform = NULL; as well.  Otherwise getTitle() creates a title from the old cached value of m_dbkeyform().

But, see my original "skierpage comments:"
Comment 4 Yaron Koren 2008-01-17 16:39:01 UTC
I definitely think S Page's suggested solution, of adding the line "$this->m_dbkeyform = NULL;", should be applied to the code for now, regardless of what the "ideal" solution is.
Comment 5 Markus Krötzsch 2008-04-17 19:09:05 UTC
Oops, that bug was open for too long, given that it was a one-liner. Fixed now in SVN.

I think the clean way would be to have some function "clearValue" for all datatypes that is then used in set*Value(). Maybe I will do it like that soon.
Comment 6 CW Dillon 2008-07-10 10:52:51 UTC
Our wiki is experiencing the symptoms of this bug again.  It was failing in SMW 1.0.1 and we replicated it on our test server after upgrading to SMW 1.2.  We can try the patch Yaron provided, above to solve our site problems, but thought you'd want to know that the bug seems to still be there.

Comment 7 CW Dillon 2008-07-10 12:31:49 UTC
Aargh!  Turns out that the programmer and I were working off of two different test sites; no matter what he tried on the "development" site, the problem persisted on the "test" site.  Nothing to see here.  Pay no attention to the new guy.

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