nlpro

Hi @bennoi,

When I look at the German (de_DE) Solid Security plugin translation (here) I see that it is only 47% completed.

Then I checked some of the strings from your screenshot(s) that are missing a translation and saw these are indeed not yet translated.

So what you need to do is translate the Solid Security 2FA specific strings on translate.ww.wp.xz.cn and then ask a German translation editor to review your submitted translations.

+++ To prevent any confusion, I’m not SolidWP +++

@shanedelierrr,

That’s totally correct😉

It should be changed to the value as used for the same string in the Vietnamese WordPress translation:

Changing the Vietnamese Solid Security translation may take some time. So as a temporary workaround use the code snippet below:

add_filter( 'ngettext_better-wp-security', 'change_solsec_n_translation', 10, 5 );

function change_solsec_n_translation( $translation, $single, $plural, $number, $domain ) {
	if( $single === '%s item' && $plural === '%s items' ) {
		$translation = '%s mục';
	}

	return $translation;
}

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

Hi @poppydev,

Ok, so it seems we have now moved from a 2FA email only issue to a Solid Security email issue.

I updated some of my WordPress test envs to 6.9 and all emails are still being send (and received). In other words, I don’t seem to be able to reproduce the issue (in my hosting env).

So whatever email issue you have it must be specific for your hosting env(s).

I did my own research (to understand better the changes made in WordPress 6.9 related to sending emails) and then did some googling. Found a really interesting article which I think is worth reading:

WordPress doesn’t send emails after 6.9 update

Hi @unison123,

If you require no further assistance please mark this topic as ‘Resolved’.

Hi @sproutchris,

Alternatively try and reproduce the issue in Solid Security Basic. That way this topic is allowed to receive support here. However if the issue got introduced after updating to Pro 8.6.0, which was released last week, there is probably no point in testing the issue in the current Basic release. The current Pro/Basic releases are currently out of sync.

+++ To prevent any confusion, I’m not SolidWP +++

Hi @kurtnuimage,

It seems the woocommerce_process_login_errors is not an action but a filter. The code in your hooked callback (add_wc_process_login_errors) may not be correct.

Furthermore it seems you can also use the WordPress Core login_errors filter.

+++ To prevent any confusion, I’m not SolidWP +++

• This reply was modified 9 months, 3 weeks ago by nlpro.

Hi @marxveix,

Below an excerpt from the 6.3.0 Changelog:

Important: The way that Hide Backend functions changes in this release. Previously, if your Hide Backend Login Slug was wplogin, going to example.com/wplogin would result in the URL remaining example.com/wplogin. The new implementation of this feature results in a redirect to a URL that looks as follows: example.com/wp-login.php?itsec-hb-token=wplogin. While this may not be desireable for some users, this change was necessary to fix longstanding compatibility issues with other plugins. Once you access the login page using the Login Slug page, a cookie is set with an expiration time of one hour. As long as the cookie remains, you can access example.com/wp-login.php without having to access the Hide Backend Login Slug first. If you wish to confirm that Hide Backend is working properly on your site, opening up a private browsing window is a quick way to test without having to log out and clear cookies.

Hi @unison123,

It would be interesting to see whether the issue persists when (temporarily) disabling the plugin “Write to Files” setting. Verify afterwards there are no more Solid Security related rules in the (Apache) .htaccess file. Then retest the issue.

+++ To prevent any confusion, I’m not SolidWP +++