!!! TASK: Deprecate additional site kickstart generators and show helpful output for default afx case

[mhsdesign]

Follow-up to https://github.com/neos/neos-development-collection/pull/5136

By default (if only the package is installed) no further question will be asked and with AFX proceeded. Additionally we can hardcode the suggestion to import the new homepage from Vendor.Site:Document.Homepage etc.

neos-manufacture-90 git:(9.0) ✗ flow kickstart:site Vendor.Site
Created .../Document.Page.yaml
Created .../Document.Homepage.yaml

Create a new site based on the new package "Vendor.Site" by running the site create command
./flow site:create vendor-site Vendor.Site Vendor.Site:Document.Homepage

The reason why i think we should deprecate this extension point is that we have a lot of YAGNI extension points and there are no usecases that im aware of.

The possible future of kickstarters

But i do love kickstarters and think Neos should provide good ones to start with. A good idea would be to see what @mficzel and @nezaniel did with https://github.com/sitegeist/Sitegeist.Noderobis. I think these more fine tuned kickstarters with much more input are way more useful then trying the impossible to kickstart a full site from scratch with one cli command. The current practice is using a template repository and cloning from that base distribution and composer create project should probably be adjusted to offer a few choices https://github.com/neos/neos-base-distribution/pull/42.

Upgrade instructions

Review instructions

Checklist

• [ ] Code follows the PSR-2 coding style
• [ ] Tests have been created, run and adjusted as needed
• [ ] The PR is created against the lowest maintained branch
• [ ] Reviewer - PR Title is brief but complete and starts with FEATURE|TASK|BUGFIX
• [ ] Reviewer - The first section explains the change briefly for change-logs
• [ ] Reviewer - Breaking Changes are marked with !!! and have upgrade-instructions

[kitsunet]

We call Neos a Content Application Framework, I think a "YAGNI" extension point that you do not use might very well be useful for someone else, we should be quite careful with just declaring everything YAGNI and removing it. I don't think it will do us good. Some wild extension points have helped me realize a feature for a project that otherwise might have been a "we can't use neos here" decision.

That said, I can probably agree that this is not it. Martin and I came up with this when the kickstarter was still the place to be, and not much manifested from this AFAIK, so yeah, lets remove this, but still be wary of that YAGNI argument when it comes to extension points.

[mhsdesign]

Just learned the YAGNI term from basti and wanted to see what power it holds to be applied :D

[ahaeslich]

Hm, I think declaring this extension point as deprecated might be a bit premature if we don't have a clear vision what this package will do in the future and why we are removing this extension point.

[mhsdesign]

if we don't have a clear vision what this package will do in the future and why we are removing this extension point.

i think we will go into the directions mentioned above in section "The possible future of kickstarters" ... and by not providing this extension-point, we can go there more easily.