TYPO3.Neos

Patch set 2 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/8931

I've added to that google doc about the pre-setup install script (that downloads/initializes a flow3/typo3 phoenix distribution): Make the install script so that it can be automated from the command line, as well as running in the browser. CLI for more cloud environments especially corporate environments. Web install for shared hosts, and mom/pop shops.

In other words: make the installation friendly to enterprise customers as well as small businesses and even personal websites. If people can use it at home, they're more likely to learn to love it and start a ground swell of support from within the corporate environment. That's one reason WP is so popular - lots of people use it at home for personal sites, and then they recommend using WP when it comes time to build a site in their org.

I think an ideal basic installation should take about 5 minutes. That includes the initial setup wizard. So, people should be able to get a basic, mostly extension-less Typo3 Phoenix installation, running with a barebones functional website, in about 5-10 minutes. (Some fudge room could be acceptable for bandwidth considerations or download time - so, that's 5-10 minutes of active effort on the user's part.)

Make the install and setup process fast, so that the first impression of Typo3 is, "Wow, I like this", or "Wow, that was fast, so my website will be fast!" (first impressions aren't always logical... But they color your view of the product for the rest of the evaluation process)

I agree to jacobs ideas!

Some more ideas after talking to Aske:
We need to keep the number of required steps as low as possible. So I suggested to have the language defaulting to English and have a language selector on each step. Also the "requirement check" should be skipped as soon as all vital checks pass - on the last page (post-setup) you could get a nice overview of possible next steps ("You're done, go to the [website], [advanced setup options], ... and there are [3 warnings & 5 recommendations]") warnings & recommendations could be a separate module (usable for FLOW3, too) that is equal to the System report in v4.
For a slick Web interface we should make use of AJAX where possible (e.g. you enter the db credentials and the db selector gets active as soon as the connection was established successfully). The CLI based setup is important too, but could be postponed to a later sprint IMO.

Some technical ideas:

• The steps are configured via YAML and are extensible
• Each step is one Form (form factory or YAML based form definition)
• The controller knows the context and executes the required step
• Steps can define requirements. A requirement could be implemented by a simple PHP class. One example is a "DatabaseConnectionRequirement". If a requirement is not met the controller needs to jump to the previous step until all requirements are met (this needs some more thoughts)

We have a working setup atm. I think we should postpone making it smoother..

OK I just checked what needs to be done in order to test the setup:

1. checkout f.e. the Flow3Org Distribution
2. place https://gist.github.com/2006620 in Web/setup.php
3. move TYPO3.Setup package from Packages/Application to Packages/Framework

Then, call setup.php and follow the instructions.

For me it fails with "( ! ) Fatal error: Class 'TYPO3\FLOW3\Utility\Files' not found in /Volumes/data/htdocs/Flow3Org/Packages/Framework/TYPO3.Setup/Classes/Core/Bootstrap.php on line 184"

This is totally reasonable as the autoloader is not yet active at this point....

How has this ever worked? :-)

Greets, Sebastian

after fixing the above issue by adding require_once(__DIR__ . '/../../../TYPO3.FLOW3/Classes/Utility/Files.php');
I needed to add a setup route:

-
  name: 'Setup'
  uriPattern: '<SetupSubroutes>'
  subRoutes:
    SetupSubroutes:
      package: TYPO3.Setup

• On the first hit of the setup tool, we see a password such as "8lsPbLSf" -- it needs to be copied and safely stored.
• The database setup screen is still a little weird -- after entering username and password there is no way to reload it in order to select the database
• When clicking submit and the migrations are executed etc, it would be great to show an intermediary screen telling the user what is happening. else it just takes long and there is no user feedback.
• error messages in setup should be styled with red background
• Message: "No site packages were available, make sure you have an active site package"
  • can be fixed by adding

    <categories><category>Site</category></categories>

    to package.xml

Sebastian Kurfuerst wrote:

Thanks for testing & reporting.

1. checkout f.e. the Flow3Org Distribution
2. place https://gist.github.com/2006620 in Web/setup.php
3. move TYPO3.Setup package from Packages/Application to Packages/Framework

I'm still not very happy with the additional "setup.php" because we have to add & maintain it in all distributions and it requires the user to call "/setup.php". Also the setup currently requires a special Route and we decided that a global, always working, fallback route can't be the solution.

I didn't join the Setup efforts lately (sorry for that) and you might have completely different plans, but what do you think of following approach:

• The core bootstrap gets a mechanismn for the very fundamental requirements - those checks are only executed on the first hit (the bootstrap could create a "REQUIREMENTS_CHECKED" file and check for its existtence ,or similar)
• The setup package registers a RequestHandler that takes over when some argument is present (e.g. ?__typo3.setup[step]). Redirecting to a setup step (for instance when no db is setup) would be as simple as a UriBuilder::uriFor() call. The performance hit due to the additional isset() check in the RequestHandler is neglectable IMO and also, the TYPO3.Setup package could deactivate itself after the last step.

Do you agree?

• The database setup screen is still a little weird --
  after entering username and password there is no way to reload it in order
  to select the database

I'll work on a custom FormElement for this one asap!

Bastian Waidelich wrote:

• The core bootstrap gets a mechanismn for the "very fundamental requirements" [...]

BTW: This mechanismn could also try to determine the "phpBinaryPathAndFilename" as Aske implemented it once: https://gist.github.com/2358452

Agreed. This is simply too epic.