hernan2022

It works! Thank you very much

I feel so embarrassed, I didn’t expect it to be so simple

But thank you very much for the help

Thanks for answering

I am attaching an example of a store under construction

Mini Bala Vibradora 7 Funciones – Mango Banana

The first color is out of stock, the second color has stock and the third color has no price (in the third scenario it is disabled correctly)

By default, as it appears in the plugin, the first color should also have the disabled class applied and appear non-selectable with a cross

From the tests I have done, I think it is a fairly general bug or problem or that it would be happening to many people

Thanks, regards

Thank you very much for your reply, I have actually thought about this myself and have decided to save emergency access codes. I have some ideas for forcing login in case I lose my smartphone (probably the easiest way is to delete the plugin via ftp) but it is an unnecessary complication or risk

It makes sense to have two ways to verify login, maybe the easiest thing would be to just tell the user that at least two verification modes are recommended or required. A simple notice in the settings should be enough

But in any case thanks for your reply, greetings

I understand,

Thank you very much for the information and analysis

It’s a shame that Firefox doesn’t do something so essential right. I have more than enough information to do tests and make decisions. I think I’m leaning towards leaving it as is, it makes sense that the litespeed plugin is betting on acting safe and prudent, even if there are few browsers that don’t support webp

Thank you very much, greetings!

I understand, can I do something? I have the impression that it worked before

Although I understand that the idea is for the browser to clarify this to the server. Can I understand this as a bug or problem with the browser and not a problem directly with the website or the plugin?

Regards

I found it ! It was a warning from the extension that allows block users

		            'title'     => __( 'About Blocked Members Comments Restriction!', 'youzify-block-members' ),
		            'msg'       => __( "it's not recommended to restrict users comments as that might affect the performance!", 'youzify-block-members' )

If I just want the blocked user to not be able to send messages or write comments on posts, taking care of the site’s performance, would it be best to disable messages and posts? (so that the blocked user simply does not see the posts)

Yes, I have entered the V3 credentials without any problems, the captcha logo appears. I’m just not 100% sure that it works

I was hoping that by logging in with Tor Browser and trying to auto-spam something would appear that would stop me. In my particular case I’m going to stick with V2 to be sure that I’m stopping or slowing down the potential attacker

I’m not sure if V3 was working in my case, maybe it was working fine and it wasn’t stopping me because in a sense, it was human spam. But since it’s possible to change the captcha language right now I’d rather stick with V2

Another thing I noticed is that by following the following tutorial:

Change reCaptcha Language on Register Form / KaineLabs (ticksy.com)

It loaded the captcha script everywhere, it’s a bit strange since one tends to think that bp-custom.php should be limited to buddypress. But with the anonymous function that returns ‘es’ it’s possible to change language without loading that JS everywhere

But in any case thanks

I was able to change the language of captcha V2! I was looking through the plugin code and had a filter already created, to leave it in Spanish I used the following code:

add_filter( 'youzify_captcha_language', function() {
return 'es';
});

You also had an article about this that I hadn’t seen before. It’s great to have this in the project language

Just if you could tell me about V3 maybe a way to test it. Although in this particular project it seems that there are many advantages to staying in V2, especially now that it is in Spanish

Youzify 3.5.4
BuddyPress 14.0.0

For now I just put this (around line 367) in class-youzify-profile.php

function open_graph() {
// Disable the function functionality
return false;
}

This does not print the Open Graph on the pages. This is a bug that surely happens to all those who have BuddyPress updated

Thanks for answering

I was able to fix it, the thing is that visually everything looked updated. But the authors of the “BP Follow” plugin forgot to put or increase the version number, this has already been fixed by them

I simply uninstalled BP Follow and reinstalled from GitHub. Surely that’s why not many people have reported the problem, it will only happen to those who update an old installation

Thank you very much, regards

I’m a little old, locally I noticed too many problems when updating buddypress/youzify (I understand that it is important for security and functionality, I will update as soon as I have more time)

• BuddyPress 11.4.0
• Youzify 3.3.9
• Youzify – BuddyPress Membership Restrictions 2.0.3

I tried to add verifications in the function itself but it didn’t work, but with the validations near the line I indicate the user is not redirected to the home when he posts in bbpress

Thank you very much, that sounds reasonable.

Thanks for the advice, I will evaluate advantages and disadvantages with some tests

Thanks for the response, regards

You’re right, the truth is everything seems fine, it must be something very specific with Firefox

When I free up some time I’m going to check with my theme support if they’ve seen something similar. Then directly to Mozilla as a bug report

But it seems like a very specific or circumstantial problem, in most cases it would be working fine

Thanks for reviewing it, greetings

Hello, am I the only one with iframe problems in Firefox incognito mode?

I have tried it several times and I think it is a consistent bug or problem