- Aliases are stored one DB row for each part of the path, eg. /planes/passenger/jumbo will be stored in 3 DB rows.
- key for the ezurlalias_ml table is composite (parent, text_md5)
- Creating custom alias reuses existing autogenerated rows and creates NOP rows if necessary.
- Autogenerated alias is an alias that is implicitly created for the Location.
- NOP rows are "inert" - they do not point to anything, paths that point to a NOP row are not generated by the system and if user tries to load a path pointing to NOP row redirect to root Location will be performed.
- NOP rows can be reused - if Location is published on the same level and with the same name, NOP row will be reused. This will not affect custom alias that originally created NOP row.
- When Location is moved this is what happens with URL aliases:
- Alias for the Location is created under new parent.
- Old alias for the Location is marked as history.
- Subtree of the Location is reparented, meaning all 1st level children aliases are updated to have newly published alias as parent.
If Location is moved under an other Location under whose NOP entries exists that mirror the subtree aliases under a Location the is being moved, a conflict will happen when reparenting. The reason is id is already occupied by the NOP row.
This could be solved by replacing or amending reparenting logic with publishing aliases for the Locations in the subtree that is being moved.
This would be quite complex and in some cases DB intensive. Also, in some cases aliases of Locations in the subtree would be changed due to conflicts with custom aliases existing there.