Ticket #2508 (assigned enhancement)
Hierarchical URLs
| Reported by: | sminnee | Owned by: | ajshort |
|---|---|---|---|
| Priority: | medium | Milestone: | 2.4.0 |
| Component: | (Unknown) | Version: | 2.2.2-rc2 |
| Severity: | high effort / impact | Keywords: | |
| Cc: | Hours: |
Description (last modified by sminnee) (diff)
It has been well established that many people would love to see support for hierarchical URLs in the SilverStripe? CMS. However, it's a very big change and currently no-one has any time to dedicate to fixing it.
That said, it should be included on open.silverstripe.com, and if anyone was wanting to have a go at fixing this properly, I (Sam) would be more than happy to give some technical guidance.
Related tickets
No results
Link visiting
The first problem is that a URL such "staff/wellington" would have two possible interpretations: The wellington action on the staff page, or the wellington page located within the staff page.
There are two parts to resolving this:
- Check for that a given action exists before failing over to a sub-page in the content database.
- When creating a page, use the duplicate checker to forbid creation of a page with the same URL as an action method.
The new URL handler code that is being developed as part of 2.3 will be helpful here.
Link() method
This would be fairly straightforward change; something like this. Caching could be added for performance:
if($this->ParentID) return $this->Parent()->Link() . $this->URLSegment . '/'; else return $this->URLSegment . '/';
Custom code accessing URLSegment directly
The URLSegment method is has sometimes been abused by developers as a way of generating a link without a slash on the end. Additionally, it is sometimes used to make a unique reference to the page for HTML IDs or Classes. For example, by putting "<body id="page-$URLSegment>" in the template.
We could potentially move URL segments to a new variable, and replace the URLSegment database field with a getURLSegment() method that returned a value with similar semantics (such as global uniqueness). However, chances are that sites that using these features are going to require some fixing to get working with the new URL structure regardless.
Perhaps it will be sufficient to create a method such as PageIdentifier?, that returned a globally unique string for identifying a page suitable for using an HTML id/class. (perhaps replacing "/" with "-" in the URL?)
Link uniqueness checking / duplicate resolution
URLSegment will no longer be able to be globally unique throughout the SiteTree? database. Instead, the uniqueness checker will need to rewrite the URL with a suffix if it finds:
- A page with the same URLSegment and the same ParentID
- An allowed_actions on the parent page, if ParentID > 0
- A class named with the name of the URLSegment, if ParentID = 0
Warning about URL change on reorganise page
When pages are reorganised, their URLs will change. We will need a way of warning the user that the page they just moved will have a new URL. A pop-up is probably too intrusive, but maybe a message in the status message area?
Link editing
The link inserter uses a '[/]+/' style reg-exp to identify internal links. This will need to be updated. But it can't simply assume that any link is an internal link. An ajax check-if-page-exists function would probably need to be used instead of a simple reg-exp.
Broken link checking
The broken link checker is only interesting in URLs that have one text part and then a slash. To be honest, the broken link checker is overdue for a major overhaul. It's not reliable enough to be useful.
Others?
There are undoubtedly going to be other issues that don't present themselves until we use hierarchical URL code for a while. We will need lots of testing of all aspects of the application.
