Can we get codename made available in preview URLs?

SamPisansarakitSamPisansarakit Member
edited November 2017 in Product Wishlist

Can we get codename made available in preview URLs, please?

I'm currently using a lot of content models as 'widgets' that can be placed in modular content blocks on a page. I'd love a way to be able to preview them without assigning them a slug.

Comments

  • petrs@kentico.competrs@kentico.com Eindhoven, NLMember, Administrator, Kentico Staff admin

    Hi @SamPisansarakit!
    If I get it right, you would like to have a {Codename} macro available for resolution of preview links. Also, in real life (in production) the widgets will never be displayed on their own (they will always be assigned as a modular content).

    If that's the case, what's the point of previewing self-contained widgets? Wouldn't you get a better picture of whether it works fine if you saw the widget in context of its parent page?

    Could you please provide more info about your specific scenario?

  • I'm using https://www.imgix.com/ to serve images from the asset library, so a client can upload a single high-res image and I can transform it for different devices or different areas of the site.

    One thing I was hoping to put together was something like an "advanced image" content type, or a "image transform" content type that they could drop into modular content to apply a single transform in multiple places. Maybe even a "responsive image" content type where they could apply multiple resolution-dependant transformations.

    For example:

    Lets say they are creating a "Hero Banner", the hero banner has a modular content slot that accepts an "Advanced Image".

    On either the hero banner or the advanced image, I could have a preview url that links to domain.com/admin/image-editor/{Codename}. On that page I'd have the image displayed and a GUI to apply all the different transformations. A very basic example: https://vuecloud-staging.azurewebsites.net/advanced-image-preview/advanced-image-test

    Even without this specific case, I can think of lots of reasons to provide the ability to preview a single content type.

    Maybe I want to create an "A/B testing" widget that picks a random item from a set of modular content. There would be no way to reliably preview that content.

    Maybe I have a "Hero Carousel" widget where you can drop in a bunch of "Carousel Slides", there would be no way to preview the last slide without clicking through all the others.

    For cases like this I would love to be able to have something like /admin/widgetPreview/{Codename}

    Also I don't think it's fair to assume that everyone's content editing workflows are the same on anything but very basic websites. Not everyone will create a page based on a specific page template and enter content. We've had lots of cases in the past where a client will get a junior in for a day to do nothing but create a bunch of hero banners. They can't be expected to create a new page and give it a temporary slug just to preview their work, then go through and delete those pages afterwards.

    Maybe a client wants to have a library of content available to them to put into their pages. It doesn't make sense for them to pull that page back in to draft and put one widget at a time into a modular slot just to see what it looks like.

    In the case of having something like a "Hero Carousel" that can be assigned "Carousel Slides", it also doesn't make sense to have to navigate away from the item you're editing to be able to preview it. You'd have to go two levels up to get back to the page, hit the preview button, and then navigate back two levels down to see the model of what you are looking at.

  • Even pages don't necessarily have a slug assigned to them. In the project I'm currently working on a user creates a page based on a page template, and assigns that page to a "Navigation Item". The navigation item is the thing with the slug attached to it.

  • petrs@kentico.competrs@kentico.com Eindhoven, NLMember, Administrator, Kentico Staff admin

    @SamPisansarakit that's an awesome feedback! The reasoning is now very clear to me and the points you made make perfect sense. Thank you very much for it! I'll make sure your remarks reach our POs.

    Could a possible workaround be adding a URL slug to the content types and marking it as *required?
    The items could be then retrieved as follows https://deliver.kenticocloud.com/975bf280-fd91-488c-994c-2f04416e5ee3/items?elements.url_pattern={URLslug}

  • petrs@kentico.competrs@kentico.com Eindhoven, NLMember, Administrator, Kentico Staff admin
    edited December 2017

    Btw - there is a bug preventing setting a URL slug to required at the moment. We know about it and working on it.

    EDIT 2017-12-19: Fixed

  • I totally agree with Sam, {Codename} variable would be great in order to generate preview of various content, but just also simply pages. For instance the URL slug for my homepage (just considered as a simple content page) is empty in my case, so I simply can't preview it. Or the URL of a blog post like /2017/11/myblogpost based on the post date. Just impossible to build based on slug variable.
    I like the fact the content editor can see the final URL in preview so I created a URL redirecting to the final URL of the page following this pattern /admin/refresh?redirect_to={URLSlug}. Small detail here, in my case, I clear the cache on the server before redirecting to the final URL. Not even considering a URL slug could potentially be the same for various pages of the same type. (if URL slug is used as segment in URLs) So it would be great to have access to the Codename.

  • adamadam Member ✭✭
    edited December 2017

    Having a codename macro would also be useful for our use case. Our content manager specifically does not want to provide her writers the ability to setup a full url slug on any page (as in, she only wants to allow them to enter the final path segment, and select the location in the sitemap), so we implemented a content item type that maps sitemap codenames to url path segments, and then when we query for a content item list by urlslug, we filter on system.sitemap_locations. Doing this works well as we are caching the mapping items, however on the 'preview' path, we don't have enough context to select a single item.

  • JanL@kentico.comJanL@kentico.com Czech RepublicMember, Administrator, Kentico Staff admin

    Hi Adam,

    sorry for a late reply. I just want to make sure I understand your scenario well. So, what you say is that the preview page cannot be displayed just because the editor did not fill in any URL slug yet. Is that correct? Or, do the preview URLs have a completely different structure than the production-grade ones?

    Thank you.

  • adamadam Member ✭✭

    Correct. Our production urls are completely different than the preview ones.

    Having the codename available in the preview url macro (or even the id) would always ensure that we will only have one item returned in the information provided when we hit our preview endpoints.

    For some background on how we are doing this now, as well as why:

    Ideally, from an engineer's perspective, I would require the content authors to define a fully qualified unique urlslug, then we could have the production urls match the preview ones. However working with our content managers, as well as looking at 'problems' that I found while porting content from our existing vendor, there is a clear business case to not give a writer that much control, which is why we came up with a solution to lock down much of the production path via a sitemap, and allow the writer to define the url slug as the leaf child path segment, however that inevitably creates conflicting urlslugs (think, "/alabama/homeowners-insurance/" and "/minnesota/homeowners-insurance/", where 'homeowners-insurance' is the url slug). We also do not want to leverage using the content type itself as a driver for our URL patterns.

    In cases where we have multiple content items that end up being mapped to the same URL. We provide warnings that are embedded into the page header while in preview, and on a production request, we just use the first result. Furthermore if we have multiple results for a urlslug in preview, but they wouldn't conflict with their parent path segments, we are showing links to the author to reselect which one they want (since we have a list of IDs/codenames after we query), but that is less than an ideal experience for the author if we could pass the codename/id in the preview URL to begin with.

  • Regardless of all the different types of content-editing scenarios, I just don't think it makes sense to be using something as an identifier that is both optional and not guaranteed to be unique.

    Every item in the inventory has a unique codename by default so it seems like an obvious choice for a macro.

  • adamadam Member ✭✭

    Completely agree with Sam.

  • adamadam Member ✭✭
    edited December 2017

    It also doesn't make sense that we can't configure a "link to" button for published items... whether or not it's the existing "preview" one, or if we have to configure several of them for differently configured delivery channels.

  • JanL@kentico.comJanL@kentico.com Czech RepublicMember, Administrator, Kentico Staff admin
    edited December 2017

    Hi @AdamWeigold , hi @SamPisansarakit ,

    Thanks for clear explanations! I've put them to our product board.

    BTW, the sitemap/URL slug combo is an interesting solution.

  • Just to echo what's already been brought up, it would be really helpful to have a way to easily preview the published content page with a button click in the same way as what's available for draft content with the preview button.

Sign In or Register to comment.