[OJS] Unlocking articles & issues / PayPal payment problem

Dear PKP Team,

I am currently having a weird problem with the paypal payment plugin.

After trying to buy an article or issue via paypal, the (buying) user is not authorized to view the iteam after the payment has been made. So the galley button still remains “locked”. Although the payment actually shows as successful in the paypal development backend as well as in the ojs backend.

As i am running a custom theme, i tried to switch back to the default manuscript theme, but the same problem occurs there as well. I have already tried a few things, but could not really pinpoint the actual problem.

My OJS on on Apache2 /w PHP 7.0.22

Thanks in advance!

Hi @mlfct,

I would suggest stepping through the code that controls access to articles. The most relevant code will be in classes/issue/IssueAction.inc.php.

Out of interest, is this content that began in OJS 3.x, or is it something that was previously hosted in OJS 2.x and upgraded to OJS 3.x?

Alec Smecher
Public Knowledge Project Team

1 Like

Hi @asmecher,

thanks for pointing out a rough direction.

I have tried the whole process for the sake of troubleshooting on a clean database with the latest git master, but the results are the same: Payment is successful, but no access to the actual bought item. So either it could be some configuration issue on my server or it is something in the actual code. Would be interesting to know, if anyone else is having this problem…

Guess i will have to wrap my head around the code passages you mentioned.

Regarding your question: The content is straight 3.x content.


1 Like

Hey @mlfct,

i have the same problem. I activate the paypal payment but I can’t buy an article or elsewhere. I don’t know where are the errors?

Best Felix

Kind of a late reply:
If you have ssh/terminal access to your server, you can usually access the error logs under /var/log/apache2/error.log (if you’re using apache) otherwise it is probably /var/log/nginx/error.log .

Hi everyone,

we are having the opposite problem: articles can be unlocked successfully through paypall, but once a single user has unlocked an article everybody seems to have unrestricted access. (OJS 3.1.)

Another (minor) issue is that the gallery buttons do not change after successful payment, i.e. the article is still displayed as locked even though its unlocked.

Any ideas or experiences how to resolve these issues?



Hi @Etienne,

Are you checking for restricted access while logged in e.g. as a journal editor or manager? Some users are presumed to have access, regardless of whether they have an active subscription or not.

Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

no, I logged out and also tried browsers and devices which I had never used to log in before. So it shouldn’t be a problem with cookies etc.


Hi @Etienne,

Do you have institutional subscriptions set up with IP ranges?

Alec Smecher
Public Knowledge Project Team

Dear @asmecher,

we have the same problem like Etienne. And yes, we have institutional subscriptions but we are not in the IP-Area of this institutional subscriptors.


Hi @asmecher,

yes, we do. However, we had institutional subscriptions with IP ranges enabled before we installed the paypall plugin and this problem didn’t occur. Also, there are some article which were never bought by anyone through the paypall plugin and which are still locked.


1 Like

Hi everyone,

it seems that the main problem has been resolved in OJS 3.1.1-1

However, the second issue is still there: the gallery buttons do not change after successful payment, i.e. the article is still displayed as locked even though it was bought and unlocked.

Any experiences how to solve this issue?

Thanks and regards,


Same issue as original poster:

Payment plugin successfully completes transaction and inserts record into the completed_payments table for the OJS database, but instead of gaining access to issue or article galley user is then re-prompted to complete payment. This happens on OJS 3.1.1 and 3.1.0 with completely new install/content or upgrade from existing OJS2.

Apache: 2.4
Mysql: 5.7.21
PHP: 5.6.36
OJS: ojs-stable-3_1_0 & ojs-stable-3_1_1

We have tried stepping through the mentioned classes/issue/IssueAction.inc.php and comparing it to 2.4.8 (where issue/article purchases are working), to no avail.

Thank you very much,

Ok I figured out the problem. I checked IssueAction.inc.php, but could not find any issues there.

