Repository navigation
fix(previews): Previews {URI} template doesn't follow permalinks #201
Description
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
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
colinmurphy commentedon May 20, 2025
@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 commentedon May 22, 2025
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 commentedon May 22, 2025
@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 commentedon May 23, 2025
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 commentedon May 23, 2025
Hopefully @whoami-pwd can verify we are not missing anything and we'll go forward without it.
whoami-pwd commentedon May 27, 2025
@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 commentedon May 27, 2025
Thanks Alex, maybe we just need to get it working correctly.
whoami-pwd commentedon May 27, 2025
Then I suggest replacing the callback with your custom functionality to take into account the permalink structure as well.
moonmeister commentedon May 27, 2025
How are permalinks custom functionality? Are you confusing URI vs URL vs SLUG?
colinmurphy commentedon May 27, 2025
@whoami-pwd @moonmeister @ahuseyn
One concern I have is about using URI and the filter "wp-insert-post-data" to generate a unique slug which is a great idea, it also might have some maintainability issues if for instance that filter fails for some reason (database connection or plugin fatal error etc).
whoami-pwd commentedon May 27, 2025
@moonmeister Sorry for the confusion.
In the description for this issue you are saying that with the configuration like
http://localhost:4321/{uri}?preview=trueyou want to get thehttp://localhost:4321/2025/05/new-post-draft?preview=true.What I am trying to say is that not the
{uri}preview parameter, no the default WP preview link functionality won't give you such output. Nothing here takes into account the permalink structure that you changed.The {uri} preview parameter gives you the result of the builtin WP function called get_page_uri. It doesn't give you anything related to the permalink structure. Please refer to the source code of the function. It returns only the
page-uriorparent/page-uriif it is child one.Sorry for the wrong/incorrect usage of URI / URL here. I am operating with terminology how WP calls it in those specific places. :)
moonmeister commentedon May 27, 2025
@whoami-pwd thanks for the clarification! Yeah I stick with the WPGraphQL usages of these terms.
@colinmurphy if we can stabilize this all it would be nice, but as discussed might be a risky feature.
colinmurphy commentedon May 30, 2025
Thanks @moonmeister @whoami-pwd
@ahuseyn and I discussed this on a call and we feel it would be better to remove this for now and we can always add the feature back in if we feel as a team this gives value. We want to make the plugin stable as possible for BETA release.
ahuseyn commentedon Jun 17, 2025
@colinmurphy I'm going to remove the URI parameter from the list, as we basically stopped supporting it and it's not working for the drafts.
colinmurphy commentedon Jun 17, 2025
Thanks @ahuseyn ❤ 🚀 🚀