• Resolved Chris Rault

    (@connectr)


    Hi guys,

    We’re using the native AMP mode for the new version of the clients site (winefolly.com) and are aiming to launch tomorrow. I’ve been going through the built in Validation status page and have noticed a couple of issues:

    1.) Validation errors aren’t getting cleared when the listed issues have been resolved. One example of this was a post where the client had added the following code:

    [code]<abbr="American Viticultural Area">AVA</abbr>[/code]

    So I updated the code to be:

    [code]<abbr title="American Viticultural Area">AVA</abbr>[/code]

    I then saved the post and clicked the recheck button, expecting the post to be removed from the list, but alas the post remains.

    2.) The other issue I found is when a post does have an issue, a redirect to the dev url is automatically added to the Yoast redirects, resulting in the post 404’ing.

    3.) I’m using the redirect to page plugin for Contact Form 7 and despite the plugin working fine without JS, it’s still listed as incompatible. I also dequeued the front-end js, but it’s still getting listed as an incompatible source.

    4.) There doesn’t seem to be any distinction between global site errors and content specific errors. Most of the posts listed as having errors are complaining about the FB open graph attributes added to the html element.

    Other posts are listed as having <script> tags, but after digging through the post content, no script tags are present, so I can only assume this is referring to a site wide error.

    Despite the 26 odd posts which are listed in the validation list, most of the posts validate fine on the front-end.

    What is especially odd is that comparing two posts listed as invalid, the one post validates fine and another post doesn’t. Comparing the source of the two links, I can see the one that validate does not have the open-graph code, but the other which doesn’t validate does. This really doesn’t make sense why it’s being added in once instance and not in another.

    I’m happy to setup a temp admin login if someone from the AMP for WP project is willing to take a look.

    TIA,
    Chris

    The page I need help with: [log in to see the link]

Viewing 8 replies - 1 through 8 (of 8 total)
  • Plugin Author Weston Ruter

    (@westonruter)

    @connectr Thanks for reaching out. Could you ping me on WordPress Slack with admin credentials so I can take a look?

    Thread Starter Chris Rault

    (@connectr)

    @westonruter Thank so much for responding so quickly – especially being weekend and all!

    Firing up Slack now and will give you a ping.

    Plugin Author Weston Ruter

    (@westonruter)

    3.) I’m using the redirect to page plugin for Contact Form 7 and despite the plugin working fine without JS, it’s still listed as incompatible. I also dequeued the front-end js, but it’s still getting listed as an incompatible source.

    This is due to the plugin currently complaining when a script is enqueued even if it later gets dequeued. This is fixed currently in 1.0-alpha, but the way around it is to remove the underlying wp_enqueue_scripts action which was responsible for the first script enqueue to begin with.

    Plugin Author Weston Ruter

    (@westonruter)

    I see a lot of validation errors regarding invalid attributes http: and fb:. If I de-activate the AMP plugin, I can see that the underlying HTML being output is:

    <html lang="en-US" https://ogp_me/ns#="" fb:="" https://ogp_me/ns/fb#="" data-markup-id="beans_html">

    This clearly looks like an error.

    It should rather be:

    <head prefix="og: https://ogp.me/ns# fb: https://ogp.me/ns/fb#" data-markup-id="beans_html">

    The prefix attribute seems to not be getting output, and the quotes are missing. Maybe you’re not passing the Beans attributes array as:

    array( 'prefix' => 'og: https://ogp.me/ns# fb: https://ogp.me/ns/fb#' )

    Or maybe this is a Beans bug? /cc @tweetythierry

    • This reply was modified 6 years, 6 months ago by Weston Ruter.
    Plugin Author Weston Ruter

    (@westonruter)

    1.) Validation errors aren’t getting cleared when the listed issues have been resolved. One example of this was a post where the client had added the following code. […] I then saved the post and clicked the recheck button, expecting the post to be removed from the list, but alas the post remains.

    You’re right, this should be getting cleared. If you load the post on the frontend with ?amp_validate in the URL, you can see that there is no invalid_attribute validation error regarding <abbr viticultural="" area="">. I suggest moving the validation status post to trash for now, as somehow it seems the validation status post has been disconnected from its URL…

    4.) There doesn’t seem to be any distinction between global site errors and content specific errors. Most of the posts listed as having errors are complaining about the FB open graph attributes added to the html element.

    In regards to point 1 and point 4 here, the reality is that the “validation status” system in 0.7 is being completely refactored for 1.0. Instead of each unique combination of errors resulting in a separate validation status post, instead there will be invalid URL posts which consist of any number of validation error terms associated with them. You then will have the ability to suppress certain validation errors from being reported, and when you suppress it once then it will be suppressed across all URLs that report validation errors. Pull request: https://github.com/Automattic/amp-wp/pull/1093

    I also highly recommend you check out our Google I/O talk that dives into how this should look: https://youtu.be/a8NScvBhVnc

    Other posts are listed as having <script> tags, but after digging through the post content, no script tags are present, so I can only assume this is referring to a site wide error.

    Yes, this is likely due to a script that is being enqueued on every page.

    Despite the 26 odd posts which are listed in the validation list, most of the posts validate fine on the front-end.

    Something important to note here is that the plugin forces responses to be valid AMP. It strips out things and add things to make it a valid AMP document. So the validation errors reported should not then also get picked up by Google Search Console because the invalid markup will not be exposed on the frontend. So the validation errors are there to inform you that there is content which is getting stripped out when making the response valid.

    What is especially odd is that comparing two posts listed as invalid, the one post validates fine and another post doesn’t.

    Are you saying one post validates and another does not with the AMP validator? Or are you saying this is with the plugin’s internal validation?

    Plugin Author Weston Ruter

    (@westonruter)

    2.) The other issue I found is when a post does have an issue, a redirect to the dev url is automatically added to the Yoast redirects, resulting in the post 404’ing.

    I think I’ll need more info about this. Not sure what the Yoast redirects are here. Is it for ensuring canonical URLs?

    Something important to note here is that 0.7 adds the initial amp theme support to the plugin. It’s really targeting vanilla WordPress installs without plugins installed. As we move toward 1.0 we’ll be advocating for plugins to improve their AMP compatibility so that more and more can be used seamlessly. For example, amp theme support is now being worked on in Jetpack. But all of this to say, it is expected that there are rough edges now as you’re working to deploy amp theme support in 0.7 since it is just the initial support. Your testing of the feature is quite helpful for the effort. You may want to consider using a 1.0-alpha build if it resolves enough of the issues you’re facing. We’re using it now on https://make.xwp.co/?amp

    Thread Starter Chris Rault

    (@connectr)

    Hi Weston,

    Thanks for taking a look ??

    I managed to get around the html attributes issue by using the markup api in Beans to replace the value on the prefix attribute. I then rechecked the posts in the validation list, but all the issues with the og and http attributes are still there.

    Would you mind sending me a copy of the alpha, so I can give that a try?

    Cheers,
    Chris

    Plugin Author Weston Ruter

    (@westonruter)

    Here is how to create a 1.0-alpha build (from the develop branch): https://github.com/Automattic/amp-wp/blob/develop/contributing.md#creating-a-plugin-build

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘AMP validation errors not getting cleared from error list’ is closed to new replies.