The Pretty URL interface is currently in beta mode.
Fluid Topics v3.7.28 introduces the Pretty URL interface, where users with the ADMIN, KHUB_ADMIN and BETA_USER roles can configure a rule engine that automatically generates pretty URLs for documents and topics.
Selecting Administration > Knowledge Hub > Pretty URL displays the Pretty URL interface as follows:
Where:
Configuration is a matter of entering metadata and, if desired, adding static text. For all rules, it is necessary to place metadata inside brackets. For topic rules, it is necessary to reference the document's metadata with the "document|" prefix.
In order for Fluid Topics to propose a pretty URL when users select the Share URL action button, it is necessary to define a rule at the topic level.
If a field turns red when entering text, this indicates that the text is invalid (e.g., missing character). The field turns blue when the text is valid.
There are no restrictions as to which metadata administrators can include in a pretty URL. To separate sections, valid characters include a dash (-), an underscore (_) or up to 9 slashes (/). Fluid Topics does not accept the symbols #, ?, [, or ] when adding static text.
Only content with all the metadata defined in the rule engine will have a pretty URL.
The Fluid Topics pretty URL generator takes into account the first metadata value indicated for each metadata key. For hierarchical metadata, the generator takes into account the last value of the first branch of the hierarchy. It is currently not possible to enter multiple values for the same metadata.
If an administrator defines a rule in the Pretty URL interface and then modifies this rule at a later date, this is likely to break pretty URLs which were automatically generated prior to the modification.
Defining rules to automatically generate pretty URLs does not override any existing pretty URLs that were previously defined by means of a control file, a source document, or a web service.
Selecting the Save button displays the following pop-up:
Reprocessing can take a considerable amount of time if a lot of content has been published to the portal. Any content a user uploads while a reprocess job is underway is queued and processed after the reprocess job is complete.