Extension talk:PubmedParser

Jump to navigation Jump to search

About this board

pubmedparser-and and single author papers

4
Summary by Kghbln

Upgrade to PubmedParser 4.0.3

PLX2000 (talkcontribs)

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!

Bovender (talkcontribs)
PLX2000 (talkcontribs)

Thanks! Will track the issue on Github ...

Bovender (talkcontribs)
Scottcain (talkcontribs)

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.

Bovender (talkcontribs)

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)

Scottcain (talkcontribs)

Hi Daniel,

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

Thanks, Scott

Brackets not formatted in balance

7
Summary by Kghbln

Caused by Semantic MediaWiki.

Kghbln (talkcontribs)

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

Bovender (talkcontribs)

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?

Kghbln (talkcontribs)

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.

Kghbln (talkcontribs)

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?

Bovender (talkcontribs)

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.

Kghbln (talkcontribs)

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

Kghbln (talkcontribs)

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!

121.44.240.147 (talkcontribs)
Bovender (talkcontribs)

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

Bovender (talkcontribs)

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.)

Reply to "Single author papers"
Summary by Kghbln

v4.0.0 was released that included this change

Kghbln (talkcontribs)

@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

Bovender (talkcontribs)

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

Kghbln (talkcontribs)

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

PHP notice: Constants already defined

11
Summary by Kghbln

v4.0.2 was release to mitigate the issue

Kghbln (talkcontribs)

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}
Bovender (talkcontribs)

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

Kghbln (talkcontribs)

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.

Kghbln (talkcontribs)

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!

Kghbln (talkcontribs)

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.

Bovender (talkcontribs)

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

Kghbln (talkcontribs)

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.

Bovender (talkcontribs)

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!

Kghbln (talkcontribs)

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

Bovender (talkcontribs)

OK, 4.0.2 is out.

Kghbln (talkcontribs)

Thanks a lot!

Issues with wiki upgrade

9
Summary by Bovender

Database migration fixed for the upcoming version 4.0.0.

Bveremis (talkcontribs)

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!

Bovender (talkcontribs)

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

Bovender (talkcontribs)

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

Bveremis (talkcontribs)

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.

Bveremis (talkcontribs)

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)

Bovender (talkcontribs)

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.

Bveremis (talkcontribs)

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?

Bovender (talkcontribs)

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...

Bveremis (talkcontribs)

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

Summary by Kghbln

Fixed in version 4.0.0

Kghbln (talkcontribs)

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.

Bovender (talkcontribs)

I'll get back to this...

Bovender (talkcontribs)

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

Kghbln (talkcontribs)

Great, thanks a lot!

DatabaseBaseːːignoreErrors()

3
Summary by Kghbln

Fixed in version 3.2.x

2602:306:CF46:34E0:80FF:BBCC:B0A2:B7FB (talkcontribs)

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

Bovender (talkcontribs)

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.

Bovender (talkcontribs)

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

$wgPubmedParserCache parameter broken

3
Summary by Kghbln

$wgPubmedParserCache no longer available, Database is used instead for storage.

Kghbln (talkcontribs)

No cache files are created when configuring this parameter though the directory is writable by the server. However I think that this one is not absolutely necessary since the data is now stored in the database.

Bovender (talkcontribs)

You're right, thanks. In fact, this variable is no longer used by the extension. I've removed the information from the page.

Kghbln (talkcontribs)

Great, thanks for clarifying!