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.
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 .
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?
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.
Regards,
Alec Smecher
Public Knowledge Project Team
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.
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.
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.
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.
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 = ?':''),
$params
);
//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);
}
$result->Close();
return $returner;
}
This does not seem to fix the locked icon problem, though it is merely cosmetic.
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 @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.
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.