Forum Replies Created
-
Posts
-
Hi,
Sharing the URL of the page that has explanation as to why caching can create this type of unexpected behavior:
https://simple-membership-plugin.com/understanding-the-impact-of-caching-on-membership-sites/Also, you can have a conflict on the site (with another plugin) that can create the unexpected behavior. The following is a good test to do:
https://simple-membership-plugin.com/forums/topic/test-for-plugin-and-theme-conflict-before-posting-an-issue-or-a-bug/You can enable the debug logging feature to check if the plugin is trying to do the redirection or not. It is useful to get clues as to what other things might be blocking the redirection:
https://simple-membership-plugin.com/enable-debug-logging/Hi, Can you please share the full debug log file for the following actions (that will give me more insight into how I need to setup my test site to try to reproduce this).
1) Reset the debug log file from the settings menu of the plugin.
2) Click the Stripe subscription button and complete the test transaction.
3) After the process is complete, copy and paste the full debug log file’s details here. I will delete the text after I check it.Also, please post the URL of the page where your Stripe subscription button is so I can inspect the HTML code of it (it will be helpful for this troubleshooting).
Thank you. The webhook configuration looks fine to me.
I need to recreate this on our site so I can investigate further. I will ask some questions to get more details:
In your case, do you see the error happen before the transaction (after you click the button) or after the transaction on Stripe?
Can you post a link to the page where you have the button so I can inspect it?
If you temporarily do the following test, is there any difference?
https://simple-membership-plugin.com/forums/topic/test-for-plugin-and-theme-conflict-before-posting-an-issue-or-a-bug/Which theme are you using on this site? I will try to install the same one to test.
Hi, I will investigate this.
The most frequent reason for issues with Stripe subscription payment buttons often stems from an incomplete webhook configuration in your Stripe account. To ensure your webhooks are set up correctly, please consult the ‘Troubleshooting Section’ of our documentation. This section provides detailed steps to verify your webhook setup:
Can you give me info on what you have configured in the webhooks menu of your Stripe.com account (for BOTH the live and test modes)? You can find your configured webhooks by going to the following page of your Stripe account dashboard:
The membership level’s duration configuration also needs to be factored in. If you are using the “No Expiry” until cancelled then it will deactivate the account as soon as cancelled. If you are using a duration expiry value then it shouldn’t deactivate the account immediately (at least that’s how it should work).
What is your membership level’s current setup?
The custom plugin you created looks good. Which line of code are you having issues with?
What is the duration setting for the membership level? Is it set to 30 days?
Our system employs a straightforward Stripe subscription model, which offers certain benefits but also comes with limitations. Our plugin operates on a cautious principle, maintaining user access until a “subscription has failed completely” webhook is received from Stripe.
Given these constraints, achieving the specific functionality you described for the trial subscription may not be feasible. It might be advisable to consider another plugin that can accommodate your requirements.
Try the following shortcode on a page:
[swpm_stripe_subscription_cancel_link]
Logged-in members should be able to click on the button created by this shortcode to cancel a Stripe subscription.
This shortcode needs some improvements (it is on our wishlist to improve it). We are somewhat overwhelmed at the moment with the various new PayPal API related changes/work. So the Stripe stuff will have to wait a while.
Just updating the thread to add some clarity for future. The discrepancy arises from the appearance of input buttons within a block that incorporates a unique CSS class. This class is added by the block, and subsequently, the theme applies specific styling to these classes. It’s important to note that these aren’t standard “label” or “Text” elements lacking a distinct CSS definition. Our plugin is designed to remain versatile across various themes.
Incorporating CSS classes from specific themes directly into our plugin’s code is not feasible due to the vast diversity of themes available. Moreover, theme obsolescence over time would introduce dependencies in our plugin’s code on outdated themes. For instance, when our plugin was launched back in 2013, the WP 2013 theme was prevalent, but it’s rarely used today. Our plugin, however, must continue to adapt and remain compatible with the evolving landscape of themes.
I will try to explain how it works below. I have tested this myself with our latest version of the plugin:
Our plugin listens to the
customer.subscription.deletedwebhook, it will adjust the account status according to the membership level configuration (the various conditions are outlined in our following documentation):
https://simple-membership-plugin.com/what-happens-when-paypal-subscription-cancelled/Upon receiving a customer.subscription.updated webhook, the plugin checks the status within the webhook. If the status is not “active” (for example, “past_due”), the plugin will disregard the update, meaning it will not change the account status to active unless the webhook explicitly indicates an active status.
After a subscription has been marked as deleted, you typically would not receive a customer.subscription.updated event for that specific subscription because it’s considered to be in a terminal state from which it cannot transition back to an active or updated state. The customer.subscription.deleted event is effectively a final state change for that subscription object. So are you saying that for your Stripe account you are receiving a
customer.subscription.updatedwebhook for a subscription that has been deleted (it already sent thecustomer.subscription.deletedwebhook already)? This means that your Stripe account might be behaving differently than what we consider to be standard operation or there is some other external conflict that we don’t understand.Do you by any chance have multiple user accounts that were created using a manual process (example: database importing) whereby it has the same email address or subscriber ID and that is causing things to behave abnormally.
It will be good to do the following basic test to establish a base line:
1) Reset the debug log file so there is a clean capture for the test.
2) Create a completely NEW user account using the plugin’s registration form (or admin dashboard).
3) Then go through subscription payment process for this user. Check that everything works.
4) Then cancel the subscription (it will send the subscription deleted webhook).
5) Check that the plugin processed this webhook and the account status is set according to the membership level as outlined below:
https://simple-membership-plugin.com/what-happens-when-paypal-subscription-cancelled/You can share the log of the above mentioned test if there is something unexpected there.
Looks like you have put some kind of site-header block that is sitting on top of that protection message. Since one layer is on top of the other layer, the content protection message is not activating the hover effect.
Add the following CSS tweak to add a margin at the top of the content protection message. This way it will sit below your other invisible site-header block and the protection message will work normally (the links will be clickable):
.swpm_full_page_protection_not_logged_msg {
margin-top: 100px;
}Hi, Below is a CSS tweak that shows how you can apply a background color of grey (hex code: #CCCCCC) with a border color of black to the login form’s input fields. You can test it out to see if this works for you:
.swpm-login-widget-form input { background-color: #CCCCCC; border: 1px solid black; padding: 5px; }Note that we can only give you some examples of how to target and apply CSS tweaks to a particular element. We don’t control how and which color can have slight discrepancy between the different browsers.
The critical error message can be sometimes little bit misleading. Reset the error_log file of the site. Also reset the debug log file of the plugin. Then test out various functionality of the site to see if you have any new errors being generated. If not, then everything is likely working fine at the moment.
Understanding Stripe payments and WordPress might seem daunting if you’re new to them. To avoid confusion early on, it’s advisable not to install too many plugins. Remember, our plugin doesn’t generate the API key; this key is provided by Stripe. You can copy those API keys from your Stripe.com account then enter these API key values into our plugin for it to interact with your Stripe account.
There are numerous tutorials and videos online that explain how to obtain your Stripe API keys. I recommend conducting a Google search to find these resources. Becoming familiar with the Stripe.com site and its functionalities can significantly reduce any initial confusion you might have.
