Stream URL Handling Concept

  • URLs for items (product, category, etc.) will be generated on the server exclusively
  • A handler concept will be implemented in PHP to generate and parse back this information from a URL that permits / in some URL parts
  • In order to link to an item (aka its Master Page), it needs to be available and a JS component will simply use the link
  • Generated URLs will still have a predefined format (for example, /.+/p/{sku}) so that the JS router can handle it at least to some degree
  • URLs that have URL parameters (?) will be excluded from SEO indexing by appending a _nocrawl parameter and forbidding this from the robots.txt

Requirements

End-User:

  • URLs should be speaking (nice to read and remember)
  • A URL can be sent to someone else producing the same screen (for example, showing a page with the same products)

SEO:

  • URLs should not only contain an ID but also keywords, e.g.
  • NOT: /p/2744rf438-gu34r8374rfhe5485tgu
  • YES: /sonnenbrille/schwarz/armani/fancy-model
  • OK: /sonnenbrille/armani/fancy-model/p/2744756573473
  • Ideally URLs should be adjustable by the Frontend Manager

Technical:

  • URL must identify a view uniquely
  • Parameters for underlying streams must be encoded in the URL
  • There might be multiple streams in one view so parameters must be distinguished between streams

Base URLs

A URL in Frontastic addresses one of these items:

  • a) Stage node
  • b) Dedicated master page (for example, "cart")
  • c) Master page of a generic item (for example, "product" or "category")

Each of these requires a speaking URL. For a) and b) the URL is simply defined by your Frontend Manager as a config value when creating the corresponding Node. (Hint: A history for URL changes to perform proper redirects may be a good idea)

For c) the situation is more complex because the URLs need to be generated and resolved automatically by Frontastic on basis of the data of the item. In order to allow full flexibility for the implementor when generating the URLs we will implement the following mechanism:

  • Master Page controllers for items match on a specific route that allows slashes in parts of the URL
  • e.g. /.+/p/{sku} for a product (allows /5th-avenue/brillen/damen/schwarz/p/6921103620169)
  • e.g. /.+/c/{identifier} for a category (allows /c/brillen-kinder)
  • Per item, a mechanism on PHP site is registered which performs two tasks:
    • Generate a URL for an item
    • Parse a corresponding API query object from a given URL
  • For each item that's fetched through our APIs we call the first task and inject the URL into the response data that is sent to the client
  • JS components can then simply realize a link by using the link that's already available in the item data (e.g. product.url or category.url or in future content.url)
  • The JS router will still be able to reverse parse the route to instruct a corresponding master-page fetch
  • When an API call to fetch an item from the frontend is comes into the PHP stack, the second task is called to factor the query for fetching the item
  • On the basis of this item, the corresponding master page is then selected and returned
  • Example Implementation

    For example, the mechanisms to generate and parse URLs could be very simple. Your SIM (PIM) will provide each product/category with a meaningful slug in the format  some_thing_fancy and our handling will translate that to /some/thing/fancy/p/<sku> (for a product). The reverse will then create a corresponding ProductAPI query for the SKU.

    URL Parameters

    URL parameters in Frontastic are used to carry around different information:

    • a) Stream configuration additions 
    • b) Page state indicators (prefixed with  _ to not be sent to the server)

    By default, Frontastic will append the parameter  _nocrawl to all URLs with parameters and have URLs with _nocrawl excluded from being crawled by robots.txt. This avoids filter URLs to appear in search indexes.

    Still Open Challenges

    • Multilingual URLs
    • In multilingual projects, we will most probably be required to have multilingual SEO-URLs, e.g.
      • /sonnenbrillen
      • /sunglasses
    • Backstage doesn't support this yet
    • The HTML hreflang attribute should be implemented with this info
    • We currently append parameters to the URL which are part of the current context (e.g. environment). We need to get rid of this.
    • How do we determine if the context differs from default to indicate when such information is required to be added to the URL?

    ‹ Back to Article List

    Next Article ›

    Extension Points

Still need help? Contact Us Contact Us