nunks
Forum Replies Created
-
Hi!
I updated to 2.12.1 and password reset is working again.
Sorry for not being able to reply earlier, and thank you for quickly fixing this issue!
Sorry, I think this was due to a failed update. I tried upgrading again to 1.8.2 and everything is fine.
Hello, thanks for the fast response!
I now changed the setting to skip the confirmation step and it seems to be working fine.
Since this is a low volume site and we generally know our users beforehand, I issued a refund to the user, cancelled her subscription on PayPal and asked her to try again. If I had manually changed the order status to “success” as a workaround, I think I would have lost the data collected during checkout through the Register Helper Addon, and I’d rather ask the user to fill the form again than ask for it via email.
If I had manually changed the order status, would the rest of the subscription automation still work, like scheduled expiration warning emails? Would it work if I manually filled the payment and subscription IDs by hand?
Even if PayPal denies confirmation because of some kind of timeout, shouldn’t the IPN receipt “overwrite” the order status? In my test, the confirmation IPN was only received after I clicked “confirm” even when I waited 5 minutes and got the error message, so it seems safe to rely on the IPN as a fallback to review confirmation, doesn’t it? Of course, this doesn’t solve the problem with missing Registration Helper data…
Thanks again!
…here’s the gist I mentioned above in my previous message (which was sadly blocked for moderation ?? )
To rephrase it quickly: I think the “and” is translatable, it’s in the “pmpro_implodeToEnglish” function and calls a translation domain. I built the gist above because I needed to get rid of the “oxford comma”.
Hi! I think the “and” in the “shownoaccess” shortcode actually can be translated, at least it seems so when I look at the github code for PMPro. The pmpro_get_no_access_message() function calls pmpro_implodeToEnglish() to build the message string, and it contains a translation call:
I went to investigate this because I also had an issue with the message built by PMPro: my language (brazillian portuguese) doesn’t allow the use of the “oxford comma” and I have three membership levels. I thought it would be easy to fix this using the pmpro_non_member_text_filter and pmpro_not_logged_in_text_filter filters, but they are run BEFORE the substitutions are made and the only data available for the filters is the text with the !! variables :(.
I ended up using these filters to rewrite the whole function, parsing the shortcode of the current post to find out what the levels are and then building the “no access” message in a more personalized fashion (I can post it in a gist for you if you want, I just need to translate my comments from portuguese to english), but I think it would be nice if the PMPro devs could add a filter just before the return statement in pmpro_get_no_access_message()…
…this would make it easy to fix any unforeseen translation issues ??
Oops, sorry, it took me a while to understand that pmpro_required_billing_fields() is used to set fields as required for form validation.
I understand, by looking at the structure of the orders table, that the address fields are somewhat constrained to the original design. I think I’ll need to save localized brazillian data to usermeta and simultaneously format it to fit the order object, and then retrieve it from usermeta as needed in subsequent orders, webhook responses etc.
Still, do you have any advice as to how I can define gateway-specific form fields for the user to fill?
Thank you very much for the clarification, @andrewza
I’ll consider the options you gave me, as well as maybe get a bit more involved in the future and try to pull the data via the PayPal API.
Thanks again!