frzsombor

Fixed in 5.2.11 (Date: February 10, 2025)

Hi @yingscarlett,

Thanks for your reply, I understand.

However, just for future reference, in the meantime, I was able to verify that this issue seems like fixed in v2.0 Beta! I have also verified that the issue was using :where(.editor-styles-wrapper) .my-global-style-class in v1, but in v2 the style is defined as .editor-styles-wrapper .my-global-style-class, which has higher priority than the other styles.

Marking as “resolved” for now.

Hi @rainbowgeek,

Sorry for the extremely late reply!

I was able to confirm that this issue still exists if I’m using the default WordPress theme and only SEOPress plugin is enabled. I have created a short screen recording for you to demonstrate the issue. Please check it out: https://youtu.be/u5AvvJNrNpI

Hi @wfpeter,

Thank you for your reply and for providing additional context.

I completely understand your perspective too. To provide more details about our use case, we develop, host, and maintain WordPress websites for our clients. Only we have accounts with the Administrator role, while our clients are assigned Editor-level accounts. In most cases, no other users will ever register as WordPress users on these sites – and we guess that most websites operate like this nowadays.

Fortunately, most of the vulnerabilities detected by Wordfence scans involve authenticated users (Contributor or higher), which are considered “low-risk” (or even “no-risk“) for us. This is because we do not anticipate our clients attempting to compromise their own websites. That said, we also recognize that even minor vulnerabilities can be deemed critical under different circumstances.

Given this, I would only expect a non-breaking or backwards-compatible change, such as adding a checkbox for aligning scan result severity with CVSS, which could be disabled by default to maintain the current behavior. Alternatively, any other similar approach would be greatly appreciated.

Thanks again for forwarding this suggestion to your team,
and for the fantastic work you do on this essential plugin!

Best regards,
Zsombor

Hello,

Thank you for your help!
We hope to see a fix soon, as currently, because of this huge UX issue, developers using this plugin can not activate the reCaptcha while using advanced validation. We can not expect the end users to figure out that the sill checked reCaptcha becomes invalid if advanced validation fails, and also wait 1 minute to be able to check again after the automatic, frontend reCaptcha invalidation.

I think the problem lies in the fact that on the backend, you validate the reCaptcha before checking the advanced validation settings and a solution could be as simple as switching order and checking advanced validation first and if everything is valid, only proceed with the reCaptcha validation.

Hi @amimulihsanmahdi,

Thanks for your reply! I’m fully aware of the behavior that you are showing in the screencast, it is called recaptcha invalidation/expiration time. The problem I’m having is what happens if you DON’T wait 1 minute for the recaptcha to become expired, but try to resubmit the form instantly after fixing the advanced verification error and with the recaptcha ALREADY checked. That time the user will get a recaptcha error, and has to wait for the recaptcha to expire (as shown in your video).

Thank you for your help! In my case, this is the best approach.

Thank you @missveronicatv for the quick answer!
This is definitely something I can start working with.

However I really think this should be included in the core (even as a simple filter or with an option to define a constant) for those who are building a website using a professionally managed child theme, not just using it to drop in some functions.

Is there a good way to submit this as a feature request for the developers?

Hi, thanks for your replies.

Unfortunately, the problem is that I’m already using a custom child theme, that has it’s own built in version management / update functions, and I can not update the child theme without losing the templates.

Thanks Tom, keep up the awesome work!

Hi Benjamin,

Thanks for your reply!

I was trying to tell that the problem is not that the screenshots are not updated on the docs, but that even if they are out of date – according to the current UI – they are still the valid logics behind the functioning of the current version.

I have not pasted the URL for the default images into the input fields but actually used the “Upload an Image” button to pick the default image from the Media Library. Yet, SEOPress still uses the first image from each page for the default twitter:image meta – as it is correctly shown on the image in the docs – and not using my default image as it should, according to the “We generate the twitter:image meta in this order” section on the settings page.

Also for Facebook, if I not force FB og:image with the “Apply this image to all your og:image tag” checkbox, it also uses the first image from a page and this step is also missing from the “We generate the og:image meta in this order” section. And – according to the actual functioning – the image in the docs IS the correct order, not what is currently displayed in the settings UI.

Dear Ying and Tom,

Now I apologize for the late reply, and thank you both for your responses!

So really, truly, you didn’t delete my message. I found it so strange that I finally convinced myself, even before your response, that it must have been some moderator error.

I fully understand that you don’t have time to deal with GitHub alongside such serious background work related to the 2.0 release.

In the past few weeks, I have seen 1-2 issues/PRs being processed, and I will continue to actively contribute to the projects in the future. But for now, I am really looking forward to the 2.0 release, and until then, I won’t send any minor feature requests, as they might already be included in 2.0.

I know it’s the hardest question, but is there a rough public ETA for the release?

Thanks for your reply!

Sorry, I was not aware of that setting as it says “Enable blocks spacing: Vertical spacing between blocks” and I wasn’t thinking that enabling block spacing will remove the added spacing. ??

I tried enabling this setting and the bottom margin actually disappeared, however, the top margin is still there as this is now the CSS I see in block editor on all blocks:

.editor-styles-wrapper [data-block] {    /* this is added inline now */
    margin-bottom: 0px !important;
}
.editor-styles-wrapper [data-block] {     /* this is still coming from blocks.css */
    margin-top: 12px;
    margin-bottom: 12px;
}

Notes: I’ve tested this in a test environment, where I’m not using any other plugins or custom themes, and this is a brand new, clean install of PublishPress Blocks.

Edit: accidentally marked as resolved.

Szerk.: Valóban, úgy oldották meg a legújabb API-ban, hogy a kapott response header kulcsokat kisbet?sre konvertálják és onnantól kisbet?sként is kezelik.

Ja értelek, igen. Egyébként ez számomra is nagyon furcsa megoldás. Egy elvileg “breaking change”, 1 hónapos “türelmi id?vel”, amit ráadásul egy kattintással átállítanak, tehát most még FIXEN(?) csak a régi módszerrel m?k?dik, majd május 10-én egyik pillanatról a másikra kizárólag az új módszerrel fog, ugyan az az endpoint? Nem valami konvencionális elképzelés és megoldás.