PopupMaker/Popup-Maker

WordPress's partial match redirect tries to redirect to Popup Maker custom post types which throws a 404

marklchaves opened this issue · 2 comments

Describe the bug

It looks like there's a conflict between WordPress's partial match redirect and Popup Maker custom post types.

Meaning WordPress tries to match a title (not just a slug) and Popup Maker popups don't have official slugs (i.e., popups technically don't have a public URL). So, it looks like WordPress is redirecting to a special query parameter string Popup Maker uses to "preview" popups via the admin toolbar.

Site information

Popup Maker version: 1.16.7

WordPress version: 6.0

PHP version: 8.0.12

Expected behavior

Partial matches on valid posts/pages should work instead of redirecting to the popup preview URL

https://mywaycool.site/?post_type=popup&p=123

which throws a 404 on the front end.

Current behavior

See above.

Steps to reproduce

  1. Create a post or page called "Newsletter".
  2. Create a popup called "Newsletter".
  3. Make sure WordPress partial match redirect is turned on.
  4. Try to navigate to a partial match, e.g., https://mywaycool.site/news
  5. You should see a 404 for a URL similar to https://mywaycool.site/?post_type=popup&p=123 where the popup ID (123) matches the ID of your "Newsletter" popup.

Errors

Additional context

As a workaround, you can turn off the partial match redirect.

add_filter( 'do_redirect_guess_404_permalink', function() {
	return false;
} );

Reference https://developer.wordpress.org/reference/hooks/do_redirect_guess_404_permalink/

Turning it off from our plugin is not an option, that could break an admins site in ways they wouldn't ever assume came from our plugin.

Never knew this was even a thing (partial match), and I've been using WordPress for 12+ year haha.

Not sure we can change it as we already told WP not to make them public, might be some special rewrite rule trick we could employ but how do we know we are not breaking something else at that point would be the concern.

We don't want it to 404 in your example, you'd actually want it to go to the /newsletter/ page. How could we code something that would handle that from our end 100% correctly every time?