lichtsturz

Hi ramiltaboy,

do you have an ETA by Liquid Web, when either the card element is turned off or when the option is enabled that connected accounts can customize their payment method?

Thanks

Hi ramilbatoy,

we have already contacted Stripe on that matter. Currently, no user of your plugin can disable the LINK element.

Neither in the dashboard nor by custom code which is this one: https://docs.stripe.com/js/elements_object/create_element?type=card#elements_create-options-disableLink. We already tried with custom code according to the docs and it did not work.

Stripe has confirmed that your configuration (controlled by https://www.liquidweb.com/ which Stripe found out – which seems your parent company) will always override any setting of the Dashboard or custom code.

Stripe recommends that you set your API configuration link_in_card_element to ‘OFF’ so users can control whether to show LINK or not.

Alternatively, if you want to keep your API configuration for LINK element for unknown reasons, Stripe asks to please delegate settings control to connected accounts (Under the account customization setting, tick the option which says “Allow connected accounts to customize their own payment method from the dashboard.”

The current configuration and setting forces all users of your plugin to have the LINK element. Please note that only a fraction of users who pay with credit card / debit card use LINK and it is not a trusted element which helps in increasing conversion rates.

Stripe recommends to technical providers like you to give the payment element controls always to the publisher. This means that you allow connected accounts to customize their own payment settings. I’m not sure about the legal / liability part of this, as I’m just a technical person.

Kindly let me know whether you turned off link_in_card_element in your API configuration or whether you have activated “Allow connected accounts to customize their own payment method from the dashboard.” in your global settings.

Once done, we will test again, whether the LINK element can be finally disabled.

Thanks for your support.

Ok, we found it. This option must be enabled: https://i.imgur.com/QsC3TUY.png

We found it by hovering over the “i” that his cannot be disabled otherwise there is no e-mail going to the client.

Ticket solved. Thanks

Thanks for the quick reply

1. Do you mean SMTP in your plugin? There is only setting for incoming e-mail and this is done and working. Ticket creation via e-mail piping works. In case you mean setup SMTP in additional plugin like WP Mail SMTP please let me know. When we tested with WP Mail SMTP all tests from WP Mail SMTP are successful and delivered to the user. The main difference is that WP Mail SMTP uses SSL 465 Port (outgoing mails) whereas we could only define with your plugin SSL 993 (incoming mails) – Defining SSL port for outgoing mails was not possible. Even with WP Mail SMTP being active on top of your plugin – replies in the ticket system will not be delivered to the user. Auto-Reply when enabled works, though.
2. E-Mail logs are all fine when tested with WP Mail SMTP – we could not find any other E-Mail logging tool, which will check the actions of your plugin. When you have one, just let us know please.
3. The outgoing e-mail is defined. As said there are no settings like SSL Port 465 available there in your plugin. Both Auto-Email options are disabled as we want the user only to receive the agent reply.
   
   Thanks for your support.

Hi John,

I will follow up via e-mail.
Yes, exactly the error is not related to HMWP but this is the error which pops-up when HMWP gets activated in “Lite Mode” and Internal Server Error appears subsequently in frontend.

Will continue via e-mail.

Thx.

Hi John,

I got additional information. When accessing frontend itself and getting the 500 error I got this:

`Dec 2 06:18:27 dd12002 apache2[19786]: [core:error] [pid 19786:tid 140103074285312] [client 121.121.89.27:0] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use ‘LimitInternalRecursion’ to increase the limit if necessary. Use ‘LogLevel debug’ to get a backtrace., referer: https://xxx.com/

Also disabling Cloudflare did not make any difference.
All of this is working fine & correct: https://servebolt.com/help/article/how-to-fix-the-too-many-redirects-error-message/

Thank you

Hi John,

my hoster checked all settings and all are as needed from HideMyWP. We spend some more hours on this topic and monitoring real-time helped us to find the rootcause.

When HideMyWP Lite Mode is activated this error will show up in Debug Log:

[02-Dec-2021 05:17:43 UTC] PHP Deprecated: et_get_one_font_languages is deprecated since version 4.8 with no alternative available. in /www/htdocs/w0195fb6/booking.discovernauts.com/wp-includes/functions.php on line 4871

and cause Internal Server Error in Frontend.

Kindly help on this matter, because I have no clue why HideMyWP is causing this conflict when Lite Mode (changing paths) is activated.

Thank you.

Also just to inform you:

This error message:

[01-Dec-2021 03:12:05 UTC] PHP Notice: Undefined index: path in /www/htdocs/w0123479/xxx.com/wp-content/plugins/hide-my-wp/models/Files.php on line 162

I get in debug mode on a website where HideMyWP is working without problems. So we can exclude already anything related to this error.

Will check now with my hoster.

Hi John,

I will talk to my hoster support. Maybe they can explain why only 2 websites have a problem on the same (Apache) Server.

If they can solve it I will inform you – otherwise I come back to you.

Hi John,

thx for the advice. I will look into it but also can say that this is not the rootcause for the Internal Server Error which is causing the frontend to not work anymore.

There are 10 different websites running on the same server. Only for 2 website HideMyWP is causing problems, because these 2 website are using Divi.I stated this in the first post in the first sentence to find better the rootcause which I believe is not server-related when 8 other websites are running on the same server with HideMyWP.

The rootcause after long testing and analysis is apparently the Divi Theme (independent from version) in combination with HideMyWP
I would assume the advice would not help, since the htaccess is properly configured for all 10 websites and because the plugin is properly working on all 8 other websites on the same server.

Do you have any updates for the conflict Divi & HideMyWP?

Thank you

• This reply was modified 2 years, 12 months ago by lichtsturz.

Hi John, great.

Also I noticed in my debug another error, which might is not critical but gets detected by WordPress Debug mode.

[01-Dec-2021 03:12:05 UTC] PHP Notice: Undefined index: path in /www/htdocs/w0123479/xxx.com/wp-content/plugins/hide-my-wp/models/Files.php on line 162

Cheers

Hi John,

the problem is still present. Did you check Divi and Hide My WP?

Thx and regards
Tom

Hi John,

thx for sharing info regarding error log. That’s handled by my hoster and I think they want to have it that way. Not sure why activating the plugin is causing this.

Divi Theme Version is: 4.14.1

Hi John,

I have increased to 512M which did not solve the problem.
Since it must be a configuration issue of the website itself I could see that it is working with Default theme Twenty Twenty, but not with Divi which is running on this site.

Are there any known compatibility issues with Divi?

Hey John,

this is a pro feature which I cannot use, since I’m using the free version offered here.

View post on imgur.com

Any other idea to make the plugin work?

I have checked htaccess which has all correct entries as far as I can see. I can exclude server setting as rootcause, since I have 8 other websites on same server where the plugin is not causing any issue, because AllowOverride All is set.

Thx for follow-up.