[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:
Rename the siteDefinition demo-project to demo-project-test and restart
The system is not reachable anymore.
(the siteDefinition demo-project-de is extending the demo-project which doesn't exist anymore).

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.

Generated at Mon Feb 12 01:48:03 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.