[MGNLETK-56] MultiSiteFilter: renaming a siteDefinition will break site-definitions extending it, resulting in system start up failure Created: 03/May/11 Updated: 09/Oct/12 Resolved: 09/Oct/12 |
|
| Status: | Closed |
| Project: | Extended Templating Kit (closed) |
| Component/s: | multisite |
| Affects Version/s: | 1.4.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Christian Ringele | Assignee: | Unassigned |
| Resolution: | Obsolete | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Date of First Response: |
| Description |
|
When renaming siteDefinitions it can easily happen, that you have an extends of an non existing siteDefinition. Reproduce: The class should be changed, that it uses in such a case the default siteDefintion as a fallback. |
| Comments |
| Comment by Boris Kraft [ 03/May/11 ] |
|
Maybe if we change a name, the dependencies should stay intact? In other words extend should reference a node/uuid not a name. |
| Comment by Philipp Bärfuss [ 04/May/11 ] |
|
The developer has to put a path. We can't expect him to work with uuids as it would very cumbersome to analyze configurations. It might be nice if we stored the uuid in the backend instead of a fix path, but then again, if you rename a node to mysite_backup and create a new mysite node we would then use mysite_backup. But for now we have to guarantee a good fallback behavior that one is able to startup the system and then fix the configuration. |
| Comment by Jan Haderka [ 09/Oct/12 ] |
|
Pointing to non existent node will still not allow that node to be used as base for extension, however it no longer results in system startup failure. |