+1 for the solution of a deactivated demo package or showing an information when creating a new site package that the demo package should be deactivated.
if there is a way to have the demo package deactivated from the start this would be a very good solution, but imo just giving a hint to deactivate it before creating a new site is (maybe) another barrier that should not be there. More like an opt-in option to activate then an opt-out option to not use it 
For 2.0 kickstarting a package deactivates other packages, unless there are still unmerged changes in review…
That sounds great and I think this is the best solution. Deactivating the demo package per default would create a barrier for everyone who wants to give Neos a first try. So having an automated deactivation sounds great.
Hey,
Ack, I thought we implemented that on the last code sprint in Rosenheim? Or am I wrong? 
So it is maybe a communication issue on the website etc. @lordrhodos maybe do you want to create a FAQ entry explaining this? That’d be great 
Greets, Sebastian
I will try this myself so I know what I write about and then I happily provide a faq entry or documentation about it. @sebastian Where to you want to have the initial text posted?
Hey Patrick,
I’d say just try to write a FAQ on https://discuss.neos.io/c/faq – I’ll happily read over it then 
Greets,
Sebastian
Hi @kdambekalns,
I’ve created a new site on a blank beta2 system, but I can not confirm that the demo package gets deactivated. Any idea what changes could still be unmerged?
1 Like
Hey Patrick,
Thanks for verifying!
the change was https://review.typo3.org/#/c/38054/ – but it has not been ported to the 2.0 branch as far as I can see. Possibly because it was tagged “master” only (as when the change was created, the 2.0 branch did not exist yet).
So, we should backport this to 2.0. Agreed, @kdambekalns?
Greets,
Sebastian
4 Likes
I thought it was meant for 2.0 too… So +1 from my side for backporting
Not related to this issue, can can we add a rules to use the “Like this post” button to replace the +1 reply style ?
2 Likes
Backported & merged. Thanks for noticing. Checked if there were other changes targeted for 2.0, but only in master and didn’t find any. There is some translation stuff, but that’s a different story.
1 Like
The changelog says:
[Bugfix] When a new site is created in Sites module, deactivate others. …
Now, if one wants to host multiple site packages, adding a new one breaks all other sites, and one needs to re-activate all other packages again.
And what if one actually wants to build on and extend the continiously developed demo site package? Re-activating the demo-site package after creating a new package may not be enough, as nodes are created without the demo site configuration.
Isn’t there maybe a way to limit the package settings to the related site scope? If desired, settings may be shared by symlinking files into selected other packages, or into the global configuratioon directory. Or by php includes?
Hey Chris,
yes, that would be the best solution; though this is technically very non-trivial: The settings are Flow settings which are (currently) global, and the concept of a “Site” is much more high-level. At the point where the concept of a “Site” comes into play, we rely on Settings being already available.
Because of this, we did not implement this feature so far; and I am not so sure how to do it cleanly.
All the best,
Sebastian
Thank you for the explanation Sebastian.
My naive thought looking from outside: Can’t site specific configuration be moved to a place that is not automatically read by the Flow framework? Instead, load that configuration from within Neos, where the site concept is known and when the requested site is known?
Edit and afterthought: Hm, the node definition probably needs to be global?
And that brings me back to my problem of extending the demo site definition, or any other site package, with a custom site package definition. The current auto-deactivation of other site packages breaks the setup whenever a new site package is added. How can users do this in order to test and share improvements?
Are there dependency definitions? The neos package kickstarter may then default to create site packages that conflict with the demo site package.
Is it at all possible to have a site package that extends another site package?
I tried to extend the demo site like this: Created new package, re-activated the demo package, and commented out the the page = Page {…} definition in the new package’s root.ts2 in order to use and start with the typoscript of the demo package. However, I still get:
Uncaught exception #1332493990 in line 227 of /html/neos/Data/Temporary/Development/Cache/Code/Flow_Object_Classes/TYPO3_TypoScript_Core_Runtime.php: No TypoScript object found in path "landingPage"
Please make sure to define one in your TypoScript configuration.
It won’t include the TypoScript of the other site package automatically.
You either have to include it in your site package or add the other site package to the auto include.
Like
include: TYPO3.DemoTypo3Org/Prototypes/Document.ts2
or
I think the demo site package is absolutely vital for learning.
However, for learning how to set up a your very own website, the bootstrap demo-package is way too convoluted.
Instead I’d propose to include a demo package that showcases the most important neos features, but with a minimum of design and configuration.
Optimally, every page that showcases a neos feature would also be a tutorial page for that feature, explaining which files you’d have to edit to achieve the result you are seeing.
Thanks, I learn: The package separation works very well, it is just the packages’ configuration that is global by default, but still overrideable to what is needed in the local installation.
The include line caused a file not find error for me, but I was succsessful with your hint to configure the autoincludue.
Mind you that I don’t have any deeper knowledge of Neos, you barely teached me to extend the demo package, but maybe the current demo package could be split into a site package and individual feature packages.
The feature packages may contain functionality that is not part of the base distribution: like bootstrap-classing, front-end-login, book-paging-chaptes, …
And the demo site package may then contain nodes with tutorial example content?
(depending and including from the feature packages)
Maybe this could also lead to good practices that shows users how to collaborate on a repository of nicely combinable feature packages.
Edit:
Maybe it is even more advantageous to also have a separate site packages for each feature package. Allowing users to keep selected feature site packages activated to use their style definitions etc. in their own site/domain (without the tutorial nodes).
Maybe the overall demo site package would then just provide some general pages and a way (shortcuts?) to browse all the installed feature packge tutorials.
1 Like