Blank page viewing article after upgrade to 2.3.7

[ntorres]

Hi,

I've upgraded from 2.1.1.0 to 2.3.7. I found an estrange behavior in some published articles. When I click to read the article abstrat I get a blank page, looking for a reason in error log I found this message:

[Mon Dec 03 10:01:57 2012] [error] [client x.x.x.x] PHP Fatal error: Call to a member function getOpenAccessDate() on a non-object in /dades/ojs-2.3.7/cache/t_compile/%%28^280^280EE005%%dublincore.tpl.php on line 41, referer: http://www.myojs.com/index.php/myjourna ... 71/showToc

I review the issue information and it looks fine; some articles from the same issue has no problems and are viewables.

Any suggestion?

Thanks

[JasonNugent]

Hi there,

You might be dealing with a template that's still cached from before your upgrade. Can you try clearing out your cached templates from inside of the administration interface when logged in as your OJS admin and see if the error remains?

Regards,
Jason

[ntorres]

Hi,

I tried it when I found the error in apache error log and the error remains.

thanks

Natalia

[JasonNugent]

Hi Natalia,

It's possible that an issue may not exist for an article, if the article is being worked on (i.e., is not scheduled yet) and the current user is an editorial user. In that case, there may not be an issue object available in the template. If that's the case, there should be a test for the existence of the object in the template, which would be a bug. Can you say one way or the other if the article that is causing problems has been assigned to an issue? Is it published?

Regards,
Jason

[JasonNugent]

Hi Natalia,

This does appear to be a bug. This particular problem was fixed in OJS 2.4 in this commit:

https://github.com/pkp/ojs/commit/20a8d ... incore.tpl

But the change does not appear to have been back-ported to 2.3. I will commit a fix to that branch, but in the mean time you can probably make the trivial edit to templates/article/dublincore.tpl yourself, which will fix the problem.

Cheers,
Jason

[ntorres]

Hi Jason,

I apply the changes to fix it on my ojs but it doesn't works. Now when When I click to read the article abstrat I takes me to the journal home page. I looking for a reason in error log but there are no message. If I login to the journal with my user I can acces to the abstract page and get the pdf.

Thanks,

Natalia

[JasonNugent]

Hi Natalia,

That sounds like a different issue. When you attempt to view the article abstract, are you logged in as an editor? If you're attempting to view an article that has not been published in an issue, there is validation code that checks to make sure that you are allowed to do this. If you're not logged in, you can't view things that are not published so you will get redirected back to the home page.

Regards,
Jason

[ntorres]

Hi Jason,

I'm not logged in when I tried it, and the issue and the article are both published some time ago (they are included in the journal using the import/export plugin). It repeats in some articles from some different journals included in our ojs installation with multiple journals.

I can access the issue using "Archived" from journal menu links. When the table of contents is showed I click the title of the article to access to the abstract page or to PDF label to download the file and both options takes me to the journal home page.

As you say I login as user and repeat the same way to access to issue table of contents and article and I can access to abstract page or to download the article file. It's so estrange because both are published .


Thanks,

Natalia

[ntorres]

Hi,

any idea to how to solve it. We have a lot of articles in this situations.

Regards,
natalia

[JasonNugent]

Hi natalia,

Another thought on this. Are the articles that cannot be accessed listed in issues that should be open access? If you have access to your database, can you check and see what the value of the access_status column is in the 'issues' table for the issue that contains the articles that can't be viewed?

Regards,
Jason

[ntorres]

Hi Jason

I review the accesss_status in issue table for this issues and the value is 1 and open_access_date is an old date(2007, 2008...)

natalia

[JasonNugent]

Hi Natalia,

Hmm, okay. I'm not sure how much debugging you want to do on this, but the redirection that occurs is happening in a function called validate() in pages/article/ArticleHandler.inc.php. It's a fairly long function, but there are several calls to Validation::redirectLogin() in there. If you can, you can insert some logging functionality right before those statements to see which one is being used and we can go from there. PHP has an error_log() function that will place a message in either Apache's error_log or in PHP's log file, if you have that enabled. You can just put a string like: error_log('in the first one'); and then look for the message.

It's possible that the error is being generated higher up, in PKPHandler.inc.php's validate() function, but I hope not. You can put some error_log statements in lib/pkp/classes/handler/PKPHandler.inc.php's validate() function also. Once we know why the redirection is occurring, we can look for a solution.

Regards,
Jason

[ntorres]

Hi Jason,
I've tried you said in you message and I found that the redirect occurs in else branch of if ($issue && $issue->getPublished() && $publishedArticle->getStatus() == STATUS_PUBLISHED). I've reviewed the setting values in validate function (articleId, galleyId, ...) and if I change the last parameter in getPublishedArticleByArticleId function (useCache to get the article) I can access to this articles

function validate(&$request, $articleId, $galleyId = null) {
....
if ($journal->getSetting('enablePublicArticleId')) {
$publishedArticle =& $publishedArticleDao->getPublishedArticleByBestArticleId((int) $journalId, $articleId, true);
} else {
$publishedArticle =& $publishedArticleDao->getPublishedArticleByArticleId((int) $articleId, (int) $journalId, false);
}
...
}

From ojs administrator I used administrative functions such "Clear Data Caches" and "Clear Template Cache" to clear cache some times. This caches is not the same?

Regards,

natalia

[JasonNugent]

Hi Natalia,

If this is the statement that is failing:

Code: Select all

if ($issue && $issue->getPublished() && $publishedArticle->getStatus() == STATUS_PUBLISHED)


Then one of those three things is evaluating to false. So, either you do not have a valid issue at that point in the code, or the issue is not published, or the article you're attempting to look at is not published (or maybe it is, but the status is not STATUS_PUBLISHED).

So, three things we can look at.

Right before that if statement line, I suggest adding three lines of code.

Code: Select all

error_log(var_export($issue, TRUE));
error_log('is issue published: ' . $issue->getPublished());
error_log('article status is: ' . $publishedArticle->getStatus());


Ideally, the first statement should generate a whole lot of lines, which indicates that you do indeed have an issue. The second line should print a '1' if the issue is published. The third line should print a '3', which is what the STATUS_PUBLISHED constant evaluates to. One of those things will not occur. Probably worth mentioning that if the first one is the problem, then the second one will generate a fatal error because you don't have an issue object to call getPublished() on.

The article status is stored in the articles database table in the status column. For published articles, it should be 3. Articles still going through the submission process are queued (2) and articles that have been archived have a status of 1. If you know the article id, you can probably make some test changes.

This is sounding like a bug during the upgrade process, where some articles may have not had their status changed to the correct value. There have been some changes to that part of the code and you did upgrade from a very old version of OJS.

Regards,
Jason

[ntorres]

Hi Jason,

I'll try this and say you anything.

You're right, we upgrade from very old version: ojs-2.0.2-1. We upgrade to ojs 2.3.4 and while we where testing this version (with lots of differences) a new version appears so finally we upgrade from ojs 2.3.4 to ojs 2.3.7.

Natalia