Ship a clean Neos base distribution without a demo package?

Creating Neos & Flow Code
21

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?

22

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

23

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.

24

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.
25

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

26

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.

27

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. :smile:

28

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