Simple Installation

[nilshoerrmann]

In #9, John is writing:

One of the great things about Symphony is the ease that comes with installation; A website owner can just drop the package into their root http folder and hit up /install in their browser and get on with it.

Years ago when Symphony 1 was around this was even more simple: you just had to upload one single PHP file that fetched everything else from the main Symphony server. The process made sure that the users got the latest up-to-date code and that no files where missing. Additionally, Symphony 1 offered extension updates from the interface. The concept was canceled later on due to some technical issues, but that was still in the age of PHP 4. This idea emphasised Symphony's focus on simplicity so I was just asking myself if something like this would be possible again in Next?

My fear is that the usage of Git, Composer and Laravel created or will create additional barriers for new users – and they already have to deal with XML and XSLT. We should stick to the old Symphony concept of providing a good user experience, something that is easy to understand – and in this context it won't help that we have a really simple interface if the users can't install it easily.

Possible or not, I just wanted to throw that old idea in the ring again.

[iwyg]

We have to develop a system that is capable of fetching and installing packages even if composer is no option (e.g. on shared hosts). So basically a user can decide to install Symphony via Git and Composer or as a tarball package. The package installer could be something like Typo3's extension repository (for those who don't know typo3: you can install extensions directly from the admin interface).

[nilshoerrmann]

Following the "mobile first" terminology, I would love Symphony to adapt an "easy first" approach where more advanced features are added "responsively" based on the user's skills. This implies that we should start with the "easy first" concept and add the professional features on top of it (and not the other way around).

We should focus on the users and not on the skills of the working group members and core developers.

[ijy]

In terms of an install wouldn't it pretty much always be the same? What other professional features could be added at the time of install which wouldn't be separate extensions?

[iwyg]

@nilshoerrmann Same here. What do you refer to as professional features?

[nilshoerrmann]

I consider Git and Composer as something "normal" users should not be forced to use and know anything about. Both are professional developer/programmer tools, nothing a web designer needs for his work.

So I'm thinking of designers that need a CMS: they will have to learn XSL already but that is conceptually similar to HTML and CSS which they are used to. A web designer should not need advanced PHP and Apache skills to set up Symphony. He should not be forced to use the Terminal.

[designermonkey]

Composer can be added to our repo as a .phar package, and our installer can be the script that runs it and gets all the dependencies, or am I missing something?

[iwyg]

not sure if you can utilize composer.phar without the commandline.

[iwyg]

@nilshoerrmann we won't add these ”features" on top of it. They're there right from the beginning.

[nilshoerrmann]

How should a script run Composer files on a shared host? Will there be a Git only solution using submodules or something?

[iwyg]

Given it is possible to execute a composer command without the commandline it still would need git to be installed on the host system.

[designermonkey]

Ah, I see yes. My bad for staying up till 2am chatting to @brendo, makes me a sleepy man.

We will definitely need a full package to download then, and the lighter version for local setup with composer and git.

[nilshoerrmann]

@iwyg I just have the fear that the team forgets about users that don't do programming. Composer might be a dream for devs, it's black magic to me that I don't want to learn. I'd like to focus on design (for my contributions and my work).

Das Einstiegslevel muss niedrig sein, die Hürde, Symphony zu nutzen klein. Das müssen wir hinkriegen. Zur Zeit steigt in den Diskussionen hier das benötigte Fachwissen immens und es gibt ein Ungleichgewicht in Richtung Programmierung was die Projektaufstellung angeht. (Sorry for the German).

[ijy]

Hmmm I see. So it would need to be split into two separate installer options? That may be confusing but I guess if it's made clear enough with emphasis on the lighter version by default then it wouldn't be too much of a problem.

Are shared hosting environments likely to have those pre-requisites installed and up to date by default?

[iwyg]

@nilshoerrmann I fully understand your concerns. I'm just trying to say that I wouldn't consider git and composer as features as they are both tools we are using for development and deployment. Handling package installation on the final product is whole different story. The biggest obstacle here is how to handle cross dependencies on different packages without tools like composer. One solution to that would be a integrated package installer (like the one in craftcms or typo3).

[iwyg]

Hmmm I see. So it would need to be split into two separate installer options? That may be confusing but I guess if it's made clear enough with emphasis on the lighter version by default then it wouldn't be too much of a problem.

Yes I think there will be two packages. The "full" package and the composer package where the "full" package is just a different branch that is build by the ci-server. So basically the installer would be the same in both cases.

Are shared hosting environments likely to have those pre-requisites installed and up to date by default?

I guess most entry level shared hosting solutions won't have neither shell access nor git.

Some will offer them on their more advanced premium hosting packages like this one: http://all-inkl.com/webhosting/premium/ but I think most of the time clients will choose the cheaper ones :)

[bernardodiasc]

Agree with @nilshoerrmann concerns. Even if the development version works with all this dev tools, the final product need to be, in the first date, a simple zip package, that you extract in the server and run a installer script. As it is done today. The git+composer need to be the alternative version, not the opposite.

[jonmifsud]

Most shared host wouldn't have shell or git. for some small sites this is a preferred option.

You have also got to keep in mind 'simple' end users, and what they're doing on their local machine. When I started out I had never installed/used git. Whilst this wasn't a problem to pick up when I needed it; it would have been an extra obstacle to install & set up the first time.

If you had to say installation is an easy process; but maybe updates & extension installation would require git it would be different to saying git is required. I still think if we're going the extra step to provide easily-installable extensions we should also support tar/zip downloads directly from github when the machine does not support git.

