Hi @radjr,
Here is the data from the composer.lock file. This shows version 3.0.4. We know from Paypal that this is still version 1 as they call it and it is deprecated many years ago.
I suspect you’re referring to Omnipay’s PayPal adapter making use of the PayPal v1 API. I don’t have any particular insight into this, but there appears to be a longstanding issue filed on the PayPal adapter’s Github repo for this. I don’t see any concrete plans for the V1 API being retired e.g. by a specific date; hopefully if/when that happens, Omnipay will update their integration. Meanwhile it should be working.
RE: if you change your database character set configuration without converting the data that’s stored in the table.
The only time a table would have been changed would have been on a version upgrade. Do you remember when the ojs upgrade required a change in type? Also for a newbie, how would I recovert the data? Again many thanks.
This is inherently a fussy collation/DBA question, so unfortuantely it’s not newbie friendly. Long story short, OJS faithfully connects with whatever character set you specify in config.inc.php
, but over the years MySQL has changed its default character set, and it’s possible to accidentally garble things with MySQL dump/reload cycles if you don’t specify the character set on the command line, which has sometimes happened to OJS users. The OJS serialize
/unserialize
functions are picky about string lengths, and a UTF-8 string that’s been incorrectly encoded in the database may trigger that. We don’t use serialize
/unserialize
for much and it’s generally not critical. That may be what’s happened here.
If I were approaching this from your perspective, and not wanting to get lost in details, I’d try to capture a little more information about the warnings you’re seeing to know whether they’re important or not. Go to the line of code that’s giving you the warning, and modify it to capture details in your error log when the content can’t be unserialized.
Is there a script available to reconcile queued_payments, completed_payments and access to subscriptions or reprints? The goal is to find those users who did not pay(1) and still have access.
(1) We have proven that is the payment gateway fails in a certain way, the user still gains access to the item they were trying to purchase.
No, there isn’t a script to reconcile queued payments with completed payments. When a queued payment is fulfilled via confirmation from PayPal, it is removed from queued_payments
, and a completed_payments
entry is created instead. Only completed_payments
is checked to see whether a user should have access to paywalled contents; whether or not there is a queued_payment
entry for that user is irrelevant.
So in the ArticleHandler.php, it looks in the completepayment table to get access to the files via the completedpayment call. BUT, see the code below. The code suggests that if the transaction just took place, you just give them access. Can you share the thinking? Is there a race condition?
If you use the code formatting tools available in this forum software it’ll be easier to read; I’m not sure if you’re highlighting a specific line of code. But no, I don’t think there’s a race condition. PayPal should fulfill the payment in OJS before redirecting the user back to the article webpage.
Just a heads-up that I can only give limited help with these subjects, particularly when they require server-side investigation; it can be incredibly time-consuming to intuit what’s happening.
Regards,
Alec Smecher
Public Knowledge Project Team