gileli121

@doublezed2

I tested again. I have 9.4.2 installed and it still not working right without the workaround

OK, so after checking more, need to add these styles to theme style file.
I copy these classes from 9.3.3

.woocommerce:where(body:not(.woocommerce-block-theme-has-button-styles)) #respond input#submit, .woocommerce:where(body:not(.woocommerce-block-theme-has-button-styles)) a.button, .woocommerce:where(body:not(.woocommerce-block-theme-has-button-styles)) button.button, .woocommerce:where(body:not(.woocommerce-block-theme-has-button-styles)) input.button, :where(body:not(.woocommerce-block-theme-has-button-styles)) .woocommerce #respond input#submit, :where(body:not(.woocommerce-block-theme-has-button-styles)) .woocommerce a.button, :where(body:not(.woocommerce-block-theme-has-button-styles)) .woocommerce button.button, :where(body:not(.woocommerce-block-theme-has-button-styles)) .woocommerce input.button {
    font-size: 100%;
    margin: 0;
    line-height: 1;
    cursor: pointer;
    position: relative;
    text-decoration: none;
    overflow: visible;
    padding: .618em 1em;
    font-weight: 700;
    border-radius: 3px;
    left: auto;
    color: #515151;
    background-color: #e9e6ed;
    border: 0;
    display: inline-block;
    background-image: none;
    box-shadow: none;
    text-shadow: none
}


.woocommerce:where(body:not(.woocommerce-block-theme-has-button-styles)) #respond input#submit.alt, .woocommerce:where(body:not(.woocommerce-block-theme-has-button-styles)) a.button.alt, .woocommerce:where(body:not(.woocommerce-block-theme-has-button-styles)) button.button.alt, .woocommerce:where(body:not(.woocommerce-block-theme-has-button-styles)) input.button.alt, :where(body:not(.woocommerce-block-theme-has-button-styles)) .woocommerce #respond input#submit.alt, :where(body:not(.woocommerce-block-theme-has-button-styles)) .woocommerce a.button.alt, :where(body:not(.woocommerce-block-theme-has-button-styles)) .woocommerce button.button.alt, :where(body:not(.woocommerce-block-theme-has-button-styles)) .woocommerce input.button.alt {
    background-color: #7f54b3;
    color: #fff;
    -webkit-font-smoothing: antialiased
}

There are the specific styles that need to add to make it work.
I isolated it to these classes.

The question is if it is a workaround or a final solution.
Is this change in WooCommerce is considered as a bug?

Reverting to version 9.3.3 does indeed resolve the problem.

However, the styles that @frykky suggested aren’t an exact match, as the buttons still do not appear exactly as they did before. I’m now working on pinpointing the exact style code that needs to be added to fully restore the previous appearance.

But it currently something that I do as workaround. I expect it to be fixed

@beautyofcode

I maintain my theme, and you mentioned that there might be a style conflict with it. To rule this out, I removed all the content from the main theme style file (style.css) located in the theme folder. However, even after completely removing the theme’s styles, I still encountered the same issue.

Interestingly, when I added the styles that @frykky posted to this file, the issue was resolved. This suggests that @frykky faced the same problem, as adding the provided code also fixed it for them.

That being said, this is merely a workaround, and a proper fix should be implemented on your end.

I found example how the buttons should look. this is how it looks before:

https://ibb.co/5BxrFcN

Hello, I also experience this problem and noticed that someone has finally reported it.

Additionally, this bug is accompanied by a styling issue.
Please see this screenshot; I’ve included an explanation within the image highlighting what is wrong. Unfortunately, I don’t have a screenshot showing the correct display, but I hope you understand.

https://ibb.co/BNrV50Z

I opened issue about it here: Style of product page broke | www.ads-software.com

Please help also with this problem.
Thanks

• This reply was modified 1 week ago by gileli121.
• This reply was modified 1 week ago by gileli121.

Thank you, but the amount of effort I invested into integration is too much.
I implemented my own code without automatic renewal.

I don’t like that you don’t allow trial by default and do not allow the use of the proper auto-renewal implementation. I don’t know why you even implement something that is wrong design (it works, but in the WRONG way that renewal is done from the WordPress scheduler, and there is no proper protection for recharge risks that could happen, for example, after restoring from backup, etc…) . It may be a way to cause people to pay for the proper implementation. but you could offer a trial instead.

Maybe in the future, I will reconsider.
Thanks.

I see and get what you are doing here.

Anyway, I think will give it a try.
Is there a way to get trial for it?

I first need to test integration between this plugin few additional configurations that I have (using woocommerce hooks)

What is the vaulting?feature?

I noticed that WPS PayPal Payments also works fine and in its code, it does not care about this BILLINGAGREEMENTACCEPTEDSTATUS.

So I assume that it is a solution

But I have concern about how the whole subscription plugin works.
I don’t like that the code is the one that charge money.
It is possible for such system to charge multiple times due to a bug…
It could be much better if this was controlled by PayPal and not by the code…

I can’t take responsibility on it.

I figured it out while debugging this issue myself.
The question is, why is there no kind of error handling here?

Even a simple message like telling the user about this BILLINGAGREEMENTACCEPTEDSTATUS thing.
Not even a log was printed.

And where can the customer configure it so that PayPal will return 1 in this property?
I could not find information on how to do it when I searched for it.

Debugging it and figuring out the issue was very tricky because I needed a PayPal account with this issue and I don’t have such account. So, I had to use the ngrok service to expose a replica of my store in my localhost:8080 (where breakpoints are possible) to the person with PayPal. Then, he reproduced it on my machine.
I want to learn how to reproduce it with my PayPal sandbox account instead of having to do this again.

Thanks for your help.

• This reply was modified 3 months, 1 week ago by gileli121.
• This reply was modified 3 months, 1 week ago by gileli121.

Here are the errors:

https://ibb.co/tP7PRRk

After debugging your code, I found out that the problem was because the PayPal credentials that used did not match the PayPal email address.

After fixing it, the problem fixed.

So it is my mistake.

But maybe good idea to add a better error message. this can help to people without coding/reverse engineering skills

• This reply was modified 10 months, 1 week ago by gileli121.

Hello, I am getting the exact same error.
When I click on Proceed to PayPal, it shows PayPal error page with message:
“Something doesn’t look right. Your payment to this merchant can’t be completed using PayPal. Choose another way to pay.”

And the url in my case is exactly like this (“INVALID_BUSINESS_ERROR”)

I am testing in sandbox mode on localhost.

woocommerce version just updated to 8.4.0

Please help.
Thanks

I found a way to workaround it outside.

This is bad workaround but as long as it is from outside then I can live with it.. but please fix it.

My workaround to trick it was to add this to my custom page template:

<?php
/*
 *
 * Template Name: Brizy Product Page
 *
 */

// Workaround for https://www.ads-software.com/support/?post_type=topic&p=17010000
global $product;
$product = 1078;

....
....

Because your method get_queried_product_id is written, it will not override the value $product because it has a condition to set it only when it is undefined. So, my workaround was to define it to 1078 outside. I could do it even from the header file but to make it more isolated, I did it from the custom page template that I use only for the product page (that was made with the brizy page builder plugin and there I put the shortcode)