[OJS 3.2.4.1] Readers can't view pdfs

diegomejia07 · March 8, 2022, 10:49pm

Hi,

I have a published number in which the pdf’s cannot be viewed and when clicking on these it redirects me to the article search page. They can only be seen if you are logged in as admin of the journal.

When clicking on the pdfs, it shows me a 302 error inspecting the browser, but nothing is shown in the error logs.

Captura

But if I look for them in the DB I see that they are published.

kshuttle · March 10, 2022, 1:26am

Hi @diegomejia07,

Could you please provide a few more screenshots to demonstrate what is happening and what the issue looks like?

A screenshot of an article landing page. Is the PDF galley button appearing as expected?
What a user sees when they click on the PDF galley button from the article landing page (please show us or describe what you mean by “article search page”)
The Galley section of the Publication tab for the submission, where the PDF is uploaded. Does the PDF open successfully from the Galley section of the publication tab?

Thank you for the additional clarification.

Best regards,

Kate

diegomejia07 · March 10, 2022, 12:18pm

Hi @kshuttle,

This happens with a full number of the journal, but it only happens with that number. The articles and PDF’s in the galleys are assembled as it has always been done and there is no inconsistency, at least at first glance:

[image]

1. A screenshot of an article landing page. Is the PDF galley button appearing as expected?
Here you can see the buttons to open the PDF’s of the articles. These can be viewed only when I enter the journal as an admin or manager.

2. What a user sees when they click on the PDF galley button from the article landing page (please show us or describe what you mean by “article search page”)
When I click on the PDF button, it opens the platform’s search page.

3. The Galley section of the Publication tab for the submission, where the PDF is uploaded. Does the PDF open successfully from the Galley section of the publication tab?

kshuttle · March 10, 2022, 5:22pm

Hi @diegomejia07,

Thanks for your reply. Can you please check the access settings in the following places:

Users and Roles > Site Access Options. Ensure the first two options are unchecked.
Distribution > Access. Ensure the first option is checked (unless your journal charges subscriptions).

Thank you,
Kate

diegomejia07 · March 10, 2022, 6:22pm

Hi @kshuttle, @asmecher,

I think there is no problem with the configuration, because as I had already told you, I only have this problem in a single number of the journal, the rest work very well. I don’t know what else I can check there that can help me validate what the error may be.

asmecher · March 10, 2022, 7:11pm

Hi all,

@diegomejia07, this is caused by an inconsistency in the database. The redirect to search is happening here:

github.com

