Extension talk:PubmedParser

Previous page history was archived for backup purposes at Extension talk:PubmedParser/LQT Archive 1 on 2015-07-10.

@Bovender I'm really enjoying your extension (using on https://wikimsk.org) Would you consider looking into having a parameter for identifying the article as open or closed access? I'm not sure how pubmed stores this information though as it doesn't seem to be in the XML file. e.g. for this open access article https://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi?db=pubmed&id=20203111&retmode=xml

Thanks for the suggestion and your kind words. You're right, Open Access information is nowhere to be found in the data. Maybe they query some other data source in the background. If you do not absolutely need to have a link to the original PDF, you can use a link to the full text in PubMed Central as a workaround. That's how I do it in my Wikis. My Pubmed template contains this bit: {{#if:{{{pmc}}}|[https://ncbi.nlm.nih.gov/pmc/{{{pmc}}}?report=reader Volltext]}}. At least in some cases, the PubReader has a link to the original PDF at the top left. BTW I realize I should amend the Readme with this information...

Thank you that is very helpful, I've adjusted my template to include that. I added a line to the template variable table about it, I hope that's ok.

Thanks very much, sure it's ok ;-) If I ever have some spare time, I'll move the Readme over to the Github repository to have a single version-controlled place where code and documentation is stored.

Upgrade to PubmedParser 4.0.3

In my installation of MW 1.32.0 and PubmedParser 4.0.2, single author papers will trigger usage of pubmedparser-and for {{{authors}}} or {{{auhorsi}}}. For instance: {{#pmid:12345}} will produce: Rubinstein & (1976) ... Is there something I might be doing wrong? Thanks!

I need to investigate; created an issue an Github: https://github.com/bovender/LinkTitles/issues/42.

Thanks! Will track the issue on Github ...

OK, I somehow managed to create this issue in the wrong repository... Moved it to https://github.com/bovender/PubmedParser/issues/2, but more importantly, I also fixed the bug... Version 4.0.3 was released just now.

I have a MW instance that was updated from 1.21.something to 1.23.13. I didn't setup the old wiki, and it is no longer around for me to look at, but I have several references that look like <ref name=PMID:19957275/>. I realize this is not the current markup used by PubmedParser, but I was wondering if perhaps our old wiki used an older version of PubmedParser. If that is the case, will I need to update to a newer version of MW to get these references working again and if so, will the pages that use the older markup just work, or will I need to do some other stuff too?

Thanks.

If you have <ref name=PMID...> in the Wiki text itself, then that's not produced by PubmedParser. (Maybe by some other Pubmed-parsing extension.) PubmedParser markup looks like {{#pmid:12345}} and will never be changed in the source text of your pages. If you look at the page source in the browser, then you will of course see <ref> tags, but this is only the rendered output. The page source is not affected. You might want to try to force a re-rendering of the page by appending ?action=purge to a URL and see what happens.

Does this help?

Daniel (author of PubmedParser)

Hi Daniel,

Yes it does help, if only to confirm that PubmedParser isn't what was used before.

Thanks, Scott

Caused by Semantic MediaWiki.

Hi, the brackets generated by the parser function, which point to the reference at the bottom of the page e.g. [1] are not formatted in balance. The opening bracket is part of the link while the closing bracket is not. See this image. The closing bracket should be part of the link, too. Cheers

MediaWiki 1.27.3, PubmedParser v4.0.2, PHP 5.6.30

I believe that's not an issue with PubmedParser. All that PubmedParser does is write out <ref>...</ref> tags, i.e., it makes use of the Cite extension. Besides, I can't reproduce on my Wiki?

Well, it must be an issue with the Cite extension on REL1_27. Doing <ref>{{#pmid:19782018}}</ref> not using the reference name parameter gives the same unbalanced view.

Just tested this with BlueSpiceSkin, Foreground and Vector on two different wikis with different setups and they all give me this view. Which version of MediaWiki are you using?

I'm on MW 1.18.0, PubmedParser 4.0.1 (funny, not current), PHP 5.5.9 on my production wiki and on MW 1.26.3, PubmedParser 4.0.2, PHP 7.0.18 on my development wiki. If it's a REL1_27 issue, it was not there in 1.26 and disappeared in 1.27 ;-)

Just verified that I really do not see this behavior.

I keep this on close watch. There is a reason but I have not figured it out yet.

I have found another case where the trailing bracket gets formatted differently. So it must be the Foreground skin doing this and not this extension. Thanks for your time anyways!

Hi, We have recently had some problems with our original PubMed extension implementation hanging the Wiki server and were trying to test PubmedParser as a possible solution. I have a simple problem on my test page https://embryology.cmsdev.med.unsw.edu.au/embryology/index.php/Test_PubmedParser, that it is not returning entries for single author papers. Have I missed something?

Hm, works just fine over here with PMID 17304021 for example. Please try to force fetching it from Pumed again: {{#pmid:17304021|reload}}.

Plus, could you please tell me what server your Wiki is running on and whether you have allow_url_fopen enabled? Are you able to cite other articles listed on Pubmed? (It cannot have anything to do with single vs. multiple authors, the error occurs because no XML data is received, for whatever reason.)

v4.0.0 was released that included this change

@Bovender: The current version 3.1.1 of this extension is still using the I18n-via-php-mechanism. This was depreciated in favour of the I18n-via-json-mechanism (see Manual:GenerateJsonI18n.php). It will be nice if this extension could be migrated. At the same time the I18n for the tag (magic word) could probably be moved to a separate file, too. Cheers

Thanks, I'll look into it. Sorry for not responding for such a long time, I had inadvertently stopped receiving notifications from this stite.

Oops. Thank you for your effort in reviving the extension!

v4.0.2 was release to mitigate the issue

Setup

• MediaWiki 1.27.1 (36b636d) 20:26, 11. Jan. 2017
• PHP 5.6.29-0+deb8u1 (apache2handler)
• MariaDB 10.0.29-MariaDB-0+deb8u1
• PubmedParser 4.0.1 (f63e6b3) 22:58, 9. Nov. 2016

Issue

When running maintenance script for other extensions such as e.g. Semantic MediaWiki or BlueSpice I get heaps of these warnings:

PHP Notice:  Constant PUBMEDPARSER_OK already defined in /.../w/extensions/PubmedParser/includes/PubmedParser_Extension.php on line 41
PHP Notice:  Constant PUBMEDPARSER_INVALIDPMID already defined in /.../w/extensions/PubmedParser/includes/PubmedParser_Extension.php on line 42
PHP Notice:  Constant PUBMEDPARSER_NODATA already defined in /.../w/extensions/PubmedParser/includes/PubmedParser_Extension.php on line 43
PHP Notice:  Constant PUBMEDPARSER_CANNOTDOWNLOAD already defined in /.../w/extensions/PubmedParser/includes/PubmedParser_Extension.php on line 44
PHP Notice:  Constant PUBMEDPARSER_DBERROR already defined in /.../w/extensions/PubmedParser/includes/PubmedParser_Extension.php on line 45
PHP Notice:  Constant PUBMEDPARSER_INVALIDXML already defined in /.../w/extensions/PubmedParser/includes/PubmedParser_Extension.php on line 46
PHP Notice:  Constant PUBMEDPARSER_TEMPLATECHAR already defined in /.../w/extensions/PubmedParser/includes/PubmedParser_Extension.php on line 47

Stack trace

This an exemplary stack trace:

2017-02-06 14:16:58 hoffmeyer 0222020151125-49275_: [c6a3062643734072ad7941d8] [no req]   ErrorException from line 47 of /.../w/extensions/PubmedParser/includes/PubmedParser_Extension.php: PHP Notice: Constant PUBMEDPARSER_TEMPLATECHAR already defined
#0 [internal function]: MWExceptionHandler::handleError(integer, string, string, integer, array)
#1 /.../w/extensions/PubmedParser/includes/PubmedParser_Extension.php(47): define(string, string)
#2 [internal function]: PubmedParser\Extension::setup(Parser)
#3 /.../w/includes/Hooks.php(195): call_user_func_array(string, array)
#4 /.../w/includes/parser/Parser.php(335): Hooks::run(string, array)
#5 /.../w/includes/parser/Parser.php(345): Parser->firstCallInit()
#6 /.../w/includes/parser/Parser.php(5075): Parser->clearState()
#7 /.../w/includes/parser/Parser.php(649): Parser->startParse(Title, ParserOptions, integer, boolean)
#8 /.../w/extensions/BlueSpiceFoundation/includes/utility/PageContentProvider.class.php(144): Parser->preprocess(string, Title, ParserOptions)
#9 /.../w/extensions/BlueSpiceFoundation/includes/utility/PageContentProvider.class.php(109): BsPageContentProvider->getContentFromRevision(Revision, integer, NULL, boolean)
#10 /.../w/extensions/BlueSpiceExtensions/ExtendedSearch/includes/BuildIndex/BuildIndexMainControl.class.php(718): BsPageContentProvider->getContentFromTitle(Title)
#11 /.../w/extensions/BlueSpiceExtensions/ExtendedSearch/includes/BuildIndex/BuildIndexMwArticles.class.php(127): BuildIndexMainControl->extractEditSections(Title)
#12 /.../w/extensions/BlueSpiceExtensions/ExtendedSearch/includes/BuildIndex/BuildIndexMainControl.class.php(263): BuildIndexMwArticles->indexCrawledDocuments()
#13 /.../w/extensions/BlueSpiceExtensions/ExtendedSearch/includes/BuildIndex/BuildIndexMainControl.class.php(398): BuildIndexMainControl->buildIndexWiki(string)
#14 /.../w/extensions/BlueSpiceExtensions/ExtendedSearch/maintenance/searchUpdate.php(27): BuildIndexMainControl->buildIndex()
#15 /.../w/maintenance/doMaintenance.php(103): SearchUpdate->execute()
#16 /.../w/extensions/BlueSpiceExtensions/ExtendedSearch/maintenance/searchUpdate.php(38): require_once(string)
#17 {main}

It seems that files are being 'required' more than once?

No, I just have wfLoadExtension( 'PubmedParser' ); once in "LocalSettings.php". Probably I should try to use the classic "require_once ..." to rule out an issue with wfLoadExtension.

Nope, switching to require_once "$IP/extensions/PubmedParser/PubmedParser.php"; does not change a thing.

Since I get an error log of 100 MB each time I run some script it will be nice to have a fix for it.

Apart form that. People on the wiki are very happy with the extension. So thank you for creating it!

This happens only on pages which use the parser function. I cannot imagine that ExtendedSearch and Semantic MediaWiki are trying to invoke the namespaces a second time. Semantic MediaWiki is parsing the page again to update the data added to it. Perhaps this helps.

I'll need to investigate, please bear with me!

I have an error log of about 10 to 20 MB due to this every day. So if there is a fix it will be cool to get it.

Do you have the opportunity to test the `develop` branch? I just pushed a hack that prevents defining the constants twice.

I have two Wikis and neither produce these warnings, so I have a suspicion that it's not the PubmedParser extension that is the root of the problem. But maybe this fix solves it for you!

Many thanks for this. This indeed seems to have tackled the issue! Great!

OK, 4.0.2 is out.

Thanks a lot!

Database migration fixed for the upcoming version 4.0.0.

I'm trying to install this extension for the first time today, and I had the aforementioned issues with 3.2.0 and 3.2.1. I tried installing the development version (4.0.0), and when I attempted to upgrade my wiki I had the following error:

Uncommitted DB writes (transaction from DatabaseUpdater::doUpdates). in .../includes/db/Database.php on line 4262

Any suggestions would be appreciated. Thanks!

Thanks for reporting this. From what version and to what version did you upgrade your MediaWiki installation?

Oh, and could you please elaborate what issues you had with the 3.2.x versions? Thanks.

I don't recall what the previous version was (sorry!). I recently upgraded to 1.26.3, but I didn't have this extension installed with the previous version.

And the previous issues were the database:ignore errors in 3.2.0 and the query error in 3.2.1 (which is still present since I cannot complete the wiki manual upgrade per the installation instructions)

OK, I've updated the database creation code to use a transaction. Hopefully this will prevent the error. Please try the latest commit from the development branch.

Still an issue. Something I didn't notice before in the text the upgrade tool was spitting out:

Creating Pubmed table ...

An error occurred:

[c98ccaec] /wiki/mw-config/?page=Upgrade   MWException from line 3885 of .../wiki/includes/db/Database.php: Could not open ".../wiki/extensions/PubmedParser/includes../db/PubmedParser_Migration.sql".

It appears that PubmedParser_Migration.sql is not in that location, but in /wiki/extensions/PubmedParser/db, Would that matter?

Yes, of course. A missing slash caused this. I've pushed the fix.

I know I should have an automated test suite for the extension, and in fact I do do quite a lot of test-driven development, but somehow I have never gotten to terms with the MediaWiki testing environment...

Fully operational! Thank you kindly! This works very well for my purposes. I'll post again if I see any issues.

Fixed in version 4.0.0

Probably I has something to do with manually creating the database table, though I currently cannot imagine why (table prefix used?). However, when trying to insert an Pubmed-ID via the parser function I get the following error:

Query

INSERT INTO `49275_pubmed` (pmid,xml) VALUES ('123456','<?xml version=\"1.0\"?>\n<!DOCTYPE PubmedArticleSet PUBLIC \"-//NLM//DTD PubMedArticle, 1st January 2015//EN\" ...)

Function

DatabaseBase::insert

Error

1062 Duplicate entry '123456' for key 'PRIMARY' (localhost)

Setup

• MediaWiki 1.23.9
• MySQL 5.5.43
• PHP 5.4.41

I found out that the "reload" paramter to the parser function is causing this issue. These are the errors I found in the server's log:

PHP Notice:  Undefined variable: xml in /.../extensions/PubmedParser/PubmedParser.Core.php on line 150, referer: https://www.example.org/w/index.php?title=Testseite&action=edit
[client 91.65.247.53] PHP Notice:  Undefined variable: _writeDb in /.../extensions/PubmedParser/PubmedParser.Core.php on line 259, referer: https://www.example.org/w/index.php?title=Testseite&action=edit

Another thing I realised is that the #pmid parser function is not registered in its section on "Special:Version" as it should.

It will be very cool if this could be fixed.

I'll get back to this...

Fixed in the development branch, [https://github.com/bovender/PubmedParser/commit/b11ec69c0b09148335f60959aa6893a8dbe1469e b11ec69]. Target milestone: v4.0.0.

Great, thanks a lot!

Fixed in version 3.2.x

After upgrading from MediaWiki 1.24.x to 1.26.2, I started noticing that some pages just plain wouldn't load, with an accompanying Apache error log messageː

"Call to protected method DatabaseBase::ignoreErrors()"

I fixed this by commenting out the method call in PubmedParser.Core.php on line 233.

Dave

My apologies for not responding for so long. For whatever reason I was not notified of your comment -- funnily, I stumbled upon it after upgrading my own Wiki to 1.26.x, encountering the error and googling it ... ;-) I'll look into it, i.e. try to remember what the purpose of ignoreErrors was in this context.

Version 3.2.1 (which I released just now) no longer has this line.