Mark Woodard

@jdrucza

The function is still disabled by default, but we ac walked back the setting about a week ago. So that’s why you don’t see it.

There is still a filter to enable the fix if you want to. It’s kadence_blocks_fix_svg_dimensions

Mark

Okay, two things.

First, beyond what were doing to check allow_url_fopen it becomes pretty vague what different configurations do and don’t support so It’s difficult for us to make checks for all cases. For whatever reason some configurations just don’t support what simplexml_load_file wants to do. I was hoping to find a solution that would filter out cases like the ones in this thread, but I don’t think that’s viable.

Second, When we added this patch we were really expecting it to only trigger for a very small portion of users. Which is why we enabled it by default as it was helping for those small number of cases.

With that as context:
I’ve updated our fix_wp_get_attachment_image_svg function to be optional behind a setting found in the Kadence Blocks settings page (off by default). You can filter it too with kadence_blocks_fix_svg_dimensions

This will keep the fix available for those who are finding that their svg’s have no height (don’t appear on the page in some blocks, like icon block). but won’t inadvertently affect users like yourselves.

Keep a look out for this in the next Kadence Blocks release.

Mark

Alan,

Okay, another report had it as just a warning so I assumed. I’ll need to look more into the fatal.

Was what you posted originally the full error log message? Was there any more to it, any other errors or warnings at the same time?

simplexml_load_file(//localhost:3000/wp-content/uploads/2023/07/name-of-asset.svg): Failed to open stream: Connection refused

In any case, we’ll try and pin this down and will let you know.

Mark

Alan,

This is Mark with the Kadence dev team. First, thanks for bringing this to our attention.

The warning doesn’t indicate a real problem (as long as your svg is loading and displaying properly that is). This function is just to fix some width / height attributes missing and that only matters in some edge cases anyway. In the case of this warning the function falls back to leaving the image the way it found it. Everything moves on.

Since this is just a warning and the case where the file can’t load is already caught by our code we decided to suppress the warning.

That update will be in the next release, I can’t say when that will be, but keep an eye out.

Worth noting that switching to the image return format might be a good option with your configuration then. Since not getting that warning probably means it’s providing width/height attributes that way. They can be nice to have. (but again, doesn’t matter in a lot of cases)

If you have any questions, just let us know.

Mark

@rilwis

Thanks for the pointer!
I’ll give that a try and let you know if that works out for my case.

Mark

@cristiano,

From what I can see we only put the ‘vcard’ class (the class indicating hCard micro data) on the author tags our theme outputs. I don’t see why recipe’s schema would conflict with that. So I don’t think that’s the issue, but please correct me me if I’m off there.

As far as hAtom data, we do add hfeed class to pages to help tag posts and stuff. From my testing on a standard posts page the tagging appears correct
https://monosnap.com/file/Gq0D3PDUgEbIV2MwIAFTO9KioV5jrL
https://monosnap.com/file/B0l2q60rn0Nab5EghoPLWHaSKJcnDe

Could you provide a screenshot or more details of the error the validator is giving you?
Even better, If your site is live somewhere that we can access it, please post a link to a page with the issue.
Is it only on your recipe archive pages or the singular recipe pages as well?

I need to see your error to figure out what’s wrong. From what I can see our hAtom and hCard implementations look correct.

Mark

Also what plugin are you using that adds the required hcard schema? Yoast or one of its extensions?

Mark

Christiano,

That filter is probably not what you’re looking for in this case.

Can you give me some more details on where you’re seeing the microdata? Like which elements or pages is it on that you want to remove them from.

Are you using a specific tool to test the data structure compliance or just inspecting in your browser?

Mark

@creatomatic

Thanks for the info. We’re going to put this on on our list to test and improve.

Hopefully we can find a good way to reduce the overall number of requests via the gallery block.

Mark

@creatomatic,

Can you give us a sense of how many gallery blocks / images you have when you begin to see this behavior?

If you don’t mind saying, knowing your hosting environment might help with testing as well.

Lastly, this is mainly an issue with the editor correct? You’re not getting failed page loads on the frontend?

Mark

@mikeydev

Just wanted to let you know that this issue should be fixed as of blocks 3.0.39.

Mark

@tarkham I think I see what you’re saying.

We updated some elements of this in blocks 3.0.40. I think we’ll be all the way there in 3.0.41 (next release).

3.0.40 has the tab role on the <a> elements like you suggested.
(with the tab index only being 0 for the active tab, not inactive tabs. For better tabbing flow into the active tab content)
But doesn’t have role presentation on the <li> elements. That should be in 3.0.41.

I used the axe dev tools for testing and saw some of the errors you were mentioning before. With these updates it looks like we’ve resolved them.

https://monosnap.com/file/fLaEOfbFujEljeZxXATZPOAJNxb63c

@tarkham

Sorry to hear the update didn’t help. I’m going to focus on your most recent comment because I think the earlier comment was made before this accessibility update came out in blocks 3.0.38.

I read what you’re saying about the anchor tags, but I’m not seeing the issue in my tests.

https://monosnap.com/file/Lc5sDBJNDVnn3VFJ3TPbB7RTQxvT5r

https://monosnap.com/file/5Z1Q0SzkmEhlcuKrtqXBERsZSIbWpC

I don’t use screen readers often so maybe I’m missing something here.

Can you please send us some more information on what screen reader you’re seeing issues in. When you say the tab panel is unusable by screen readers, what is the screen reader showing/reading as it tries to read the tab panel? A video of what you’re seeing would help a lot.

Mark

@tarkham,

This is Mark with the Kadence development team.

It’s been a minute, but I wanted to say that we’ve got some updates to the aria roles for the tabs block coming in the next update (release date pending). Including what you recommended about tablist and tab roles.

We did not add the setsize or posinset attributes as those are only required when the full data set is not present in the dom, which is not the case with tabs. With the changes to roles screen readers should now be able to appropriately find the size of the set.

Thanks for the feedback,
Mark

Nate,

I think I see the problem.

Try using the “kadence_woocommerce_email_previews” filter instead.

It expects you to add an array to it’s array.
The array you add should look like this:

array(
    'email_type' => 'email_example_slug',
    'email_name' => 'Email Example',
    'email_heading' => __( 'Placeholder for Heading', 'plugin' ),
);

Supplying values for this filter automatically hooks things into the “kadence_woomail_email_types” filter you were using before and others which I think are all important to making third party emails load correctly.

Disclaimer: I have not tested this myself yet, so try it out and see if that works for you.

Mark