Removing Installation Application (Directory)

[Nils Rückmann]

At the end of Joomla installation we are still announcing the need to remove the installation folder (INSTL_COMPLETE_REMOVE_INSTALLATION), but that's not true. 

What's the expected behavior ?  Dropping the announcement or adding a check on start-up ? 

[Michael Babker]

If you're working from the git repo, the check for the install directory is not enforced (in part to keep from having issues galore with patches submitted that might remove it).  It is a requirement with tagged production releases.

On Sun, Mar 15, 2015 at 2:07 PM, Nils Rückmann <ma...@nueckman.de> wrote:

At the end of Joomla installation we are still announcing the need to remove the installation folder (INSTL_COMPLETE_REMOVE_INSTALLATION), but that's not true. 

What's the expected behavior ?  Dropping the announcement or adding a check on start-up ? 

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

[Nils Rückmann]

Hi Michael, thanks for reply. That explains a lot. But should we not try to find a better solution ? I mean preparing releases should be as easy as possible.

[Phil-Taylor.com]

borrowing from Zend and other frameworks, they can look for Environment Vars (prerelease|development|production etc) with getenv() etc.. 

It should be assumed, I guess, that a developer coding for Joomla, using git, etc, should be able to set the APPLICATION_ENV kind of environment var correctly in apache/nginx/htaccess

This could mean that if the APPLICATION_ENV is set to “prerelease” then the installation folder check is bypassed.

This could then mean that the core code needs no changes for preparing and deploying releases.

This could introduce correct APPLICATION_ENV switching of configurations for staging/development/production versions of Joomla and could open a whole new feature set, and custom extensions, for Joomla etc… 

[Phil Taylor]

borrowing from Zend and other frameworks, they can look for Environment Vars (prerelease|development|production etc) with getenv() etc..

It should be assumed, I guess, that a developer coding for Joomla, using git, etc, should be able to set the APPLICATION_ENV kind of environment var correctly in apache/nginx/htaccess

This could mean that if the APPLICATION_ENV is set to “prerelease” then the installation folder check is bypassed.

This could then mean that the core code needs no changes for preparing and deploying releases.

This could introduce correct APPLICATION_ENV switching of configurations for staging/development/production versions of Joomla and could open a whole new feature set, and custom extensions, for Joomla etc…

> On 15 Mar 2015, at 18:34, Nils Rückmann <ma...@nueckman.de> wrote:
>
> Hi Michael, thanks for reply. That explains a lot. But should we not try to find a better solution ? I mean preparing releases should be as easy as possible.
>

[Michael Babker]

Preparing releases is easy.  Even this is in commenting two checks in two files that are otherwise never touched.  Yes the check has no meaning outside of tagged releases, but I don't think that we should introduce a lot of overhead into what is currently a set of simple checks (install app always display the prompt and the main app framework checks if installation/index.php exists).

On Sunday, March 15, 2015, Nils Rückmann <ma...@nueckman.de> wrote:

Hi Michael, thanks for reply. That explains a lot. But should we not try to find a better solution ? I mean preparing releases should be as easy as possible.

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

--
- Michael

Please pardon any errors, this message was sent from my iPhone.

[Michael Babker]

As far as the environment vars go, this would be seen as a barrier to contributing.  Same as if we used Composer the "one right way".  Whatever method chosen needs to be foolproof enough for the newest of contributors to the most experienced of developers to set up and run with.  This also includes someone consuming a nightly build or a ZIP file as prepared by GitHub.

That said, I'm not opposed to using env vars in the application.  But doing so should not make it more difficult to get up and running.

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

[brian teeman]

As always "what is the problem you are trying to resolve" and is a proposed solution making things easier or harder.

For me this is a complete non issue and the "solution" just makes life harder for contributing

[Phil Taylor]

So we should not implement the “correct” way if it means we have to educate those that want to contribute a little more? There is already massive barriers to contribution, like the running of tests locally, code style, translation, politics, git… adding a professional feature such as environment aware code (that defaults to production anyway) is NOT a barrier to entry.

