This is normal behavior, with any <noscript? fallback (which would normally come into effect should a visitor have JavaScript disabled) being active once a user visits your AMP URL. The plugins AMP_Script_Santitizer ensures the content is visible while the <!–/noscript–> comment is an indicator.
Let us know if you have any further questions on this.
Thread Starter
asafm7
(@asafm7)
Thanks for your reply.
I’m not sure I fully understand though.
According to the documentation, <noscript> should behave normally with AMP. Meaning, they should only be viewed if JavaScript is really disabled, and not always, on every AMP page.
Again from the documentation:
Allowed. Can be used anywhere in the document. If specified, the content inside the <noscript> element displays if JavaScript is disabled by the user.
https://amp.dev/documentation/guides-and-tutorials/learn/spec/amphtml/
The emphasis is mine.
Am I right?
-
This reply was modified 7 months ago by
asafm7.
If you’re not using the AMP plugin and following the amp.dev guide then yes, <noscript> will behave normally and run only when JavaScript is disabled. As the plugin sanitizes all content it will insert the comment while also exposing content between the noscript tags.
Are you looking to use noscript to ensure content appears in the case a user has explicitly opted out of all JavaScript? I can check whether there are plans to change the behavior within the plugin and report back to you here if you wish.
Thread Starter
asafm7
(@asafm7)
Yes.
More specifically: I share code snippets using embedded gists in my posts. As they are produced by JavaScript, and on AMP also using an iframe, I’m not sure about them being indexed by Google. Copying them into a <noscript> tag feels like a good SEO solution.
On a general note, I feel like the AMP plugin behavior should conform with the AMP documentation, isn’t it?
Anyway, yes, it will be great if you let me know if there are plans to change the behavior.
Thanks again
The AMP specification allows for noscript, yes, but in general the most helpful behavior for existing plugins which aren’t built to support AMP is to unwrap the noscript elements so that their contents become the fallback on the AMP page. We don’t currently have a way to prevent this unwrapping behavior, but we could introduce it via some class name like <noscript class="amp-wp-preserved">.
But are you embedding the Gists via the amp-gist component? If so, the best fallback approach would be to put the text content inside of the amp-gist component as a fallback child. Like so:
<amp-gist data-gistid="e5032d805625f0f743237708c43d3783" layout="fixed-height" height="400">
<pre fallback>
<?php
/**
* AMP Mobile Server-Side Redirection plugin bootstrap.
*
* @package Google\AMP_Mobile_Server_Side_Redirection
* @author Weston Ruter, Google
* @license GPL-2.0-or-later
* @copyright 2021 Google Inc.
*
* @wordpress-plugin
* Plugin Name: AMP Mobile Server-Side Redirection
* Plugin URI: https://gist.github.com/westonruter/e5032d805625f0f743237708c43d3783
* Description: Disable the default client-side JS-based mobile redirection in lieu of opt-in in to server-side HTTP redirects. The AMP plugin does client-side redirection by default since it is most compatible across various caching plugins, but if possible you should use server-side redirection because it is always faster.
* Version: 0.1
* Author: Weston Ruter, Google
* Author URI: https://weston.ruter.net/
* License: GNU General Public License v2 (or later)
* License URI: http://www.gnu.org/licenses/gpl-2.0.html
* Gist Plugin URI: https://gist.github.com/westonruter/e5032d805625f0f743237708c43d3783
*/
add_filter( 'amp_mobile_client_side_redirection', '__return_false' );
</pre>
</amp-gist>
Nevertheless, if you’re going to the trouble of copying the original Gist contents into your posts in addition to linking to the Gists, why not just use a regular Code block in Gutenberg? You can get AMP-compatible syntax highlighting (server-side via PHP) with my plugin: Syntax-highlighting Code Block (with Server-side Rendering). It involves zero JavaScript so it is inherently AMP-compatible.
Thread Starter
asafm7
(@asafm7)
Thanks @westonruter
I’m not directly using <amp-gist>, but rather Jetpack’s Shortcode Embeds functionality which does everything automatically with the block editor (including fetching <amp-gist> on AMP pages, and regular markup on regular pages), and that’s why embedding the code is not really an option.
As you guessed, I prefer gists over the native code block because of syntax highlighting.
I tend to choose official solutions over solo-developer plugins, because of a better chance of future-proofness. If a native syntax highlighting code block would be merged to the WordPress core – it will be great.
Following this, do you think there is any chance for a change in noscript behavior? (or, even better, for your plugin to be merged to core? :))
Thanks again
Thread Starter
asafm7
(@asafm7)
@westonruter btw I just tried your plugin and it’s great!
It turns out there is a way to prevent noscript from being unwrapped at present. All you have to do is add a data-ampdevmode attribute to the noscript. For example:
<noscript data-ampdevmode>
<p>Sorry, you have JS turned off!</p>
</noscript>
This is not super intuitive, but it basically means that AMP conversions should be skipped for the element. I’ve opened an issue to improve on that: https://github.com/ampproject/amp-wp/issues/6030
Nevertheless, you can use that technique for now.
Maybe best not to rely on data-ampdevmode actually, since it seems this was mistakenly used as an exemption without also checking if the attribute is on the html element.
