Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AMP: load order issues #11169

Closed
3 tasks
jeherve opened this issue Jan 21, 2019 · 4 comments · Fixed by #11195
Closed
3 tasks

AMP: load order issues #11169

jeherve opened this issue Jan 21, 2019 · 4 comments · Fixed by #11195
Assignees
Labels
AMP Epic Formerly "Primary Issue", or "Master Issue" [Pri] BLOCKER [Type] Bug When a feature is broken and / or not performing as intended
Milestone

Comments

@jeherve
Copy link
Member

jeherve commented Jan 21, 2019

Opening this to track the different issues that were caused by #10945 in Jetpack 6.9. We'll need to find a different solution to address the solution proposed in this PR, as it caused problems with different modules:

@jeherve jeherve added [Type] Bug When a feature is broken and / or not performing as intended Epic Formerly "Primary Issue", or "Master Issue" [Pri] BLOCKER AMP labels Jan 21, 2019
@jeherve jeherve added this to the 7.0 milestone Jan 21, 2019
@jeherve jeherve self-assigned this Jan 22, 2019
@jeherve
Copy link
Member Author

jeherve commented Jan 22, 2019

cc @westonruter Moving things from init to after parse_query seems to be causing quite a few issues with different Jetpack modules. I can imagine that this could be an issue with other plugins making use of is_amp_endpoint. Has this come up since the release for you?

@westonruter
Copy link
Contributor

If plugins rely on an early hook to initialize (like Jetpack), then yes, this will be something needing to be worked through.

The AMP plugin has always required the parse_query action to have fired before calling is_amp_endpoint() though during the 1.0 release cycle we did try to remove this consraint in ampproject/amp-wp#1148 to make it easier for plugins but it had to be undone. It had to be reverted because it's simply not possible to know whether it will be an AMP response until the query has been established. This is especially true when in Native mode because there is no query parameter to look for.

While is_amp_endpoint() has always required the parse_query action (and now actually wp) what has changes is using this function in regular template responses in the Native/Paired modes. So there is more surface area now.

Ultimately, the solution is to delay initialization of the modules or defer the is_amp_endpoint() checks until the wp action.

jeherve added a commit that referenced this issue Jan 23, 2019
This reverts some of the changes to Carousel that were made in #10945.
Instead, we try to defer the is_amp_endpoint until wp is loaded,
to avoid the problems raised in #11169.
@jeherve
Copy link
Member Author

jeherve commented Jan 23, 2019

Thanks, that makes sense! Do you think something like 29a3558 would be enough to solve our issues here?

@westonruter
Copy link
Contributor

@jeherve The change to is_amp_request() in class.jetpack-amp-support.php I don't think is correct. By only returning a value if the wp action has happened, then it will just inexplicably return null when called and it would fail to return the right value when the request actually is AMP.

A normal refactor would look like this. Given this code:

add_action( 'init', function() {
    if ( ! is_amp_endpoint() ) {
        add_filter( 'something', 'filter_something' );
    }
} );

function filter_something( $value ) {
    $value .= 'something else';
    return $value;
}

This should be changed rather to be:

add_action( 'init', function() {
    add_filter( 'something', 'filter_something' );
} );

function filter_something( $value ) {
    if ( ! is_amp_endpoint() ) {
        $value .= 'something else';
    }
    return $value;
}

So essentially the AMP checks should be deferred to as late as possible.

jeherve added a commit that referenced this issue Apr 24, 2019
Summary:
After adding the AMP compat file that ships with Jetpack (this was done in D22313, D26814, D26819, D26921, and D26928), let's start using this class.

This replaces D22154 and D23501, and allows us to start syncing any future changes that would rely on the Jetpack_AMP_Support class.

Related Jetpack PRs:
- #10945
- #11195, which reverted some of the changes in the PR above.
- #12054
- #12053
- #12026

Discussion:
- https://[private link]

We'll need to test for issues like the ones that popped up on Jetpack at the time:
#11169

We will also need to account for the fact that WordPress.com does not run the latest version of the AMP plugin. It runs an old version (0.6.2 vs. the current version on W.org 1.0.2), with its own version of some of the compatibility fixes that come with the class we've added (see [[ https://[private link].php | here ]]) and needs to be updated as per the discussions here:
- https://[private link] (D14521)
- https://[private link]

Test Plan:
* Create a post with a gallery
* Add a Facebook sharing button to that post.
* Try Liking that post.
* Comment on one of the images in the gallery.
* Load the post in an AMP view, and repeat the steps below.

In all cases:
- You should not see any js errors in the browser console.
- You should not get any PHP notices in your debug log.

Reviewers: zinigor

Tags: #touches_jetpack_files

Differential Revision: D26821-code

This commit syncs r190790-wpcom.
jeherve added a commit that referenced this issue Apr 24, 2019
Summary:
After adding the AMP compat file that ships with Jetpack (this was done in D22313, D26814, D26819, D26921, and D26928), let's start using this class.

This replaces D22154 and D23501, and allows us to start syncing any future changes that would rely on the Jetpack_AMP_Support class.

Related Jetpack PRs:
- #10945
- #11195, which reverted some of the changes in the PR above.
- #12054
- #12053
- #12026

Discussion:
- https://[private link]

We'll need to test for issues like the ones that popped up on Jetpack at the time:
#11169

We will also need to account for the fact that WordPress.com does not run the latest version of the AMP plugin. It runs an old version (0.6.2 vs. the current version on W.org 1.0.2), with its own version of some of the compatibility fixes that come with the class we've added (see [[ https://[private link].php | here ]]) and needs to be updated as per the discussions here:
- https://[private link] (D14521)
- https://[private link]

Test Plan:
* Create a post with a gallery
* Add a Facebook sharing button to that post.
* Try Liking that post.
* Comment on one of the images in the gallery.
* Load the post in an AMP view, and repeat the steps below.

In all cases:
- You should not see any js errors in the browser console.
- You should not get any PHP notices in your debug log.

Reviewers: zinigor

Tags: #touches_jetpack_files

Differential Revision: D26821-code

This commit syncs r190790-wpcom.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
AMP Epic Formerly "Primary Issue", or "Master Issue" [Pri] BLOCKER [Type] Bug When a feature is broken and / or not performing as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants