Plugin for reporting pdf downloads

Software Support
,
1

Somewhat similar to my previous question, I’m making a plugin that will report views of published articles to an external API.

The plugin needs to react the same way in the following situations:

  • The user downloads the pdf to their machine.
  • The user views the pdf in their browser, either via the pdf.js plugin or the builtin pdf viewer in the browser.
  • In the future, when we have HTML versions of the our articles, we would like the plugin to also report to the API when a visitor views an HTML version.

What are the appropriate hooks to use here? I see the following hooks in pages/article/ArticleHandler.php but I’m not sure which are the correct ones to respond to:

  • ArticleHandler::download
  • ArticleHandler::view
  • ArticleHandler::view::galley
  • FileManager::downloadFinished

Any guidance would be much appreciated, thank you!

[Edit] Separately from reporting pdf downloads, we also need to report when visitors view the article abstract/landing page. I guess that is the ArticleHandler::view event?

2

After looking at the code a little bit more, my guess is that I need to respond to the following hooks:

  • ArticleHandler::view for reporting landing page views.
  • ArticleHandler::download for any kind of full-article access, whether that’s a pdf download or viewing an HTML galley.

But I’d appreciate confirmation!

3

Hi @mbtuckersimm,

At a glance, that looks correct to me!

Thanks,
Alec Smecher
Public Knowledge Project Team

4

Thanks @asmecher! I have a related question as well. In addition to recording actual downloads, we also need to record attempted downloads where the user clicks on the pdf link but is not authorized. It seems that (understandably) the ArticleHandler::download hook doesn’t fire in that situation. Do you have any suggestion for where to intervene in that case?

5

Hi @mbtuckersimm,

If you’re using the subscription toolset, have a look at the hooks in classes/issue/IssueAction.php – particularly IssueAction::subscribedUser. This is called after OJS’s internal subscription checks have been run, in order to allow a plugin to either inspect the result (your situation), or override it (e.g. in case it wants to check an external subscriber database).

Regards,
Alec Smecher
Public Knowledge Project Team

6

@asmecher Thank you.

The problem with the approach you recommend, as I understand it, is that the IssueAction::subscribedUser hook (and similarly the IssueAction::subscribedDomain hook) isn’t only run when the user clicks the download link. These hooks fire when somebody views an issue table of contents page or an article landing page in order to decide how to style the links to the pdf.

I do already have a plugin that attaches a callback to IssueAction::subscribedDomain to check an external API to see whether the IP address corresponds to a subscriber. But this is about recording actual pdf downloads and download attempts, which I only want to happen when the user has actually clicked the pdf link. I can’t record a download attempt when the user just visits the article landing page.

I guess the question is, if I want to intervene after the access decision is made, I need a way to check whether the user was actually attempting a download, or whether they were just viewing an article landing page or issue TOC page.

Does this make sense, or am I misunderstanding something?

7

Hi @mbtuckersimm,

At a glance – and my advice on this is not as well informed as if I were trawling through the code – you should be able to use those hooks, but also check within them to see what page/operation are being requested. You can do that from within the hook callback by calling something like (untested):

$request = Application::get()->getRequest();
$page = $request->getRequestedPage();
$op = $request->getRequestedOp();
if ("$page/$op" == 'article/view') {
    // This is an article view request
}

Regards,
Alec Smecher
Public Knowledge Project Team