fix(previews): Previews `{URI}` template doesn't follow permalinks

[moonmeister]

What did you do?

I configured my preview URL for posts to look like: http://localhost:4321/{uri}?preview=true. Permalinks are set to "Month and name". But this seems to affect any permalink setting other than "Post name".

What did you expect to happen?

I expected to be able to preview posts, and the URI to be correct.

What actually happened?

The preview URL was http://localhost:4321/new-post-draft?preview=true, which was not correct. It should have been `http://localhost:4321/2025/05/new-post-draft?preview=true

Additional context (Optional)

HWP Previews v0.0.1
WPGraphQL v2.3.0

[colinmurphy]

@moonmeister @ahuseyn

Just noting I think this is a high priority issue we should look at this sprint. Thanks @moonmeister for raising this issue 👍

[moonmeister]

Question: @whoami-pwd mentioned that the whole URI thing is kind of hacky. My concern is that if it's so hacky as to be unstable, should we even include it as a feature?

By comparison, the URL filtering we do in Faust.js has so many corner cases and caveats that we still get bugs reported on it after 5 years. As Dovid told us, it's almost better to just let the JS handle this.

I'm not aware of any requirement from front-ends to have a full URI. Can they all just use the post ID like headful WordPress uses?

If there is a case where it's very stable, maybe we mark this specific feature as experimental or unstable?

[colinmurphy]

@moonmeister

Those are some great points ❤

It feels like this needs a bit of research to help make the correct decision as I don't know either. I am not sure yet why a post ID wouldn't be sufficient to query a post/page/CPT but there might be a good reason not to use this.

On your point about Faust, even adding in the content_replacement work we still even had an edge case around ports so very hard to cover all use cases. (this was a rewrite for multisite).

I think what would be useful to get completed this sprint is #217 and define the use cases and features (including examples/integrations) and create some sort of roadmap for BETA etc.

[ahuseyn]

I'm not aware of any requirement from front-ends to have a full URI. Can they all just use the post ID like headful WordPress uses?

Great point @moonmeister. I've tried to use URI for the Next example and it caused so many trouble where the databaseID worked just fine. Having an option for the URI may cause confusion and a false sense that it's a better/recommended way to do it.

My suggestion is that, instead of providing this feature when nobody asked for it, we wait until someone actually requests it with a reason and a use case.

[moonmeister]

Hopefully @whoami-pwd can verify we are not missing anything and we'll go forward without it.

[whoami-pwd]

@moonmeister the URI thing is not hacky, as you can see from the callback for the URI preview param it is the function called get_page_uri. And what I can see from the description of this issue - it works as expected here.

You can change the callback (along with logic) for the parameter to make it more beneficial for the user. It is totally fine.
I don't have any pros and no cons for doing things only with URIs vs IDs. Personally I would stick to the IDs for examples. But keep URI in case if its needed for someone (for redirects or FE side logic).

Please feel free to edit/remove it if needed.

[moonmeister]

Thanks Alex, maybe we just need to get it working correctly.

[whoami-pwd]

Then I suggest replacing the callback with your custom functionality to take into account the permalink structure as well.