On 6 May 2013 13:26, Thomas Appel notifications@github.com wrote:

Hmmm I see. So it would need to be split into two separate installer options? That may be confusing but I guess if it's made clear enough with emphasis on the lighter version by default then it wouldn't be too much of a problem.

Yes I think there will be two packages. The "full" package and the composer package where the "full" package is just a different branch that is build by the ci-server. So basically the installer would be the same in both cases.

Are shared hosting environments likely to have those pre-requisites installed and up to date by default?

I guess most entry level shared hosting solutions won't have neither shell access nor git.

Some will offer them on their more advanced premium hosting packages like this one: http://all-inkl.com/webhosting/premium/ but I think most of the time clients will choose the cheaper ones :)

— Reply to this email directly or view it on GitHubhttps://github.com/symphonycms/symphony-next/issues/10#issuecomment-17476794 .

[nilshoerrmann]

We should follow the principles of adaptive design: Having a basic version that we enhance based on the features offered in the server and browser environment.

[brendo]

I think something that is soley missing from the Composer discussion is exactly why it's critical to Symphony. Something better than just because it's part of Laravel. Personally, I see benefits, having a dependency manager means we can pull in other libraries and what not that are considered dependencies of Symphony's installation. The fact it will generate an autoload file is also helpful. I could very well see us using Composer to manage extensions instead of git submodules (but that's a conversation for another issue).

But then again, I don't want have the userbase to walk away because they don't have a clue what Composer is. The fastest way to make people walk the other way is to throw up a barrier in installation. Composer is a barrier before installation, which is even worse IMO.

@iwyg, you come from a heavy development background (if I'm not mistaken), so using Terminal and Composer is second nature to you. You're also very lucky to have access to top class servers and being able to really sell the client on a quality shared host if that's not possible. A wide portion of Symphony's use base does not have these skills or this fortune, so it's our responsibility to try and fill the gaps and make things simple where we can.

I'm not saying we get Next working on PHP5.2 on some obscure Windows hosting, but I am saying like @germchaos said, we should be able to install Symphony in a way very similar to what we do today. That might not be the only way to do it, but it has to be an option (and not one you have to jump through thirty burning rings of fire to complete).

The same goes for the rest of Laravel's Artisan functionality. It's not in our best interests to assume that everyone is capable (or happy) with switching between a UI and terminal to get the site going. Again, I'm not saying it shouldn't be possible from command line (it's actually very cool and opens up a lot of opportunities), but it cannot be ignored from a UI perspective. If we ignore it at a UI level now, we'll have conceptual issues later down the track when our UI is not flexible/powerful/extensible enough to deliver a top notch experience.

[iwyg]

@brendo @nilshoerrmann please don't get me wrong. I'm totally with nils here. We have to make sure that symphony stays a "normal" CMS in terms of "download it, install it". That's why I've proposed to have something like a in-system extension repository.

[brendo]

Ah right, miscommunication then :D

:dancers:

[nilshoerrmann]

With Next we should finally switch to German as our main language - that will make things a lot easier :P

[nilshoerrmann]

(Also known as GDD: German driven development ...)

[iwyg]

That didn't end well the last time.

[nilshoerrmann]

And that was not how I meant it.

[TheJester12]

I'm in agreement with Nils. With all this talk of Laravel I wanted to play around with it and try to learn. I'm primarily a designer with a little bit of ability to hack around in PHP. Composer completely confused me and I had to ask a developer friend to help me out. A simple Zip file should be an option.

[designermonkey]

Ok, so we need to release a fully 'packaged up' Symphony, with all of the composer stuff run and deployed by the dev team, and the only install to do is as we currently do which is to configure the system.

That sorts this out then :)

[iwyg]

pretty much

[nilshoerrmann]

Coming back to my initial idea borrowed from Symphony 1:

Instead of a "fully 'packaged up' Symphony", it would be quite neat to only have a single file that you upload to your webspace. This installer would load all needed files dynamically from the Symphony server that would fetch everything from Github live, also running the Composer/Git/whatever stuff (could be cached of course).

Advantages:

• Only having to upload a single file is easy and fast. That one file could just guide the user through additional required steps (like setting permissions etc.).
• Packaging would not have to be done manually, we wouldn't have to create a ZIP file with each release.
• No need for terminal/Git/Composer access on the user's webspace.

[iwyg]

Packaging would not have to be done manually, we wouldn't have to create a ZIP file with each release.

Sorry for being technically again but we would't do the packaging manually, the buildserver (maybe travis) would do all the work.

Only having to upload a single file is easy and fast

I'd rather see this as an alternative to uploading the whole package. Although this may come with a downside as you would have to configure your root directory twice (given johns structure proposal isn't working out).

[designermonkey]

given johns structure proposal isn't working out

Isn't it?

[iwyg]

I don't know. I haven't tried it yet :)

[jensscherbl]

Would it be possible to design the system in a way where installation is only needed to create the initial database structure? Where I can just throw everything in my project folder (either manually or from cloning the git repository), init the database, develop locally and push everything on production over SSH?

[iwyg]

I was thinking about having the choice between easy/expert installation would be great. Also cli installation php symphony install:config url/to/config.json

[designermonkey]

CLI installation would be super cool for automated setup of new projects. I was imagining the default setup to be like it currently is; The app is already configured, it's just a matter of installing the R&B and add the symphony config in.