Last modified: 2014-05-05 13:10:02 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 T65487, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 63487 - refreshLinks.php is destroying SMW-Data
refreshLinks.php is destroying SMW-Data
Status: UNCONFIRMED
Product: MediaWiki
Classification: Unclassified
Maintenance scripts (Other open bugs)
unspecified
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-03 16:11 UTC by Ekim
Modified: 2014-05-05 13:10 UTC (History)
5 users (show)

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


Attachments

Description Ekim 2014-04-03 16:11:36 UTC
Everytime when I run refreahLinks.php without any options, the complete semantic data from SMW is destroyed in the database (not on the pages).

The complete Attributes are destroyed, and semantic querys leats to no results.

After editing and safing a random page, the semantic data of this single random page is recovered. This is working with every page.


I have figured out the following:

when I comment out the line ~244 in refreshLinks.php

$updates = $content->getSecondaryDataUpdates( $page->getTitle());

the semantic data is not destroyed.

-> https://github.com/wikimedia/mediawiki-core/blob/master/maintenance/refreshLinks.php


Also I have figured out that inside the RefreshLinksJob.php

there is a very similar function in line 172


 $updates = $content->getSecondaryDataUpdates( $title, null, false, $parserOutput );


with much more source code in front.


https://doc.wikimedia.org/mediawiki-core/master/php/html/RefreshLinksJob_8php_source.html


I have the feeling this second script is the one that runs after a single page edit with saving. This one seems to work fine.


Am I right? What can I do to fix the problem?
Comment 1 Andre Klapper 2014-04-04 13:00:42 UTC
(In reply to Ekim from comment #0)
> Everytime when I run refreahLinks.php without any options, the complete
> semantic data from SMW is destroyed in the database (not on the pages).

Where exactly (tables etc.) is semantic data stored by SMW?

> The complete Attributes are destroyed

Is that a table created by SMW?

> and semantic querys leats to no results.

Any example query?
Comment 2 Ekim 2014-04-04 17:39:12 UTC
(In reply to Andre Klapper from comment #1)
> (In reply to Ekim from comment #0)
> > Everytime when I run refreahLinks.php without any options, the complete
> > semantic data from SMW is destroyed in the database (not on the pages).
> 
> Where exactly (tables etc.) is semantic data stored by SMW?
> 

SMW is storing the data in a MySQL database.

> > The complete Attributes are destroyed
> 
> Is that a table created by SMW?

Attributes is this case are exclusive for SMW.

> 
> > and semantic querys leads to no results.
> 
> Any example query?


[[Is Member of Organisation::Coca Cola]] entered in the Special pages SMW-Query.

leads normaly to the result that all (in this wiki stored) employees of "Coca Cola" will be listed.



I also figured out, that the bug must have to do something with the usage of templates.

Every semantic data, defined directly on a page is not affected, only the semantic data that is entered through a template (this is my case) will be destroyed through refreshLinks.php
Comment 3 Bawolff (Brian Wolff) 2014-04-04 20:10:26 UTC
Its probably caused by the line:

$wgParser->clearTagHooks(); (line 79 of refreshLinks.php)

Which is probably somewhat misguided as some hooks are important (This has caused bugs on Wikimedia wikis in the past). I would say we should get rid of that line and instead make extensions implement the MaintenanceRefreshLinksInit where it is appropriate.
Comment 4 Bawolff (Brian Wolff) 2014-04-04 20:19:13 UTC
Actually, I wouldn't expect that to affect link annotation syntax (since that's from a InternalParseBeforeLinks hook), but it would affect any {{#foo type syntax. Don't know much about SMW though.
Comment 5 Ekim 2014-04-04 20:25:19 UTC
I have some more informations:

If I change this line in my template:

[[ist member of organization::{{{organization|}}}]] 

to

[[is member of organization::coca cola]] 


Every page with a Person using the template is now member of Coca Cola and refreshLinks.php is not affecting this.


For me it seems to be a problem of the ??Parser?? who must replace {{{organization}}} (but dont do it right) before Evaluation?


Additional: If I run a SMW-Query from the Special-page lige theese:

[[is member of organization::{{{organization|}}}]]
[[is member of organization::{{{organization}}}]]
[[is member of organization::{{organization}}]]
[[is member of organization::organization]]

Shows no result, so something is replaced for {{{Organisation|}}} but what?
Comment 6 Bawolff (Brian Wolff) 2014-04-04 20:49:52 UTC
>{{{Organisation|}}}

Is replaced by an empty string if no Organisation parameter specified...
Comment 7 Ekim 2014-04-04 21:01:35 UTC
Yes, but in my case organization is getting a valid Parameter.


By the way, I have replaced

[[is member of organization::{{{organization|}}}]]

with

{{#set:is member of organization={{{organization}}}}}
{{{organization}}}


To avoid a link.


But I get the same results in destroying semantic data through refreshLinks.php


Additional: In Specialpages:Properties I can see some results like this:

Jim Beam + <tplarg><title>Organization</title><part><Name index="1"/><value/></part></tplarg> 

or
Comment 8 p858snake 2014-04-04 21:05:09 UTC
it might help if someone adds a few of the semantic people onto the cc list
Comment 9 Andre Klapper 2014-04-04 22:58:05 UTC
(In reply to p858snake from comment #8)
> it might help if someone adds a few of the semantic people onto the cc list

Adding Markus and Jeroen.

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


Navigation
Links