Nick the Geek

@abzlevelup, I appreciate that. I’m wondering if it might be possible to get a filter that allows disabling this filter or update the add_filter to use a static callback in the interim. The issue is that the temporary solution of commenting out this line of code means we have to apply it every time the plugin is updated. If I could just remove_filter() or other wise disable this line of code from outside the plugin then we would be able to apply updates and just wait to see if it is fixed.

Hey all,

I ran into this with a client after we updated to PHP8 on WordPress VIP. Unfortunately this is going to be a bigger issue for clients on that platform as they are enforcing PHP8 starting next month.

I commented out the filter and it is “working” again but I’m not sure what else is affected by this.

I tested by updating to v6.0.2 before commenting the code, but that did not resolve the issue.

Looking forward to a solution.

thanks!

Thanks! I suspect this is a bug and filed a bug in Gutenberg repo about this. I included the screen recording you made and link to this ticket.

I hope to get it resolved quickly in Gutenberg. Until then, my recommendation is to use the work around of typing the text, selecting, and choosing the text format.

Thanks for asking! I’m sorry but this plugin only adds a text format control to the WordPress block editor. It doesn’t work with Beaver Builder.

All is not lost. Beaver Builder does have their own controls to improve accessibility. I have not used the plugin in a few years, so unfortunately I can’t point you to a 1:1 alternative if it exists, but you might contact Beaver Builder support about potential to set aria-labels or screen reader only text in the various modules.

@westonruter ah, that appears to be the issue.

I removed the tag and the script is being injected now. I’m assuming that when the tag is stripped something in the dom navigation is failing to identify that there is a valid <form> tag so the amp-form custom element script does not get inserted.

This is working for me correctly now that I’ve removed the invalid script. It’s a bit confusing in the doc on this as usually the custom elements are indicating specific wrappers that have to be applied.

Not sure if y’all want to see why the cleaned up and corrected code was not triggering the custom element script.

Sorry, I have an NDA with this client. Can’t say who they are. ??

I did check the HTML just now. I was assuming <amp-form> was present, but it seems that is being stripped out. It is 100% in the code injecting the form though.

<amp-form>
	<form
		method="GET"
		id="a_string<?php echo esc_attr( $count ); ?>"
		class="a_string"
		action="https://example.com"
		target="_blank"
	>
<!-- Inputs -->
	</form>
</amp-form>

This is added as part of a filter on

add_filter( 'the_content', 'theme_string_insert_amp_form', 20 );

So a filter is stripping the <amp-form> element and the custom element script.

Thanks for the reply. It makes sense and I think is a good solution for a lot of implementations.

The problem is the amp-form script is not being added automatically either. The page definitely has the amp-form inserted. It might be that it is inserted *after* the check to see if it is there. Is there a way to bypass the nanny logic and let us do it the way we were? It was validating and working and not it is not.

@adriandemocracychroniclescom the beta is currently available for download. I’ve got a few things I’d like to do. The biggest is make it possible to switch back to the XHTML code for sites that have custom CSS supporting the XHTML.

@mclennan can you try that without the square brackets?

doug,

Can I get a screenshot for the current setting and the post meta that should be setup for this. I am unable to replicate so I’m not sure if maybe there is a configuration issue or something I don’t have setup the same as you that would break the usage.

Update on this, I’ve got beta 1 out for HTML5 support. It is available in GitHub.
https://github.com/NicktheGeek/genesis-featured-widget-amplified/releases/tag/v1.0.0-beta.1

@mclennan I think that may be a usage issue.

The field is for a custom meta field that is added to the post.

For example, you might add a value like gfwa-url to that field in the widget, then in the post editor add a custom field with the name gfwa-link and the value as the URL you wish the link to point to like https://example.com.

Then when that post shows up in that instance of the widget it will link elsewhere.

This is pretty handy because you can make different widgets link to different locations using different custom fields.

@lucashilty sorry to hear you are having trouble. The markup shouldn’t have changed but I did change the method I used to get the posts to use the better WP_Query method over get_posts that it was previously using.

My guess is this is causing issues.

That said, can I get some details about your widget settings so I can see if there is a reasonable fix for this?

I don’t want to go back to the old method but maybe there is a simple fix with settings or with some custom code you could add that will solve this.

The latest update should resolve this.

Ok sorry but it looks like the code I removed was added back by a different commit before I did the release. I will need to do another release to solve that.