With errors on, I noticed that one of the depreciation errors referenced ArticleHandler.inc.php, so I looked there as well, and found the code that directly referenced the check for individual article purchases. I found the actual database SQL reference in OJSCompletedPaymentDAO.inc.php, and by breaking and playing with the code, found that the SQL handler seemed to not be functioning correctly. When I hard-coded the request, it worked and the article was accessible!

Trying to generalize the code for the specific cause of the error, I tried working from scratch and directly forming the query from the array index, when I noticed the problem: the referenced parameters were ordered incorrectly in the SQL.

They were all being passed correctly, but in the wrong order, which explains why some people seem to report it working. It actually isn’t, but if you have a userid of 3, it will match the payment type, and the constant payment type of 3 for one time article purchases would then match the userid. Any transaction of this type would match, thus making it seem to be functioning correctly.

Relevant function and proposed fix (OJSCompletedPaymentDAO.inc.php):

function getByAssoc($userId = null, $paymentType = null, $assocId = null) {
	$params = array();
	if ($userId) $params[] = (int) $userId;
	if ($paymentType) $params[] = (int) $paymentType;
	if ($assocId) $params[] = (int) $assocId;
            //working code
	$result = $this->retrieve(
		'SELECT * FROM completed_payments WHERE 1=1' .
		($userId?' AND user_id = ?':'') .
		($paymentType?' AND payment_type = ?':'') .
		($assocId?' AND assoc_id = ?':''),
            //fail code
	//$result = $this->retrieve(
	//	'SELECT * FROM completed_payments WHERE 1=1' .
	//	($paymentType?' AND payment_type = ?':'') .
	//	($userId?' AND user_id = ?':'') .
	//	($assocId?' AND assoc_id = ?':''),
	//	$params

	$returner = null;
	if (isset($result->fields[0]) && $result->fields[0] != 0) {
		$returner = $this->_fromRow($result->fields);

	return $returner;

This does not seem to fix the locked icon problem, though it is merely cosmetic.

A few more proposals:

I found the depreciation errors to be extremely helpful in solving this problem, so I would recommend a debug mode that will list every called core file at the top, on separate lines, and in order. That way even without dependency errors, it will be easier to debug the system without needing familiarity with the underline document structure.

Second, it may be useful to put article and issue user access in its own database table. This would make it harder to produce similar database access errors, while also allowing for more flexibility in future access options (one example could be a journal manager offering a specific reader special access to an article without having to make a fake transaction, or granting more user privileges than desired).

Hi @jamesp,

Good spotting – my own testing since 3.1.0 was released must’ve corresponded to the very specific case where the reversed IDs matched appropriately. I’ve filed this and rearranged the SQL parameter ordering properly: Correct SQL ordering for payment check · Issue #3773 · pkp/pkp-lib · GitHub

Can you briefly describe the outstanding issues now that this aspect is resolved?

Alec Smecher
Public Knowledge Project Team

Thanks to everyone for looking into this. The payment process works now with the patch applied.

The only issue i found, is that galley icons do not switch to “unlocked”/green after a user bought an article (as also mentioned by @jamesp).

Hi @asmecher , the styling of the buttons is fixed now as far as we can tell. But now we have a new problem: any time a PDF link is clicked the user is simply redirected back to the index page of the site. In other words, our users cannot view ANY PDFs. I can send you a temporary login if you’d like, so that you can see what is happening.

UPDATE: I just realized that the styling issue still exists for my user level (admin); and the redirect issue probably existed from the beginning for our subscription-based accounts. I am not sure about institutions but I know that valid individual subscription users simply cannot get PDFs—they are just redirected. Sorry, I was confused by the fact that different user types are experiencing different problems.

Hi @jamesp @jamilj @asmecher

Thanks for sharing the solution, it worked perfectly,

I am wondering if you figure out how to change the article button once the article is purchased, can you please share that solution too?

I found a solution for this problem, I have seen that it haven’t been fixed in the latest OJS version too…
I run a javascript file that checks the HTML response of the article buttons and eventually removed the css class that makes the button red.

Do you guys want me to share the solution?