Ervin Domonkos

Hi @soliloquysupport,

Thanks for getting back to me.

Since then we removed the plugin, so I can’t replicate it now, but as far as I remember, it was a subscriber user.

Thanks,
Ervin

Hi Nikita,

Thank you so much for taking care about this. You really walked the extra mile with it by describing the issue for the Gutenberg devs.

Hopefully they’ll fix it very soon. Yep, it doesn’t break the site, so it’s okay for now.

Thanks for the instructions, @devnihil.

Actually I don’t want to turn logs off as I am actively developing sites/plugins where I need to see the logs during the process.

I am usually aiming for zero warnings in them, but I know it’s not always possible…

I know most of them are not harmful at all, but it would be nice if the amount of them could be reduced, so that it would be easier to debug other components.

Hi Peter,

Thank you for showing me this possibility. I think this feature is really valuable if we have to allowlist URLs in the future without the hassle of finding out manually what parameters to use.

Unfortunately, the event didn’t show up in the Live Traffic table. In the meantime, our hosting provider told us that they had XSS hardening set up on the server level, so that we were safe to turn it off in WF.

So the issue seems to be fixed for now. Anyway, I really like this feature of adding rules to the allowlist with a click of a button.

Thanks,
Ervin

Hi nK,

Thank you for taking care of this issue.

Strange that you couldn’t replicate it. Maybe it is related to our server settings, too? (however, the issue comes up only when WordFence is active)

Btw. as a workaround we can edit/save that page by turning WordFence temporarily off.

Thanks,
Ervin

Hi nK,

I deactivated the other plugins one-by-one and turned out that there’s indeed a conflict with the WordFence Security plugin.

If it’s turned off, saving happens correctly.

Regards,
Ervin

Hi nK,

Thanks for taking care of that!

Ervin

An extra info that can help here: the “Form” block type is switched off on our install because of other compatibility issues.

So looks like an inactive block type is generating these warnings.

I think the problem is with the eval() call inside it.

However it might be difficult to substitute it with something else in many cases (removing it would reduce the flexibility of usage significantly).

Hi Mihai,

Thanks for the quick answer. Yes, the issues were after Checkout submission.

Looking forward to see the next version then.

Thanks,
Ervin

Great, thanks!

Thanks for the quick answer.

Is there a way to make them displayed in the loop, too?

Thank you for the fast response!

That’s great news!

Thanks for your answer, @otto42.

Well, switching back and forth between block visual/HTML mode wasn’t the best experience for me.

I just wanted to add an ID attribute to a Cover Image element (as it can be used as a separator and I wanted to add some in-page navigation based on IDs), but after doing it in HTML mode I wasn’t able to switch back to the visual mode.

Using simply the HTML block is not an option, as my client – who doesn’t know HTML – will want to modify the background element and the text on the cover image occasionally.

And there was another thing with the cover image element: that despite it’s visually big, it uses P element for the text. For the sake of SEO it would be much better if we could choose H1..H6 headings here.

Sorry.

OK, here is an excerpt of my longer review:

Positive side:
– Look and feel of the new editor
– Page building tools (like columns, cover images)
– Clean markup

Negative side:
– Lack of the ability to add ID attribute to most of the blocks
– No 1-column version of the columns element and last column is deleted when switching to a lower number of cols
– Sometimes it’s hard to position the mouse in a way to make some items active in the editor
– Switching back between HTML and Visual editing doesn’t work if I make some small changes to the HTML markup of a block.