Progressive mode

Hello @htrex

Thank you for contacting us, Yes you can use “progressive mode” with AMP.

AMP plugin introduced experimental Sandboxing Mode in version 2.2 it, Now you can use Fast performing bento components (Next gen AMP components) without worrying about AMP invalidations.

Eg: If you have used youtube embed on a page the AMP plugin will replace the embed with amp-youtube component which is fast performing component compared to youtube embed, by introducing a fast loading component in place of slow loading embed your page performance is automatically improved.

The Sandboxing Mode can be set to level of AMP optimization can be introduced and on a level AMP invalidation is introduced.

Loose: the components will be applied only when they are AMP compatible, the custom script is allowed, and the CSS processing will be disabled.

Moderate: remove anything AMP invalid, except for POST Forms, excessive CSS, and other PX-verified markups. This mode should perform almost as well as pages in Strict, but they won’t be valid AMP so they won’t be eligible for AMP Cache.

Strict: Require valid AMP, removing all markup that causes validation errors (except for excessive CSS). This is how the plugin has previously behaved by default.

You can learn more about sandboxing mode in our release blog post

How you can use it in your site?

Step 1: Switch to Standard Mode and Click save. (Currently Sandboxing is only available for Standard Mode)

Step 2: You will notice an new Setting named Sandboxing (Experimental) is introduced

Step 3: Choose “Loose Mode” (don’t worry AMP plugin will adjust the level itself when it sees opportunity)

You can learn more about Sanboxing mode in our documentation

I hope this is helpful!

Hi Milind,
it seems the new sandboxing feature could be perfect for my use case, except it only works in standard mode.

To recap, I’ve a custom parent theme which is AMP native and used as reader theme, while a child theme adds some js to it for any page of the website and is used as standard theme.

As far as I understand, with sandboxing in loose mode I’ll not have a single AMP valid page on my website, because any page contains invalid JS.
In moderate mode every page will be AMP valid, but “progressive” JS will be stripped out.

In the documentation

Lastly, in future releases, we may allow the sandboxing levels to be used in non-Standard modes as well, in particular Reader mode.

is there any github issue to follow the development of this feature?

it seems the new sandboxing feature could be perfect for my use case, except it only works in standard mode.

Yes, currently available only for Standard Mode

To recap, I’ve a custom parent theme which is AMP native and used as reader theme, while a child theme adds some js to it for any page of the website and is used as standard theme.

You can use your child theme which contains js as your primary theme instead of Reader Theme.

As far as I understand, with sandboxing in loose mode I’ll not have a single AMP valid page on my website, because any page contains invalid JS.
In moderate mode every page will be AMP valid, but “progressive” JS will be stripped out.

Yes, the pages won’t be valid AMP anymore and the focus will be on Fast performing pages.

is there any GitHub issue to follow the development of this feature?

Currently, we are experimenting with it internally to check the possibilities, also some strategic decisions will be taken then we can make it public.

till then you can check following issues labeled as sandboxing and px-toolbox-php repo.

To enqueue AMP-invalid scripts my child theme uses a conditional:

