-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Widgets - Show/Hide HTML block not working, settings not sticking #10
Comments
Hi, thanks for reporting this. You've taken me down some rabbit holes. The HTML block is a different kind of beast compared to most. I'll need a little more time to explore how it might be possible to add rules to this. Can you confirm you're running the most recent version of the plugin? (0.2.9) |
Yes, latest version of WordPress and your plugin.
I had thought wrapping the iframe or div in a table would help; but it
didn't.
Thanks
Warren
…On Thu, 26 Jan 2023, 1:29 pm Richard Tape, ***@***.***> wrote:
Hi, thanks for reporting this.
You've taken me down some rabbit holes. The HTML block is a different kind
of beast compared to most. I'll need a little more time to explore how it
might be possible to add rules to this.
Can you confirm you're running the most recent version of the plugin?
(0.2.9)
—
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A5O764N65EQ2CQWSTVXJRHDWUHVTPANCNFSM6AAAAAAUG4R6SM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
I dug a little deeper into this today and it's not great news I'm afraid. For the HTML Block (and, I discovered, a couple others including the shortcode block) WordPress core doesn't fire the same hook (technically the One thing I noticed is that the HTML block (and shortcode block) don't support the 'Advanced' Panel - i.e. where you would normally expect to see the field to add a custom CSS class. That's WP core doing that, so I suspect this is expected behaviour right now. I'll push an update which prevents folks from trying to add content visibility rules on these blocks (and stop the "why isn't this working?!" frustration), and update the documentation to reflect that. I don't have an answer right now as to how this might be solved, but I'll carry on digging, and pondering. Will leave this issue open in case any one sees it and can think of a way forward. |
Thanks for the feedback.
Just a thought, what if the block is text with inline code below the text
in the same block, or graphic with code below it?
…On Fri, 27 Jan 2023, 3:28 am Richard Tape, ***@***.***> wrote:
I dug a little deeper into this today and it's not great news I'm afraid.
For the HTML Block (and, I discovered, a couple others including the
shortcode block) WordPress core doesn't fire the same hook (technically the
blocks.getSaveContent.extraProps filter). I'm not 100% certain *why*
right now, but I suspect it's to do with the expectation that whatever is
output in these blocks can handle their own attributes/logic. So, at the
moment, this isn't really a bug in Content Visibility, but rather a missing
feature in WordPress. (Or it could be there's an alternative way this
should be handled, but I can't find it right now). There is definitely a
lack of documentation on my part tho, and I can help prevent user
frustration.
One thing I noticed is that the HTML block (and shortcode block) don't
support the 'Advanced' Panel - i.e. where you would normally expect to see
the field to add a custom CSS class. That's WP core doing that, so I
suspect this is expected behaviour right now.
I'll push an update which prevents folks from trying to add content
visibility rules on these blocks (and stop the "why isn't this working?!"
frustration), and update the documentation to reflect that.
I don't have an answer right now as to how this might be solved, but I'll
carry on digging, and pondering. Will leave this issue open in case any one
sees it and can think of a way forward.
—
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A5O764PRHZ4LQNKSU2OPVY3WUKX4TANCNFSM6AAAAAAUG4R6SM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
As long as the block you're using isn't the HTML, Shortcode, Legacy Widget, or "freeform" (the old 'classic') block then you should be good to go, I think. |
Thanks Richard, a test I did with entering a text widget and adding inline
code works well.
…On Fri, 27 Jan 2023 at 09:53, Richard Tape ***@***.***> wrote:
As long as the block you're using isn't the HTML, Shortcode, Legacy
Widget, or "freeform" (the old 'classic') block then you should be good to
go, I think.
—
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A5O764LRAS6KOELPK7DVJUTWUME7BANCNFSM6AAAAAAUG4R6SM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
That's such great news! Thanks for reporting that, Warren. That'll help out any future travellers coming here. That, I imagine, will also be true for shortcodes. I suspect if you put a shortcode in a paragraph block it should still work, and you can apply Content Visibility rules to the paragraph block. I'm going to leave this issue open if you don't mind, as I'm going to see if there's a neater way to handle this, or at least have something to point the issue on the main WP/Gutenberg projects repos. |
In Widgets I have a HTML block showing affiliate ads in a table.
![Screenshot 2023-01-26 092120](https://user-images.githubusercontent.com/123600753/214715411-2ba0461e-af0f-49f2-ab68-d081652d12a8.png)
I select the block and set Visibility rules to Show.
I select a Page to show the block.
I apply the settings and check.
The block shows on all pages throughout the site. The show/hide is not working.
Also, when I go to update a post and then come back to widgets, the settings for the block are lost.
I have test with visibility of just an image block and this works perfectly and the settings hold and the eye marker can be seen next to the image block.
The issue seems to be with a block of html text e.g. (edited so it displays the code)
table>tbody>tr>
td>xxxx/td>
/tr>/tbody>/table>
The text was updated successfully, but these errors were encountered: