Last modified: 2014-09-24 01:17:58 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 11539 - Add Hooks to SpecialImport and SpecialExport
Add Hooks to SpecialImport and SpecialExport
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Export/Import (Other open bugs)
1.11.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-reviewed
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-02 17:19 UTC by Christian Neubauer
Modified: 2014-09-24 01:17 UTC (History)
4 users (show)

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


Attachments
Fix against 11.0 release (5.07 KB, patch)
2007-10-05 16:37 UTC, Christian Neubauer
Details
Patch against 1.13r39163 (5.05 KB, patch)
2008-08-13 15:24 UTC, Christian Neubauer
Details
Make nodeContents public and add the $tag param to various hooks (601 bytes, patch)
2012-01-19 14:11 UTC, Christian Neubauer
Details

Description Christian Neubauer 2007-10-02 17:19:59 UTC
I have an extension that adds additional metadata to pages.  I've modified SpecialImport and SpecialExport to handle importing/exporting this additional metadata, but it would be nice if this could be done via hooks instead of modifying core code.  It doesn't look like an easy problem to solve since the importer relies on callbacks but...
Comment 1 Christian Neubauer 2007-10-05 16:37:06 UTC
Created attachment 4219 [details]
Fix against 11.0 release

Adds a hook to Export.php right before it writes the closing </revision> to allow extensions to export additional metadata for a revision.

Changes the way importing is handled slightly.  When an unknown tag is encountered in the <revision> block now, instead of throwing an error, the importer stores the tag in an array.  After the revision is saved in the WikiRevision class, a hook is fired with the array as a parameter allowing extensions to import the custom tags.  Hopefully nothing currently relies on the error throwing bit.

Usage:

$wgHooks['ExportPageRevision'][] = 'efExportMetadata';
function efExportMetadata( $writer, $revid, $out ) {
    // lookup additional metadata for the revision using the $revid
    $metadata = getRevisionMetadata($revid);
	
    // construct additional metadata chunks and write them to $out
    foreach($metadata as $field=>$value) {
        $out .= "      " . wfElement( $field, null, strval( $value ) ) . "\n";
    }
    return true;
}

$wgHooks['ImportPageRevision'][] = 'efImportMetadata';
function efImportMetadata( $wikirev, $revid, $metadata ) {
    // Do something with the imported metadata
    $revision = Revision::newFromId($revid);
    $custom_metadata_handler = new CustomMetadataHandler($revision);

    foreach($metadata as $name=>$value) {
        $custom_metadata_handler->handle($name, $value);
    }
    return true;
}
Comment 2 Brion Vibber 2007-10-15 23:04:53 UTC
Please post patches as attachments so they can be managed without copy/paste problems.
Comment 3 Christian Neubauer 2007-10-16 11:54:40 UTC
I don't understand.  Do you mean don't select the patch checkbox when you are submitting an attachment?
Comment 4 Brion Vibber 2007-10-16 16:58:45 UTC
I mean *attach a file*, don't paste it into a comment.
Comment 5 Christian Neubauer 2007-10-17 17:34:05 UTC
Um, I did attach the patch.  It's id 4219.  Its the one and only attachment on this bug.  What I typed into the first comment is not a patch, its the recommended usage of the code that was added in the patch.  Something that an end user would put in an extension to use the new hooks.
Comment 6 Christian Neubauer 2008-08-13 15:24:58 UTC
Created attachment 5175 [details]
Patch against 1.13r39163

The import hook in this patch fires right before the revision is saved and passes the revision object so it can be manipulated.
Comment 7 Siebrand Mazeland 2008-08-18 18:47:37 UTC
Mass compoment change: <some> -> Export/Import
Comment 8 Mike.lifeguard 2008-11-22 19:11:06 UTC
Is this a dupe of bug 11537?
Comment 9 RV1971 2008-11-23 22:04:28 UTC
It seems to me that this is a superset of bug 11537 in that it proposes more changes to the code. The part corresponding to bug 11537 is the patch to importOldRevision(). This patch is different from that of bug 11537 and appears at a different place, but I think it can be used for similar purposes. (The order in which hooks would be fired is different between the two bugs, but this should be of little importance.)

Personally, I'd be happy if any of the two would be included in one of the next releases.
Comment 10 RV1971 2009-01-06 17:47:04 UTC
My DataTable extension (http://www.mediawiki.org/wiki/Extension:DataTable) now uses the hook NewRevisionFromEditComplete (http://www.mediawiki.org/wiki/Manual:Hooks/NewRevisionFromEditComplete), so personally I don't have any further need for the hook suggested here.
Comment 11 Christian Neubauer 2009-12-17 15:14:09 UTC
So I still need this, but I'm not going to continue making patches for it until there is some indication that it is going to get added to the code.  If someone with permissions feels like committing this, let me know and I'll generate a new patch against trunk.
Comment 13 Christian Neubauer 2011-10-27 17:40:50 UTC
Oh so close!

Unless I'm missing something, ImportHandleRevisionXMLTag is worthless for processing the imported XML.  It doesn't pass the name of the tag being processed or the contents of the tag.  Also, the tag name/contents are stored in a private member/function of the importer so you can't get to them in a hook.

Can we either, 1) modify the hook to pass the tag name and tag contents or 2) make the $reader member and nodeContents function in WikiImporter public?
Comment 14 Sumana Harihareswara 2011-11-24 19:25:20 UTC
Christian, I am very sorry for the wait.  I've cc'd the people who currently work on these dumps so they can advise you.  Thank you for your contribution and sorry again for the delay in response!
Comment 15 Sam Reed (reedy) 2012-01-16 15:44:02 UTC
Comment on attachment 5175 [details]
Patch against 1.13r39163