Almost every professional PHP Product is environment aware - its doesn’t create barriers to contribution anywhere.

There is nothing special about having

configuration.php
configuration.development.php
configuration.staging.php

We already have a method to overrule the Joomla defines.php, well this would just build on and improve that.

Yes this is probably overkill for the “installation folder in prerelease” but still is a worthwhile feature to be added to Joomla for all so many other great reasons.

In-fact I already do this for Joomla in MAMP - it takes ONE line
http://screenshot.myjoomla.io/image/1j3o3y1f0b0y

There are wordpress attempts: https://github.com/studio24/wordpress-multi-env-config

There are Zend Framework APPLICATION_ENV

Drupal can be environment aware with its "multi-site configuration”

Code Ignighter has excellent ENVIRONMENT configurations

Symfony has the SF_ENVIRONMENT

Im not saying this is "The solution” - I’m saying there is no reason why we cannot improve Joomla to become more environment aware, and provide a great way of deploying Joomla sites through the complete lifecycle - just the way other major successful PHP frameworks do.

Kindest regards
Phil.

> On 15 Mar 2015, at 19:55, brian teeman <joom...@googlemail.com> wrote:
>
> As always "what is the problem you are trying to resolve" and is a proposed solution making things easier or harder.
>
> For me this is a complete non issue and the "solution" just makes life harder for contributing
>

> --
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

> To post to this group, send an email to joomla-...@googlegroups.com.

[Michael Babker]

I'm not saying we shouldn't have the possibility for environmentally aware configs, for example.  I'd just suggest that if implementing it, it does not make it harder to contribute.

As for your list of barriers, many of them are non-issues for a lot of folks.  If you know the file that needs edited, you can make changes right in GitHub and submit them as pull requests; no git knowledge needed and Travis-CI takes care of automated checks.  Politics is an issue because we all make it one and translations, depends which aspect of that we're discussing but I don't see an issue with having high language standards the same way we have a certain code standard.

[Roberto Segura]

If the correct way has some benefits then we can discuss it. But for now we are talking about:

- One person changing files before and after the release.

VS

- Everybody having to change their configuration to start contributing.

I don't see this a benefit itself.

[Phil Taylor]

You don’t see a benefit as you are closed your mind to thinking about this one issue - the installation folder and prerelease code.

Im talking about, I guess, a new feature, which would fix that issue, and create more value than ever…

If you open your mind to the fact that an Environment Aware application is a much better foundation of code, for so many great reasons, then you will start to see why almost every major project has it.

There is absolutely no reason why adding environment specific configurations to Joomla should - at all - create any barrier to contribution.

We already have defines.php overridden, we already have debug, language debug, logging, caching, template module positions preview, and so much more that could all be incorporated into environment switching.

Still nothing stopping someone going to github and modifying that one file they way

Still nothing stopping people creating PR’s

Still nothing stopping people installing prerelease code locally - if implemented right.

I fail to see how anyone can see environment specific configurations as a bad thing.

Anyway - it seems even if I coded a solution its been shot down by three people already… so thats more of a barrier to contribution than anything :-)

Having worked in code bases that implement this, and in businesses that deploy code to 100’s of servers, with local, development, staging, UAT, prerelease and production environments, I see the value instantly. Each environment has a different database password for a start...

> To post to this group, send email to joomla-...@googlegroups.com.

[Roberto Segura]

Not a closed mind but talking about what's being discussed.

If you want to contribute enviromental behaviors I'll be more than happy to see it happen. But that requires a bigger discussion not a fast patch to avoid us to save stuff on releases.

[Nils Rückmann]

Well, i think we are now really of topic. My first question was only because of my lack of knowledge. I think some kind of environment state (no matter if its an environment variable) is something we should implement. Not because of releases, but for deployment reasons. It's really annoying to deploy Joomla in two or three stages (e.g. live, stage, dev).

BUT: This is something which can not be done over night and is more likely for a new major release.

[Nils Rückmann]

+1 Roberto