Changing htaccess

[garyee]

Hi,

so as I said in #27 I cloned the master (from my fork) for development. Thing is, that I had to make changes to the .htaccess file in order to make gitlist work. Git naturally picked up on those changes and wanted to commit them, which would not be good.
As I see it when getting the master all should work out of the box, IF one uses the default configuration that is written in the documentation.
So that if one does not use the default config, one would have to change things.
That said, it would be good to have eigther a htaccess that is working for all systems out of the box, or have none by default and have the system work anyways ... IF configuration is default.
And have a .htaccess_default that the user can edit. (and add the .htaccess to the gitignore)

[PABourdin]

I also stumbled on the default .htaccess giving me HTTP/500 errors, because my Virtual Host configuration prohibits having an additional .htaccess. I would prefer to move the .htaccess away to, e.g., .htaccess-example.

Furthermore, one should give also an apache2-vhost.conf example file for all those using this (very popular) Apache2 configuration scheme. Not only because some people block .htaccess globally due to security concerns.

@garyee could you please post your .htaccess changes here or simply edit the master? You were not the only person having troubles with it. Btw. I just want to mention what Silex2 recommends:
https://silex.symfony.com/doc/2.0/web_servers.html

[DannyvdSluijs]

@garyee we are in the process of merging all the forks out there and resolving some frequently reported bugs. Once this is done we can make a stable release. This would be (like the original gitlist a zip file to download and install on the server. This would make the focus of the GitHub hosted files for development.

In the mean time I guess one thing we need to solve is how the different config (Apache 2.2 vs 2.4 or Apache vs NGINX) should be part of the files. It will be difficult to have a single file for each env.
We should make a choice if we will support only mainstream (would be Apache 2.4 I guess) or we support multiple and add some installation script (Similar to how Zend Expressive does the install). This would still not work for development purposes, perhaps the best approach would be to exclude .htaccess (one could say this improves security as the use of .htaccess could allow server config override) and provide a clear wiki with default vhost configuration for Apache 2.2, Apache 2.4, NGINX

[PABourdin]

Here is my current config for an Apache 2.4 virtual host:

<VirtualHost IP:port>
    # other directives and directories

    Alias /gitlist/ /var/www/gitlist/
    <Directory /var/www/gitlist>
        Options -MultiViews
        # other directives
        FallbackResource /gitlist/index.php
        <Files config.ini>
            Require all denied
        </Files>
    </Directory>
</VirtualHost>

As one can see, no RewriteRules or RewriteBase is involved and .htaccess is completely unneeded.
You do not even need mod_rewrite and this is available since at least Apache 2.2.16.
I would propose we use this as the only Apache example.

[garyee]

For me it would be okay to define the (Github) master as development, as one needs to do the "composer install" in order to get it to work and as there is the zip file for those only want to use gitlist.
But it would be better to have the .htaccess on the gitignore and maybe have a .htaccess-default
A apache.conf or nginx config should be in the wiki, as people who are admins of their own webserver usually have the knowledge to configure it(or should be able to understand how the config works)
Whereas for people just using the a webserver by unzipping the latest stable release into the document root, it should work for the default configuration (written in the readme). If they are not using the default config they should not mind deleting some lines and renaming a default .htaccess (which also should be documented in the wiki).

[PABourdin]

@garyee in our yesterday's meeting we have agreed on this procedure and I will implement that soon.