Add a hook to run before building the "live url"

[kristijorgji]

Hi,

you have already one hook that runs before building the preview url which is used in the preview button.
This is working great (export const HOOK_BEFORE_BUILD_URL = 'plugin/preview-button/before-build-url';).

I would like to have another hook for the show button, when the content is published and you open the live view.

Why?
Because the existing config is not enough for dynamically locating the page where a particular cms element is used.

I want to open as live view something like example.com/api/locate?type=block&otherdatahere then the web locates where this block is uses and redirects 307 to that page.

The problem is that now you do not urlencode the query parameters properly and is not very flexible.

My current config:

                    {
                        uid: 'api::block.block',
                        published: {
                            url: `${env(
                                'SITE_URL',
                            )}/api/show?locale={locale}&type=block&container={container}&key={key}`,
                        },
                    },

if container is an url like magic-products/blabla it is not urlencoded and breaks.

Would be super easy if we have a hook to build ourselves the published url based on the entity content instead of being limited only to the statis plugins.ts config

[mattmilburn]

Hi @kristijorgji If you're using the HOOK_BEFORE_BUILD_URL hook, are you not able to inspect data.publishedAt to determine if it is in draft or published mode? Also, the configs for draft and published modes already separate so checking the published state shouldn't be necessary.

As for encoding, it seems like we just need to update this line of code to use [key]: encodeURIComponent(val) which would produce this URL based on your example:

http://localhost:3000/api/show?locale=en&type=block&container=foo%2Fbar&key=3

[mattmilburn]

@kristijorgji Actually after adding tests for encoded params, I've realized that I was relying on qs to encode the params and tests were failing because of that. I think I have a safe fix for this on the way 👍🏻

[mattmilburn]

@kristijorgji I created PR 112 which should fix this issue 👍🏻 but please let me know if I can clarify anything else about your issue.