Marking as obsolete as it is superseded in core
Comment 16 Sam Reed (reedy) 2012-01-16 15:49:57 UTC
(In reply to comment #13)
> Oh so close!
> 
> Unless I'm missing something, ImportHandleRevisionXMLTag is worthless for
> processing the imported XML.  It doesn't pass the name of the tag being
> processed or the contents of the tag.  Also, the tag name/contents are stored
> in a private member/function of the importer so you can't get to them in a
> hook.
> 
> Can we either, 1) modify the hook to pass the tag name and tag contents or 2)
> make the $reader member and nodeContents function in WikiImporter public?

Well, making the variables directly public is a no, adding a getFunction() is fair enough.

Extra parameters passed to the hook should be fine

What do the currently passed things give you?
Comment 17 Christian Neubauer 2012-01-19 14:11:55 UTC
Created attachment 9869 [details]
Make nodeContents public and add the $tag param to various hooks

(In reply to comment #16)
> What do the currently passed things give you?

http://www.mediawiki.org/wiki/Manual:Hooks/ImportHandleRevisionXMLTag
http://www.mediawiki.org/wiki/Manual:Hooks/AfterImportPage

* $importer: The WikiImporter object
* $pageInfo: An array of xml tag names => xml tag content for the <page> object
* $revisionInfo: An array of xml tag names => xml tag contents for the <revision> object

Theoretically in the ImportHandleRevisionXMLTag hook, you would process the XML input and add data to the $pageInfo or $revisionInfo array.  Then later on in the AfterImportPage hook, you could process the data and save it to the database or whatever.

The problem is, the actual data being parsed out of the XML is stored in the $tag object in the importer and that isn't passed to the hook so you can't actually see what tag is being encountered.  Adding the $tag param to the hook would fix that.  To get the contents of the XML tag, you need to call $importer->nodeContents() which is currently a private function.  Making that function public would totally solve that.
Comment 18 Sam Reed (reedy) 2012-01-19 15:44:25 UTC
(In reply to comment #17)
> Created attachment 9869 [details]
> Make nodeContents public and add the $tag param to various hooks
> 
> (In reply to comment #16)
> > What do the currently passed things give you?
> 
> http://www.mediawiki.org/wiki/Manual:Hooks/ImportHandleRevisionXMLTag
> http://www.mediawiki.org/wiki/Manual:Hooks/AfterImportPage
> 
> * $importer: The WikiImporter object
> * $pageInfo: An array of xml tag names => xml tag content for the <page> object
> * $revisionInfo: An array of xml tag names => xml tag contents for the
> <revision> object
> 
> Theoretically in the ImportHandleRevisionXMLTag hook, you would process the XML
> input and add data to the $pageInfo or $revisionInfo array.  Then later on in
> the AfterImportPage hook, you could process the data and save it to the
> database or whatever.
> 
> The problem is, the actual data being parsed out of the XML is stored in the
> $tag object in the importer and that isn't passed to the hook so you can't
> actually see what tag is being encountered.  Adding the $tag param to the hook
> would fix that.  To get the contents of the XML tag, you need to call
> $importer->nodeContents() which is currently a private function.  Making that
> function public would totally solve that.

I think your patch is the wrong way round, as it shows you're making it private

Also, please use a unified diff against a file, see https://www.mediawiki.org/wiki/Subversion#Making_a_diff
Comment 19 Sumana Harihareswara 2012-01-19 18:08:11 UTC
adding "reviewed"
Comment 20 Christian Neubauer 2012-01-20 14:55:13 UTC
(In reply to comment #18)
> 
> I think your patch is the wrong way round, as it shows you're making it private
> 
> Also, please use a unified diff against a file, see
> https://www.mediawiki.org/wiki/Subversion#Making_a_diff

Bah!  I was trying to make a diff without checking anything out.  I'll try again later when I have some time to mess with it.
Comment 21 Sumana Harihareswara 2012-10-14 21:27:06 UTC
Christian, is this still something you have an interest in?   We now use Git https://www.mediawiki.org/wiki/Git/Tutorial in case you'd like to address this hook addition again.  (And if the answer is "no, I'm rather tired of this issue and wash my hands of it" I completely understand.)

Best wishes.
Comment 22 Christian Neubauer 2012-10-15 11:14:44 UTC
I am still interested in the capability but realistically I'm not going to be submitting a patch for it again. Thanks for following up.

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


Navigation
Links