The-seo-framework: Sitemap.xls and custom site_icon_meta_tags

Created on 21 Sep 2018 · 19Comments · Source: sybrew/the-seo-framework

Hi!

I use custom site icon meta tags through a filter:

function site_icon_tags()
{
    return array(
        '<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png?v=20180306">',
        '<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png?v=20180306">',
        '<link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png?v=20180306">',
        '<link rel="manifest" href="/site.webmanifest?v=20180306">',
        '<link rel="mask-icon" href="/safari-pinned-tab.svg?v=20180306" color="#0f3341">',
        '<link rel="shortcut icon" href="/favicon.ico?v=20180306">',
        '<meta name="msapplication-TileColor" content="#0f3341">',
        '<meta name="theme-color" content="#0f3341">',
    );
}
\add_filter('site_icon_meta_tags', __NAMESPACE__ . '\\site_icon_tags');

And I get style errors for the sitemap. White page of sitemap. Console errors 'Opening and ending tag mismatch' for sitemap.xsl.

It was unexpected to meet my html5 tags in the xml file. Now I've closed the tags in my code snippet, but it's not entirely clear what to do with this in the future

[Type] Bug

Source

vralle

All 19 comments

From https://www.w3schools.com/tags/tag_link.asp:

Differences Between HTML and XHTML

In HTML the tag has no end tag.

In XHTML the tag must be properly closed.

The general consensus is to make code strict (XHTML) in plugins.
However, I do understand that portability mustn't (and aren't always to) be considered when users are adding targeted adjustments.

I'll see if I can filter the tags with some regex to make them behave strictly. This includes attribute quoting.

sybrew on 23 Sep 2018

We'll fix this in a future update. It takes too long to test for the upcoming patch.

With this fix, we're going to assume that all items in the filter are meta elements without content.

Here's what I got for grabbing the closing tags:

/<[^>]+?(\/?>)/

Here's what I got for strict attribute quoting, it's slow because we can't repeat-capture nested groups:

/<[^>]+?\/?>/                 # Grab tags first
/(\w+=([^"']+?)(\s|(\/?>)))/  # Grab unquoted elements for each of the tags...

sybrew on 23 Sep 2018

<[^>]+?(\/?>)

8 matches, 1622 steps (~7ms)

other way: https://regex101.com/r/zgKJUw/1

8 matches, 186 steps (~1ms)

my favorite bullet-proof)
You can use \w+ instead link|meta : https://regex101.com/r/zgKJUw/2

8 matches, 160 steps (~0ms)

vralle on 23 Sep 2018

By just removing the ? makes this the fastest one, with just 56 steps in your example:

<[^>]+(\/?>)

sybrew on 23 Sep 2018

<[^>]+(\/?>)
See what happens if the tag is closed

vralle on 23 Sep 2018

😕1

Ah, yes, it doesn't grab the closing solidus.

sybrew on 23 Sep 2018

Keep in mind that we can't filter the outcome of the function without using output buffering (it introduces code smell).

So, we're going to loop over the array. Whatever's faster over a single meta-tag line will be used. Keep maintainability and readability of the code in mind, too.

8 steps on a single line (112 over all those lines):

/<[^\/>]+(?:\/?[^>\/]++)*?(\/?>)/

Thanks for your input, it helped me get to that 😃

sybrew on 23 Sep 2018

If you want to find the ending of the tag, here: https://regex101.com/r/zgKJUw/3
but this does not solve the issue with quotes of attribute values.
Parsing tags is not an easy task. My search for universal code led to the following:
first look for the contents of the tags, like here: https://regex101.com/r/zgKJUw/2
So we get the tag name and attributes. Attributes can be parsed using Wordpress. Look at how work shortcode_parse_atts andwp_kses_hair.

You can simplify the processing, but in this case, we must understand that we will encounter a dirty code. Obviously, we can not be responsible for the dirty code. But you need to choose between a simple and fast code and a handler that will work even with dirty code.

vralle on 23 Sep 2018

I don't think it's necessary to scrutinize and repair every single line. If it's invalid HTML that isn't supposed to be in the <head> tag nor in that meta-tag-only filter, then it's invalid by default and we can't-nor won't-fix that.

We'll only want to convert HTML to XHTML, whatever purpose the tag has.

sybrew on 23 Sep 2018

The easiest way is to notify users through the interface "the icon tags should be compatible with XHTML Strict, otherwise it will lead to style errors and a white window."
There is always an option to abandon the use of site map styles. I have not seen websites for a long time where this is used by the clients of web resources

vralle on 23 Sep 2018

Another way is to remove site_icon_meta_tags filter before output styles and turn filter on after

vralle on 23 Sep 2018

It's using a WordPress Core function for consistency. Turning off the filters or adding an option for the off-chance that someone adds non-XHTML code is too much of a chore for both developers and users alike.

Let's just make it work as intended 👍

sybrew on 24 Sep 2018

Simply looking end of tags https://regex101.com/r/zgKJUw/4
And fail, if unexpected tag.

More: https://stackoverflow.com/a/3524392/2227392

vralle on 24 Sep 2018

https://regex101.com/r/zgKJUw/5
This regex finds the whole tag and its parts - the name, attributes, and content, if any. In this version, we can make the tags as needed.
No other ideas as to provide for any scenario

vralle on 24 Sep 2018

👍1

Brilliant, thanks! That'll help with edge case scenarios too 👍

sybrew on 24 Sep 2018

in the case of using regex, a rational option may be where the wait for link and meta tags.
In this case, the handler will be simpler: https://regex101.com/r/zgKJUw/7
And the comment in the UI, for example, "Only link and meta tags are allowed."

vralle on 24 Sep 2018

There are more restrictions set in XHTML, like only having lowercase elements and attributes names.

For balancing tags, we should use WordPress' force_balance_tags(). This will also close the single tags that should be closed. I think it also lowercases elements.

Alas, this doesn't strictly quote attributes nor lowercase the attribute names.
wp_kses_attr() could help us with this, whilst providing valid XHTML tags and their attributes (aka $allowed_protocols).

Why reinvent the wheel? 😄

sybrew on 8 Oct 2018

👍1

I wasn't able to fix attribute minimization due to time constraints. I must move on to TSF 3.2 ASAP for Gutenberg.

Nevertheless, attribute minimization shouldn't be used in any context regarding meta tags anyway, which is why I feel save introducing the following commit.

It should prevent errors showing in the XSL file when filtering site_icon_meta_tags.

sybrew on 9 Oct 2018

👍1

Now work perfect. Thanks!

vralle on 10 Oct 2018

Was this page helpful?

0 / 5 - 0 ratings