if ( !function_exists('amp_is_request') || !amp_is_request() ) { ...

I had to remove that condition, otherwise even when using Sandboxing loose mode they wont get enqueued. Is there any function or trick to check is Sandboxing mode is active and what’s the sandboxing user selected level?

Hello @htrex

You don’t need that condition if you are trying to enqueue the script on sandboxing mode, you only need it if you want something specific on the AMP page.

The sandboxing box is active on canonical pages ie. you will have only one version of the page.

As I mentioned before if you choose “Loose” mode the scripts will get enqueued automatically.

I’ve removed it. You’re right, that condition isn’t needed when serving only an AMP invalid website in Standard mode with sandboxing loose mode.
I was trying to make it future proof, as some kind of mode checking will be needed again if and when sandboxing will be extended to the reader mode and a plugin or theme could include or exclude some scripts depending on the context (reader theme: Strictly valid AMP page, standard theme: AMP page with unvalid additions).

Now, it mostly works but I’m facing a show stopper. In some pages I’m using the <amp-selector> that’s included in a custom post type template.
In Standard mode with sandboxing loose mode active the <amp-selector> component doesn’t work, while in reader mode it does both when rendering the standard theme and the reader theme.

The issue comes from a js error, see:
https://gist.github.com/htrex/f63eedce5558ab4f08ddab37e14bc471

I don’t have a clue on how to debug it.

• This reply was modified 2 years, 2 months ago by htrex.
• This reply was modified 2 years, 2 months ago by htrex.

Hello @htrex

It will be best to contact AMP support (We are exclusive support AMP WordPress plugin) as they can guide you better in terms of scripts conflicts.

Hello @milindmore22
I wasn’t sure it was an AMP script compatibility issue and tried some changes to the code before contacting AMP JS libraries support.

At the end I’ve found that a mu-plugin containing add_filter('amp_enable_ssr', '__return_false'); solves the js error (https://gist.github.com/htrex/f63eedce5558ab4f08ddab37e14bc471), but that also disables important performance optimizations.

@westonruter can you please give me a few hints to debug this issue further?

It looks like the error is coming from amp-selector v1.0 which is the Bento version. This is still experimental but we use it by default when in the Loose level to guard against other scripts on the page mutating the element tree and causing an inconsistent state. I suspect that if the v0.1 version is used instead that the error will go away. I’ll look into the best way to do that.

Thank you Weston, I’ve compared the sources between the working and non working version. In sandbox mode, it seems that when a 1.0 version exists, the libraries are updated to it, while the difference with the libraries and SSR on/off seems to be the use of js modules (.mjs).

When SSR is on I’m getting that error.

• This reply was modified 2 years, 2 months ago by htrex.

I was able to easily replicate the issue by:

1. Setting template mode to Standard
2. Enabling Loose sandboxing level
3. Adding a Custom HTML block that contained:

<button on="tap:mySelector.clear">Clear Selection</button>
<amp-selector id="mySelector" layout="container" multiple="">
  <div option="">Option One</div>
  <div option="">Option Two</div>
  <div option="">Option Three</div>
</amp-selector>
<script>document.write('document write!')</script>

When I did that, the post had the same JS error.

As a quick fix, you can edit includes/sanitizers/class-amp-script-sanitizer.php in the plugin to add one line as follows:

diff --git a/includes/sanitizers/class-amp-script-sanitizer.php b/includes/sanitizers/class-amp-script-sanitizer.php
index fc4d5c131..90e8faf32 100644
--- a/includes/sanitizers/class-amp-script-sanitizer.php
+++ b/includes/sanitizers/class-amp-script-sanitizer.php
@@ -150,6 +150,8 @@ public function sanitize() {
 			$sanitizer_arg_updates[ AMP_Form_Sanitizer::class ]['native_post_forms_allowed']       = 'always';
 		}
 
+		$sanitizer_arg_updates[ AMP_Tag_And_Attribute_Sanitizer::class ]['prefer_bento'] = false;
+
 		foreach ( $sanitizer_arg_updates as $sanitizer_class => $sanitizer_args ) {
 			if ( array_key_exists( $sanitizer_class, $this->sanitizers ) ) {
 				$this->sanitizers[ $sanitizer_class ]->update_args( $sanitizer_args );

This will prevent Bento from being enabled altogether.

I’m going to file an issue about disabling Bento by default since clearly it is buggy (and still experimental).

I’ve filed an issue to basically do the same thing for the next release: https://github.com/ampproject/amp-wp/issues/7267

Magic Weston,
I can confirm that removing the prefer bento flag did the trick!
I’ve also removed the mu-plugin workaround with add_filter('amp_enable_ssr', '__return_false'); and it still works.

I’ll need to check it again on the next AMP plugin update to see if the patch will be merged already.