Details
-
Bug
-
Resolution: Duplicate
-
Low
-
5.0, 5.1
Description
Context:
- Aliases are stored one DB row for each part of the path, eg. /planes/passenger/jumbo will be stored in 3 DB rows.
- 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 name of the Location is changed, new alias is created for the new name and alias for the old name is marked as history.
Problem:
If Location is created that reuses NOP row of the existing custom alias and its name is then changed, custom alias will also be changed.
Note: as history is maintained and how hierarchy is implemented, original custom alias path will still be loadable, however in the administration interface changed name will be shown.
Attachments
Issue Links
- relates to
-
EZP-20773 Legacy Storage URL alias design problems: deleting Location potentially destroys custom alias
- Backlog
-
EZP-20775 Legacy Storage URL alias design problems: moving a Location (subtree) resutls in conflict
- Backlog
-
EZP-20728 eZRest v2 : Some (unknown) REST call corrupts the database and make MoveSubtree call fail
- Closed
-
EZP-26097 404 error if you rename your content in a multilingual site without "default object availability"
- Closed
-
EZP-23042 Doc: Urlalias history removed for an existing translation when updating content
- Closed