Norm Sash

Only thing I’ve been able to get to work (somewhat) is to select the keywork that is inside the brackets and then format that as inline code. Don’t include the brackets as part of the inline code. Or use backticks to surround the keyword, which should be the same as formatting the keyword as inline code.

With that it highlights the keyword, but not the brackets. And it doesn’t render the shortcode. Not exactly the same as just putting a plain text non-rendered shortcode in the text (like what shows in this thread earlier) but at least it doesn’t render.

Thanks @hupe13 … but yeah, I’ve tried xxx and formatting as in-line code. Neither of them work. Both of those forms still render the shortcode. The only thing I’ve found to not render the shortcode is to put it in a separate code block (which isn’t inline) or to surround the shortcode keyword with spaces.

Does the xxx format work for you inline? Are you using the Enlighter plugin that you mentioned earlier in order to do this?

Edit: I just noticed that the double bracket [[ format actually just makes a link of the text to the wordpress codex… like this which is formatted with the [[ format: xxx And then it removes the brackets so it ends up not being displayed as a [shortcode] text at all.

• This reply was modified 4 months, 2 weeks ago by Norm Sash.

I’m sorry, it appears as if I wasn’t clear in my op about what I want to achieve.

What I would like to do is display [shortcode] as plain inline text, and not have the shortcode rendered. For example, say I have a valid shortcode on my site with the keyword “banner”. Now I want to write some instructions for using that shortcode. Thus, I need to place [banner] inline within the paragraph context (just like in this paragraph).

But when I do that on a site where [banner] is a valid shortcode, it gets rendered every place where it is put.

I can’t use the shortcode or code blocks because they still render the shortcode, and in the case of the shortcode block, it’s not rendered inline.

The only solution that I’ve found is to put a space character on either side of the shortcode name, like [ banner ]. But that could be interpreted wrong by the reader unless I put in a disclaimer to eliminate the spaces if they are actually going to use the shortcode.

Hopefully that explains better my objective.

Hey, thanks for pointing me in the right direction. I was able to find the Stripe transactions and view the customer records. I do see the failed Stripe transactions and the error message stated above along with the previous successful transactions.

In Stripe I don’t see any payment methods on the customer account. In their WC account profile I see one payment method.

The customer is on an annual renewal, and I see a number of events from 6/6/2023. See https://share.zight.com/L1ubeBGb

I can understand one of the card detachments, but the other doesn’t make sense to me. I am suspicious of one thing thought. I was previously using WooCommerce Stripe plugin. Then when switching to Payment Plugins Stripe, when the customer made a payment two payment method entries are entered into their WC payment methods. One with a 4-digit date mm/yy and one with a 6-digit date mm/yyyy. The 4-digit one is WC Stripe, the 6-digit one is Payment Plugins.

So in WC dashboard, two payment methods were listed, both having the same card number. I’m suspecting that the ‘duplicate’ payment method with 4-digit date (WC Stripe) was deleted, and then that ended up detaching the payment method from the customers Stripe account, even though the 6-digit date payment method (Payment Plugins) was still on the customer’s WC dashboard.

Jumping in here, not to hijack, but just to say that I’m also seeing this error:

Recurring payment for order failed. Reason: The provided PaymentMethod was previously used with a PaymentIntent without Customer attachment, shared with a connected account without Customer attachment, or was detached from a Customer. It may not be used again. To use a PaymentMethod multiple times, you must attach it to a Customer first.

I’m not sure what it means. Context: This is a customer’s WooCommerce subscription renewal that has been working for 4 years. I’m currently running Payment Plugins v3.3.71. Not all subscription renewals by customers are showing this error – only a random few. When I look in stripe I don’t even find any record of a failed transaction for this renewal.

Also, it doesn’t matter if I manually try to process the renewal order… it returns the same error.

• This reply was modified 5 months, 2 weeks ago by Norm Sash.

Thanks so much for the updates and detailed explanation. I’ve been testing and trying to recreate what I had been seeing. So far I have been unsuccessful. I’m almost positive that the behavior that I had seen before was with the WC Stripe plugin. Maybe there was some change to WC Subscriptions that coincided with the timing of my change from WC Stripe to Payment Plugins (?).

I’ve been studying your code screenshot from your point #3. I’m not a coder, but I can’t see the relationship between that code snippet and the subscription billing detail Payment Method. It seems to be that code applies to the interface where the payment method is changed, not the admin subscription details page. Am I not understanding it correctly (very possible).

But it seems to me that the Payment Method displayed on the Subscription Details page should be something like “Card ending in xxxx”. Since the subscription is Active, and there is a parent order with a payment method, it is known which payment method will be used for the subscription payment (at least up until the time the payment method is changed).

Maybe that is something that is controlled by WCS and you have no ability to modify it. If so, maybe you have better luck in providing feedback to WCS. Every time I try to get more information from WC or provide feedback the response is always “we can’t provide help with that, talk to a developer.” WC is terrible to work with IMO and is on my list of the worst developers to work with (rant over).

Now, a new (but related) issue… In doing my testing it brought up another anomaly I saw while switching plugins from WC Stripe to Payment Plugins. When a customer had a previous card saved with WC Stripe, and then enters another purchase with the same CC but using Payment Plugins, a new saved payment method is created. Now when looking at an accounts payment methods there are two listed — both with the same card number, etc., but the details are slightly changed, such as the date formatting. This causes problems because I (or the customer) can’t tell which one is the correct one to use and which one is assigned to be the payment method for various subscriptions (as they just show “card ending in xxxx”. See the following screenshot: https://share.zight.com/qGublNDO

Again, I don’t know where the responsibility for this lies, but it seems to me that there should be one payment method listed per card number.

Thanks, -Norm

Done… Enhancement request filed. Thanks James.

I wasn’t able to get a before shot on some of the issues, but here is a compilation of various screen views which are showing the problem. It compares the Order List page vs the Subscriptions List page. Then the Order Details page vs the Subscription Details page. And also what is now showing in the Order Activity notes area.

https://app.screencast.com/ppR7ryQYl5mbT

Let me know if you need anything else.

I’ve been testing out the patch and things seem to be working now.

Hey beeky2….

It’s definitely happening on the back end. I’ll have to watch the front end to see if it is happening as I spend most of my time in the back end.

Thanks Scott! I’ve been testing it and so far things look good ??

I just had to toggle save on/off the sanitizing flag to get it to apply. So far I have tested it with the wysisyg and text field types.

Thanks so much for this fix!

Thanks Paul and Scott. I was able to get things functioning by using the filter in the referenced instructions “add_filter( ‘pods_field_maybe_sanitize_output’, ‘__return_false’ );” I elected to use the global filter to save time and get the production sites functioning again in the least amount of time.

Seems like the same issue exists on other custom field plugins and I didn’t see anything in their settings to turn off the sanitization (thought they may have a filter that could be applied.)

So now just need to go through all the sites and update them with this filter override and all should be good.

Thanks Paul.

I’ve been pounding away on this stripping issue trying to narrow down the cause / fix.

This doesn’t seem to be PODS specific. For example, I disabled PODS and installed the Custom Post Types plugin. Then I enabled the wysiwig on a custom field. Script and iframe put into that custom field from the text tab of the editor also gets the tags striped out.

But what’s interesting is that if I remove the custom field definition from PODS/Custom Post Types, but enable the WP custom fields metabox, I can then enter the tags directly into the custom fields metabox and they don’t get striped out.

In addition, I CAN enter the tags into the text tab of the WP Post Content editor and it works fine.

So entering tags into the wysiwyg post content editor works fine, but entering tags into the wysiwyg custom field editor has the tags striped.

… it’s only affecting custom fields.

… it’s broader than PODS as I’ve replicated the issue on three different custom field plugins.

… this appears to need a global fix at either the custom field level or the TinyMCE level.

This is beyond me. I have tried adding functions to enable TinyMCE extended tag types, but nothing seems to work.

This is certainly beyond me and I’m not sure where to go at this point.

Thanks… got it to work. The problem was that I missed the “Post Title” field at the top of the settings dialog. That apparently is what was referred to as “label” in the error message. So I added a Post Title and it seems to be working better.

Hmmm… but I did select the “assignments”. Look in my screenshot and you can see I selected “Topics”.

Also, the error message says that label is required. However, there isn’t anywhere in the UI to put in a label that I can see (also shown in the screenshot.)