frontity / wp-plugins

Bug report

I've updated both my project and my packages to the latest Frontity versions: https://docs.frontity.org/guides/keep-frontity-updated
I've searched for existing issues.
I've checked the documentation: https://docs.frontity.org
I've checked the community forum: https://community.frontity.org

Expected behavior

when uploading image to the media and then use it as featured image in a post everything should be normal

Observed behavior

the end point /wp-json/wp/v2/posts?_embed=true redirects to the uploaded image instead of the json of the posts

but if we remove the _embed=true part it works again

Steps involved to reproduce the problem

you actually dont need frontity project

all you need is a wordpress with these two plugins

open media tab
upload an image
create new post and add this image as a featured image
save the post
go to the endpoint /wp-json/wp/v2/posts?_embed=true

Possible solution

any of these alone will fix it

disable REST API – Head Tags
disable Yoast and then re-enable it
upload the image from the featured image dialog within the post itself NOT from the media tab
remove _embed=true from the endpoint

The team is on holiday now but we'll look into this on Monday. Thanks for the report @mody-ydom 👍

I was able to reproduce the issue.

It looks like the problem was introduced in 1.1.0: https://github.com/frontity/wp-plugins/blob/dev/plugins/frontity-headtags/CHANGELOG.md#110

Specifically because of this line.

wp-plugins/plugins/frontity-headtags/includes/class-frontity-headtags.php

Line 142 in 7b77561

do_action( 'template_redirect' );

So the problem comes because we are calling template_redirect.

The template_redirect that is doing the redirection in Yoast is this:
https://github.com/Yoast/wordpress-seo/blob/master/frontend/class-frontend.php#L135

add_action( 'template_redirect', [ $this, 'attachment_redirect' ], 1 );

Until we solve this, the issue can be fixed by disabling attachment redirects in Yoast options:

@DAreRodz Could you handle this issue once you finish with the one you're working on right now? It seems it could affect most of the sites using Yoast and our plugin, including our own blog.

Sure. I was thinking how to solve this.

The template_redirect action it's called because SEO plugins use that to register a lot of hooks to different actions (wp_head and Yoast actions in this case). It was a way to really simplify the code.

We could either

stop using template_redirect (each SEO integration would have to register those hooks being registered during that action).
unregister the attachment_redirect from template_redirect during head tags computation, and register it again later (much simpler).

unregister the attachment_redirect from template_redirect during head tags computation

Yeah. I was thinking about that option too but it doesn't look solid. I mean, if we keep the template_redirect action the plugin is going to break if people use any other plugin out there that is using some type of redirection logic that interferes with our plugin, like this case.

If we use your first suggestion, yes, we have to add manually all those hooks and we have to maintain the list, but at least no other plugin could break it.

What do you think?

If we use your first suggestion, yes, we have to add manually all those hooks and we have to maintain the list, but at least no other plugin could break it.

They won't break the Head Tags plugin unless they change the hooks they are using internally. And I think you are right, that's less probably to happen than adding new hooks to template_redirect that could break Head Tags plugin again.

The bugfix in #29 is ready.

I move this to To do again waiting for #32 to be merged before setting #29 as ready to review.

Hey @mody-ydom, we have released a new version of the Head Tags plugin (1.1.3). Let us know if it's working now. 🙂

301 response when fetching posts