pkp/ojs/blob/stable-3_3_0/pages/article/ArticleHandler.inc.php#L542

      
        
            
            
					if (!isset($galleyId) || $galleyId) {
            						if (!Validation::isLoggedIn()) {
            							Validation::redirectLogin('reader.subscriptionRequiredLoginText');
            						}
            						$request->redirect(null, 'about', 'subscriptions');
            					}
            				}
            			}
            		} else {
            			$request->redirect(null, 'search');
            		}
            		return true;
            	}
            
            
	/**
            	 * Set up the template. (Load required locale components.)
            	 * @param $request PKPRequest
            	 */
            	function setupTemplate($request) {
            		parent::setupTemplate($request);

It’s caused by falling through this condition:

github.com

pkp/ojs/blob/stable-3_3_0/pages/article/ArticleHandler.inc.php#L471

      
        
            		$user = $request->getUser();
            		$userId = $user?$user->getId():0;
            
            
		// If this is an editorial user who can view unpublished/unscheduled
            		// articles, bypass further validation. Likewise for its author.
            		if ($submission && $issueAction->allowedPrePublicationAccess($context, $submission, $user)) {
            			return true;
            		}
            
            
		// Make sure the reader has rights to view the article/issue.
            		if ($issue && $issue->getPublished() && $submission->getStatus() == STATUS_PUBLISHED) {
            			$subscriptionRequired = $issueAction->subscriptionRequired($issue, $context);
            			$isSubscribedDomain = $issueAction->subscribedDomain($request, $context, $issue->getId(), $submission->getId());
            
            
			// Check if login is required for viewing.
            			if (!$isSubscribedDomain && !Validation::isLoggedIn() && $context->getData('restrictArticleAccess') && isset($galleyId) && $galleyId) {
            				Validation::redirectLogin();
            			}
            
            
			// bypass all validation if subscription based on domain or ip is valid
            			// or if the user is just requesting the abstract

My guess is that the status column in the submissions table does not match the value in the publications table. Try:

SELECT p.status, s.status FROM submissions s JOIN publications p ON (s.current_publication_id = p.publication_id) WHERE s.submission_id = 17;

Regards,
Alec Smecher
Public Knowledge Project Team

diegomejia07 · March 10, 2022, 7:20pm

Hi @asmecher,

Make the query in the database that you tell me, and it shows me this

What else can I do there, to solve this problem.

asmecher · March 10, 2022, 8:39pm

Hi @diegomejia07,

Hmm, how about this query to check that the issue’s status is accurately set to “published”?

SELECT i.issue_id, i.published
FROM issues i
JOIN publication_settings ps ON (ps.setting_value = i.issue_id AND ps.setting_name = 'issueId')
JOIN submissions s ON (s.current_publication_id = ps.publication_id)
WHERE s.submission_id=17;

Regards,
Alec Smecher
Public Knowledge Project Team

diegomejia07 · March 10, 2022, 8:43pm

Hi @asmecher,

This is the result of the new query, and I see that the data is fine, since the issue_id is 4.

asmecher · March 10, 2022, 8:48pm

Hi @diegomejia07,

Hmm, it might be necessary to add some debug code around the areas I indicated to see what specific condition isn’t being met, leading to the redirect. Is it possible that you’re using numeric values for the custom article or custom issue IDs? If so, those might be clashing with the numeric database IDs; for that reason, if you’re using custom IDs, it’s best to make sure your custom IDs include something non-numeric. But that’s just a guess.

Regards,
Alec Smecher
Public Knowledge Project Team

diegomejia07 · March 10, 2022, 8:51pm

Hi @asmecher,

I don’t use custom issue IDs. The truth is that the publication was made just like the others, but this is the only one in which the galley proofs or the galley proof files cannot be viewed.

https://revistas.udea.edu.co/index.php/mutatismutandis/issue/view/4

asmecher · March 11, 2022, 7:48pm

Hi @diegomejia07,

It’s hard to know what’s happening remotely; I would recommend using some error_log PHP statements to determine what path those requests are taking to end up at the redirect. In particular, which of the conditions in the if statement linked above is causing execution to fall through to the redirect?

Is the $issue object is unset?
Is the $issue->getPublished() call returning false? I believe we’ve already ruled this out.
Is the submission status not STATUS_PUBLISHED? I believe we’ve already ruled this out.

If the $issue object is unset, is it because $issueDao->getById returns null? If so, what parameters are being given to it, and why don’t they match the database?

Regards,
Alec Smecher
Public Knowledge Project Team

diegomejia07 · March 11, 2022, 8:44pm

Hi @asmecher,

With some error_log statements, I get the following error.

PHP Fatal error:  Uncaught Error: Call to a member function getId() on null in /pages/article/ArticleHandler.inc.php:533\nStack trace:\n#0 /pages/article/ArticleHandler.inc.php(216): ArticleHandler->userCanViewGalley(Object(Request), 14, 245)\n#1 /lib/pkp/classes/core/PKPRouter.inc.php(391): ArticleHandler->view(Array, Object(Request))\n#2 /lib/pkp/classes/core/PKPPageRouter.inc.php(231): PKPRouter->_authorizeInitializeAndCallRequest(Array, Object(Request), Array, false)\n#3 /lib/pkp/classes/core/Dispatcher.inc.php(145): PKPPageRouter->route(Object(Request))\n#4 /lib/pkp/classes/core/PKPApplication.inc.php(281): Dispatcher->dispatch(Object(Request))\n#5 /index.php(68): PKPApplication->execute()\n#6 {main}\n  thrown in /pages/article/ArticleHandler.inc.php on line 533, referer: https://revistas.udea.edu.co/index.php/mutatismutandis/issue/view/4

asmecher · March 11, 2022, 9:53pm

Hi @diegomejia07,

I’d need to know what modifications you made, and in particular what that line of code looks like. I suspect it’s one of the lines you’ve inserted/modified.

Regards,
Alec Smecher
Public Knowledge Project Team

diegomejia07 · March 15, 2022, 12:58pm

Hi @asmecher,

What I did was put the error_log statement before:

$request->redirect(null, ‘search’);

And that’s when the error I mentioned was registered:

PHP Fatal error:  Uncaught Error: Call to a member function getId() on null in /pages/article/ArticleHandler.inc.php:533\nStack trace:\n#0 /pages/article/ArticleHandler.inc.php(216): ArticleHandler->userCanViewGalley(Object(Request), 14, 245)\n#1 /lib/pkp/classes/core/PKPRouter.inc.php(391): ArticleHandler->view(Array, Object(Request))\n#2 /lib/pkp/classes/core/PKPPageRouter.inc.php(231): PKPRouter->_authorizeInitializeAndCallRequest(Array, Object(Request), Array, false)\n#3 /lib/pkp/classes/core/Dispatcher.inc.php(145): PKPPageRouter->route(Object(Request))\n#4 /lib/pkp/classes/core/PKPApplication.inc.php(281): Dispatcher->dispatch(Object(Request))\n#5 /index.php(68): PKPApplication->execute()\n#6 {main}\n  thrown in /pages/article/ArticleHandler.inc.php on line 533, referer: https://revistas.udea.edu.co/index.php/mutatismutandis/issue/view/4

asmecher · March 17, 2022, 10:11pm

Hi @diegomejia07,

What is line 216 of pages/article/ArticleHandler.inc.php?

Regards,
Alec Smecher
Public Knowledge Project Team

diegomejia07 · March 18, 2022, 3:56pm

Hi @asmecher,

On line 216 is:

if ($this->galley && !$this->userCanViewGalley($request, $article->getId(), $this->galley->getId()))

asmecher · March 28, 2022, 3:00pm

This topic was automatically closed after 10 days. New replies are no longer allowed.

asmecher · April 5, 2022, 11:02pm

Hi @diegomejia07,

Something is happening here that I’m not spotting. The line of code you quote is

if ($this->galley && !$this->userCanViewGalley($request, $article->getId(), $this->galley->getId()))

…which is causing an error report of…

PHP Fatal error:  Uncaught Error: Call to a member function getId() on null in /pages/article/ArticleHandler.inc.php:533
Stack trace:
#0 /pages/article/ArticleHandler.inc.php(216): ArticleHandler->userCanViewGalley(Object(Request), 14, 245)
#1 /lib/pkp/classes/core/PKPRouter.inc.php(391): ArticleHandler->view(Array, Object(Request))
#2 /lib/pkp/classes/core/PKPPageRouter.inc.php(231): PKPRouter->_authorizeInitializeAndCallRequest(Array, Object(Request), Array, false)
#3 /lib/pkp/classes/core/Dispatcher.inc.php(145): PKPPageRouter->route(Object(Request))
#4 /lib/pkp/classes/core/PKPApplication.inc.php(281): Dispatcher->dispatch(Object(Request))
#5 /index.php(68): PKPApplication->execute()
#6 {main}\n  thrown in /pages/article/ArticleHandler.inc.php on line 533, referer: https://revistas.udea.edu.co/index.php/mutatismutandis/issue/view/4

The two calls to getId() that could be causing the error are

$article->getId(), and
$this->galley->getId()

The first is impossible because there is a function call on $article a few lines above:

'currentPublication' => $article->getCurrentPublication(),

…and since this call didn’t generate an error, obviously $article can’t be null.

The second is also impossible because the if contains the check:

if ($this->galley && ...

…ensuring that $this->galley can’t be null either.

Are you sure there’s not a modification of the code causing the problem? I note that the error message makes reference to pages/article/ArticleHandler.inc.php:533 – in OJS 3.2.1-4 that file is only 519 lines long.

What is line 533 of pages/article/ArticleHandler.inc.php?

Regards,
Alec Smecher
Public Knowledge Project Team