Can we get codename made available in preview URLs?

SamPisansarakitSamPisansarakit Member
edited November 24 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

  • petrsvihlikpetrsvihlik 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.

  • petrsvihlikpetrsvihlik 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}

  • petrsvihlikpetrsvihlik Eindhoven, NLMember, Administrator, Kentico Staff admin

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

  • 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.

  • aweigoldaweigold Member
    edited December 2

    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.

Sign In or Register to comment.