Re-configuration webpage based on htaccess authentication to eradicate "Application Instantiation Error" and connection problems to the database

[DeRaja]

Is your feature request related to a problem? Please describe.

If the configuration.php cannot connect to MySQL database, it shows a white page with the following:

"Error displaying the error page: Application Instantiation Error: Could not connect to MySQL."

The white page for this error is rather primitive for such a advanced CMS system like Joomla. The reason is self-explanatory and logical. Do not require to explain a word more.

Describe the solution you'd like

As discussed in my postings below, I would like to see in Joomla code a possibility to create an admin authentication based on htaccess during the first step of installation, where one enters admin username and password, which shall safeguard /administrator/ directory and, thereafter, allow making changes in configuration.php lying outside the /administrator/ directory.

If - and once during the first installation step - the /administrator/ directory is protected with htaccess, all files under this directory shall also be secure. Thus, there is no security hole opened by this solution. In contrary, it offers the most secured solution and increases security.

I propose the following:

1. To have a Joomla Admin Tools pages based on the /administrator/include/*.php and have htaccess authentication activated at the time of first and initial setup of administrator username and password, that could be invoked by /administrator/index.php without the need of database connection. The htaccess control user, which has a super power to make changes to configuration.php should not be inside the User table.

This means certain codes for Joomla Admin Tools pages that should in in the installation scripts will be the same in the Framework. That coding will manage generation of Joomla Admin Tools pages without a database connection.

2. Once /administrator/index.php returns html views without any database connection, then it should be possible to correct or change database connection parameters.

At the same time, if there is no connection, the core will through a pre-configured page of a database connection error on the front page. That page has to be static and could be saved outside the database.

3. Once /administrator/index.php returns html views with a database connection but the joomla core for administrator does not boot, then it should be possible to activate or deactivate plug-ins and extensions.

Here, the htaccess user will not be inside MySQL user table but inside htaccess file.

The ACL controller will only allow to activate or deactivate extensions and plug-ins and do nothing else. The reason of doing this is to have the core bootable at all times to ensure there is a possibility to deactivate something nasty and accessible from a web interface.

4. The Admin Tools page could also allow changing prefixes and backup of the database.

If the installation is accessible and was once properly installed, the only thing required here is to re-configure the connection parameters in configuration.php. In such a case, there should be a possibility of generating a webpage to re-configure it.

Additional context

In the core, there should be a basic minimal system of having a page for Admins that should be accessible at all times and offer a re-configuration option in these circumstances to do certain basic checks and make changes in configuration file and directory permissions, if certain directories and files are accessible from the web under administrator directory.

If - for example - the /administrator/index.php as well as /includes/* is accessible, thereafter it is just the question to revert session from session=database ---> session=file. Then generate a configuration webpage to setup up certain configuration parameters for connection of database and re-write it.

Of course, one could do this manually through FTP. But if this system is in there, in-built, the configuration could be used for many other purposes like checking file and dir permissions of other directories as well, when such a basic function is available in the core.

When htaccess file is created, which is merely supplied along with installation as a text file, it should also be used to actively protect the /administrator/ directory. Consequently, there is no reason why an administrator should not be allowed to make all changes to configuration.php, run some tools to repair MyISAM corruption, deactivate certain nasty plug-ins that make crashes of the core.

[mbabker]

To normally work with Joomla once it is installed, you have to have the database. Even to get a minimal configuration interface like what you're proposing, because we have to have the data to authenticate and validate your user account to give you access to it. Without that data, any type of minimal configuration interface or recovery system is opening the door to allow a site to be easily compromised or messed with.

So as much as this might be user friendly in case of an emergency, the only way to create this type of emergency system basically compromises every platform security measure we have in place.

[DeRaja]

Dear Mr. Babker,

Do you agree, based on your post above, that Joomla lacks in principle fundamental basic security built-in in the core? Well of course, this is not your heredity.

To normally work with Joomla once it is installed, you have to have the database.

I want to place a counter-argument, while I totally agree to your expression above, is:

"To normally work with Joomla once it is installed, you have to have the htaccess protection in administrator dir."

One of the first thing any installation process in any installation on Linux is to create .htaccess. Since 20 years, after managing Linux administration from 1998 onwards and right from Redhat v3, I have seen that young php coders have shown blatant carelessness to such fundamental needs of security.

Why should an external developer like Akeeba, while that is excellent, develop a possibility of .htaccess in the administrator directory? Should this basic and fundamental function not be done by the core?

One of the issue of having such a re-configuration webpage is also to facilitate such basic security function of creating .htaccess file.

Because this creation of .htaccess file should be run EVEN BEFORE mySQL database connection parameter, it should be done within the initial configuration, where one enters admin username and password.

But if this was never implemented, should we not discuss about that necessity and give a thought to it as well?

Even to get a minimal configuration interface like what you're proposing, because we have to have the data to authenticate and validate your user account to give you access to it.

Here, I do notice your lack of experience on other systems and frameworks.

I believe in a fundamental principle: The Framework has to be able to boot at all times, and that too regardless of any connection to the database.

For any reason and even if the connection parameters to a database connection is correctly configured in configuration.php, why should Joomla care a damn, if MySQL is not giving a re-start or if some table out of several thousands has crashed and need to be repaired.

Why should one see a "Cloudflare error 504" which declares that the site is non-responsive, when the php scripts are fully functional and MySQL decided to play nasty?

Here, you see a deadlock to your own argument, right.

My suggestion will solve this problem too. The Framework will be required to create a page on the front end to declare database connection is currently not available, or any other message decided by an Admin.

Without that data, any type of minimal configuration interface or recovery system is opening the door to allow a site to be easily compromised or messed with.

Once you and other developer agrees on this aspect, that it is the business of Joomla core to take care of VERY BASIC AND FUNDAMENTAL FUNCTION OF SECURING ADMINISTRATOR DIRECTORY, your counter-argument to my request evaporates immediately.

Am I right?

[DeRaja]

Dear Mr. Babker,

For your information, the above error described is thrown on the Frontend as well. So even here, your counter-argument is in vain. The owner is made laughable by such a silly and ridiculous white webpage, that could trigger on one of the TWO MILLION WEBSITES ANYTIME! We know about such a possibility of an error that could be thrown by MySQL, don't we? My solution changes display of a silly and ridiculous white webpage and proposes generation of a smart webpage decided by the admin.

[DeRaja]

Dear Mr. Babker,

Excuse me, one more thing I forgot to mention.

Even to get a minimal configuration interface like what you're proposing, because we have to have the data to authenticate and validate your user account to give you access to it.

The solution I proposed is to allow authentication based on htaccess to access configuration.php. Because htaccess is a very secure method for authentication on linux, and my proposal is to create htaccess in the first initial step, there is no problem to have Joomla Framework to access htaccess and allow the admin to re-open configuration.php.

With this, I hope that I made my point to your counter argument.

[DeRaja]

Dear Mr. Babker,

Ooops, I need two coffees now because there are certain ideas that cropped up after the above posting.

I propose one more thing to achieve my feature request as follows:

REMOVE ANY REFERENCE OF ONE SUPER ADMIN FROM MYSQL DATABASE AT ALL AND HAVE THIS SUPER USER TO BE CONFIGURED THROUGH HTACCESS ALWAYS!

Well, we have to have htaccess. If we have it, then why not have the htpassword OUTSIDE OF PUBLIC HTML DIR?

Thus, one could have: /home/user/domain.com/public_html/configuration.php and /home/user/domain.com/public_html/.htaccess.

Then one could have for the password: /home/user/domain.com/.password

This means the password file associated to this htaccess is OUTSIDE OF PUBLIC HTML DIR!

Consequently, Joomla will be 100% secured through htaccess for super admin. Thereafter, it becomes no problem to allow and offer an access to configuration .php.

Am I right?

[DeRaja]

Dear Mr. Babker,

Now I am stretching my own argument to counter your constructive opposition. Let me give you one more example:

/home/user/domain.com/public_html/.htaccess ---> read-only /home/user/domain.com/.password ---> read-only /home/user/domain.com/public_html/configuration.php ---> read-only

Now I can access the /administrator/index.php through .htaccess and make changes for configuration.php, add parameters into it and even make it read + write. Because my .password allows me to make everything with configuration.php and this is 100% safe.

This solution is 1000 better and secure that anything available now on the entire Extension system. This means I propose to have a new system of Administration:

Config-Admin

The Config-Admin is NOT to be added in MySQL database and IS not supposed to be web accessible. This means that the CORE is - or it is supposed to be - secured _NOTBY Super Admin based on MySQL authentication but based on Config-Admin based on htaccess.

[DeRaja]

Dear Mr. Babker,

Once this principle of authentication of an admin based on htaccess is available in Joomla core, one could stretch my feature request to analyse its potential further.

So, after an admin has authenticated through htaccess, one could repair MyISAM tables in MySQL/MariaDB, right? If one table on MyISAM should be repaired, MySQL or MariaDB will not restart. Repairing that table will remove this hindrance of restart.

If Authentication is done by htaccess, it should be also possible to change prefix from this Tools page, right?

This opens the door to doing many things through the Framework based on htaccess and work on the DB.

[DeRaja]

On Joomla portal, the team has declared that there are two million websites running on Joomla. If MySQL does not start, simply because one MySQL table got corrupted, then the error in question will be thrown.

The solution proposes to generate webpages that are not based on a database connection and eradicate this error through a web interface.

Because all Joomla developers always thought of a database connection, this kind of an approach has never ever been implemented. Consequently, certain areas in connection with htaccess file also remained under developed and there are no tools available.

In my solution initially proposed, I did not include my request of having htaccess. My solution is based on local htaccess authentication. I had not described some advantages upon implementation of the solution.

Today, I have edited and made changes to my solution and added four points to it.

[ReLater]

Not all hosts/providers support user htaccess files. Not all server environments support htaccess. Not all support access to files ouside the current domain directory or maybe they are not writeable. Some smaller packages just have one directory that's the only place where you can install a website.

A htaccess file should be added (if you want one) BEFORE you start uploading installation files/package.

Sorry, I'm not an expert concerning this issue, but the more I read the more I see additional security risks, not less and more user confusion...

[brianteeman]

Sorry, there is no option but to close this for the reasons stated above.

[brianteeman]

I just wanted to add that your "solution" is only relevant if the reason that the message is served is because you have changed the database details and not updated the configuration. That will never happen without you making a change so there is no reason for the user to ever see that message in this circumstance as you should of course update the configuration when you change the database settings.

The more likely occurrence of this error message being displayed to the user is when there is a problem connecting to the database because of hosting issues eg the web server cannot talk to the mysql server. Your proposed "solution" wont help at all in those circumstances

[DeRaja]

Dear Mr. Teeman,

I wanted to refactor some functions in my own component and enhance something in Controller classes as well as wanted to modify something small in a Model. As I was working on a new project (based on Symphony), I wanted to modify a bit in my Joomla Component. Here, I forgot to update the configuration.php. So obviously I knew what was wrong and, even if I had seen a blank page without that error, I would have had noticed my mistake and had immediately updated the configuration.php.

This feature request - to begin with - proposes a fundamental concept of "Connectionless view generated from Joomla Framework" and proposes to have a bootable webpage from the Joomla framework and to generate views "under all circumstances", without touching model for database connection, regardless of any connection details in the configuration.php. The logic underlying is:

• If the connection details are correct, there may be reasons why a connection to database could not be made. My concept proposes to generate a webpage here without any database connection by default.
• If the connection details are wrong, my concept proposes to show a webpage without database connection and offer some possibilities based on the technological infrastructure it is hosted.

From two million websites running on Joomla, there must be - assuming - at least one hundred thousand websites that could use this solution based on htaccess. There may be one thousand websites that could face risk of MySQL not starting due to table corruption or some other problems.

From two million websites running on Joomla, there must be - assuming - at least one hundred thousand websites that may want multisite installation. I see everyday companies launching their websites based on regions and languages hosted on different subdomains. But you dared to claim that I am "the only idiot" to propose multisite concept and blatantly closed this - very important - feature request here:

https://github.com/joomla/joomla-cms/issues/22254

Before many years, WordPress began to offer multisite solution. During the first install, one was required to choose, what kind of installation one wants, a single or multisite installation. Now this changed. In ProcessWire (See https://processwire.com/api/modules/multi-site-support/) the Framework supports multiple databases from shared codebase. This framework operates under different concept and differs from Joomla Framework. Joomla Framework could easily connect different databases and even share parts. This is possible now and earlier. I am running multisite installations on Joomla since years. I never needed to confronted with people like Mr. Teeman and Mr. Babker, who have a narrow vision and perception. I felt that the community needs it.

You Mr. Teeman and Mr. Babker declared that if Joomla is running on other technologies, like Lightspeed, or whatever, which may have one hundred thousand users (an assumption), then other one hundred thousand users (an assumption) must accept all the disadvantages on Apache and nginx. The reason they gave was because the Joomla framework must be adaptable to these technologies too.

In Redhat linux 3, the first thing I created in 1998 and before bringing my server for co-location with Level3, was to create htaccess on public_html and have .htpassword outside public_html. The poster ReLater above reminded me "A htaccess file should be added (if you want one) BEFORE you start uploading installation files/package.". Well, I could then only thank for this reminder.

If there are one hundred thousand users, who may have a full server access with root privileges, they could hide htaccess from public_html. The poster ReLater above mentioned "Not all support access to files outside the current domain directory or maybe they are not writeable.". Thus, from two million users, these one hundred thousand users should not be provided facility to have htpassword file written through a web interface from Joomla, which could reside under /public_html/ or outside of it.

If there are one hundred thousand users, who could avail htaccess, then they can create it in the initial step. According to the poster ReLater "Not all server environments support htaccess." these people cannot avail an opportunity to create htaccess. They must have their /administrator/ directory unprotected and should do themselves. Well, I have been doing this since twenty years and I feel foolish to suggest this request. All these one hundred thousand users should use Akeeba extension or leave the dir unprotected.

The poster ReLater declared "but the more I read the more I see additional security risks". The entire linux community should be foolish to have use htaccess authentication because it creates security risks.

By configuring session based on file, which CodeIgnitor and Laravel does, one saves details on the disk. All data is - at the end of the day - saved on a disk. The question is its accessibility. Htaccess authentication is one of the best method to secure directories because the daemon could refuse serving a file based on dots in the name.

It is also incorrect to tell a poster they should bring out their php codes. It would be correct to let this request open and allow others to work with it.

[brianteeman]

As stated before it is joomla policy that it works the same in all supported configurations.

[mbabker]

Joomla supports sessions stored to the filesystem, or several other storage mechanisms that are not a RDBMS, but that shouldn't need to be said to an experienced user. However, unless you are going to rewrite Joomla to move a large bulk of what is currently in the database to the local filesystem, what you are requesting with an offline page cannot be done (in that case it sounds like you would be better suited with a flat file CMS that does not actually use a database connection by default).

Joomla already supports rendering an error page within its error handler. But, to know what template should be used for rendering the page, it has to be able to connect to the database. See the problem here?

You Mr. Teeman and Mr. Babker declared that if Joomla is running on other technologies, like Lightspeed, or whatever, which may have one hundred thousand users (an assumption), then other one hundred thousand users (an assumption) must accept all the disadvantages on Apache and nginx. The reason they gave was because the Joomla framework must be adaptable to these technologies too.

Joomla must offer the same features across all supported platforms. You are suggesting .htaccess based authentication and security mechanisms, an Apache configuration directive (one that can also be used with LiteSpeed with extra configuration). For Joomla to consider supporting this feature, it must be possible for a user to make the same type of configuration changes on their active webserver. As NGINX does not have a .htaccess (Apache) or web.config (IIS) style file that could be written in the web space, Joomla cannot directly implement a feature for creating and configuring these types of files. Extensions such as Admin Tools can fill this space because they create specialized solutions and do not support all of Joomla's operating environments (i.e. Admin Tools has an .htaccess management interface but not one for web.config).

The poster ReLater declared "but the more I read the more I see additional security risks". The entire linux community should be foolish to have use htaccess authentication because it creates security risks.

Relying ONLY on .htaccess authentication as a security mechanism is not platform portable and a security risk on environments where .htaccess configuration is limited or not available at all. Deferring all authentication to inside the application ensures we can consistently manage our own security and not rely on an external system.

[DeRaja]

Dear Mr. Babker,

Nice, and tolerable enough, that you began to pour something more constructive than blatantly blocking and closing this feature request.

Joomla supports sessions stored to the filesystem, or several other storage mechanisms that are not a RDBMS

In fact on CodeIgnitor docs pages, they want its users to prefer storing file based instead of databased. I learned from that its advantages too.

But, to know what template should be used for rendering the page, it has to be able to connect to the database.

The "Connectionless page" could be generated based on a naming of a directory - for e.g. - "default". So all files under the default dir under /public_html/templates/default/ and /public_html/administrator/templates/default/ could be served. With this system, every user is guaranteed to have a webpage to be displayed under all circumstances, regardless of if there is no connection to database or if the connection parameters are wrong.

Dear Mr. Babker, what happens during the installation, when there is no database connection and is yet to be fulfilled? The admin gets a page generated or not? In my system of having /public_html/templates/default/*, a user could even configure a default template that will be generated when such an error is triggered, or 404 is generated, etc.

Joomla must offer the same features across all supported platforms.

Joomla portal claims to have two million websites here:

https://www.joomla.org/core-features.html

I refer to the "Usage of web servers for websites" published here:

https://w3techs.com/technologies/overview/web_server/all

The statistics declares:

A) Apache 45.6% means 912000 thousand Joomla websites Nginx 39.6% means 792000 thousand Joomla websites

Apache and Nginx together becomes 1,704 Million Joomla websites

B) Microsoft-IIS 9.4% means 188000 thousand Joomla websites Litespeed 3.4% means 68000 thousand Joomla websites

Microsoft-IIS and Litespeed together becomes 0,25 Million Joomla websites

C) None other of above is irrelevant.

Based on above statistics, we are talking about one Group of (Apache and Nginx) 1,704 Million Joomla users against 0,25 Million Joomla users.

Dear Mr. Babker, do you mean to place a counter argument that 1,7 Million up to ca. ONE MILLION USERS users should accept all disadvantages, because they use Apache/Nginx, simply because there are 0,25 Million Joomla users, who could not use this solution?

Thats not how a developer may evaluate a concept. The majority comes first in the priority and one should not block very important development work because of minority. I do not say that one should neglect the other. I say that one should find a way out. I myself use Apache under localhost and Nginx as proxy. This is kind of a very good combination for various reasons. Many servers use this configuration.

If one excludes Nginx from 1.7 Million users above, still there would be majority using Apache, like about ONE MILLION USERS.

So the strategy - according to me - would be to follow and apply more focus on one million users and thereafter try to apply all changes to other technologies "as best as one can". I have not known a single developer in the last twenty five years, who thought otherwise.

Relying ONLY on .htaccess authentication as a security mechanism is not platform portable and a security risk on environments where .htaccess configuration is limited or not available at all.

This is a restrictive thinking. Why provide in the first step something that has nothing to do with that platform? One could make things possible where it is required and needed to be. If there is some kind of detection mechanism of OS and services, then one could change the installer to offer htaccess configuration on systems using Apache services and allow configuration of htaccess. On other systems, where it is not applicable, this option may not even be displayed.

Don't we know how this works and how to modify the installer on "case: apache2", "case: iis", etc?

Like this, a new window of work will be instantly available for ONE MILLION USERS.

I have never ever mentioned about creating a flat file CMS. The idea was simply to have a possibility to have a basic creation of a Connectionless view as a basic feature embedded into the core.

Once this functionality is embedded in the Framework, there may be many extensions cropping up and will begin to use this functionality, like repairing tables, changing prefixes, etc. This could not be done now without from Joomla framework as it requires a connection. There will crop up some more extensions for a better security too working with htaccess, etc. and other features.

It simply opens a new door to multiple advantages for ONE MILLION USERS.

About ONE MILLION USERS of Joomla installations will be compelled to create a htaccess file during installation - first step and secure their /administrator/ directory, if Joomla detects Apache on the server and ask to insert the htpass on that page where admin enters its password and username.

Once this fundamental area is decided and implemented, it would not be too far to identify some other techniques for users of Joomla running on other services like Microsoft-IIS, Litespeed, etc. There would be definitely something that would help to create some access of a similar kind without major modification or work.

From the claim by Joomla portal, there are "Over 9% of all known business websites". This means that there are 180000 thousand users.

From ca. 2.000.000 business users, I am more-or-less sure that there are more than one hundred thousand business users, who would be "extremely interested" in having this multisite feature. According to me, there may be at least another two hundred thousand users from other groups, who may want to have multisite feature.

If I were to give a priority to my own feature request by myself, I would spend more time on multisite feature and provide little by little functionality of multisite feature to a QUARTER MILLION JOOMLA USERS.

If users may not know about this functionality, then this number be less. Once this functionality is embedded, one may see a rapid growth in its use. I even could stretch this argument and say that there may be at least ONE HUNDRED THOUSAND USERS who may want to change from other CMS to Joomla because of multisite feature. Summing up, I am looking at about half a MILLION USERS FOR MULTISITE feature.

Not implementing the multisite feature is more than stupid and less than foolish, and nothing in between, upon neglecting such an important demands in the industry, specifically after Joomla core has achieved to be one of the finest and most stable. Mind you all, I criticize this severely and harshly, not because I am an enemy of Joomla or any one of you but, on the contrary, as a lover of Joomla, who has followed its growth since it was a child nicked as Mambo.

Developers of this kind of a quality, level, popularity and stability in a framework, like Joomla as already achieved since version 3 was born, have no right to remain blind to such a demand.

And there are not many other than CMS 7 Frameworks other than a few ones, like Laravel, CodeIgnitor, Drupal, etc. Against these ones, Joomla has a terrific built-in advantage and highest potential, although I would choose CodeIgnitor or Symfony, when it may come to multisite built upon a framework. However, none of these frameworks have a variety of extensions, plug-ins, modules and templates, which Joomla has. Consequently, Joomla wins. I do have some reasons to argue in favour of Joomla for multisite and, thus, placed a request here to support A QUARTER MILLION USERS to avail multisite function under top priority.

[SniperSister]

Apache and Nginx together becomes 1,704 Million Joomla websites

Nginx does not support .htaccess based basic auth.

[DeRaja]

@SniperSister I use Apache + nginx myself on my multiple Centos servers across continents. I use htaccess with Apache and Nginx as proxy. Of course I know this that Nginx does not support htaccess. But thanks.

I have calculated in my statistics above a combination of Apache + Nginx as proxy here, which covers htaccess group, like myself. Although there is not a big number in this group though, I would presume to be like 10% only.

[SniperSister]

I have calculated in my statistics above a combination of Apache + Nginx as proxy here

To clarify: you assume that the 39.x% of nginx powered websites are indeed using apache under the hood and nginx is just a proxy? Because that's how I read the numbers above.

[mbabker]

Dear Mr. Babker, do you mean to place a counter argument that 1,7 Million up to ca. ONE MILLION USERS users should accept all disadvantages, because they use Apache/Nginx, simply because there are 0,25 Million Joomla users, who could not use this solution?

Any solution that is implemented must be available to all users regardless of platform. If we create features that are only available if you are using a specific platform, that is neglecting or treating users not using that platform as second class citizens of the ecosystem. It is not about favoring one group over another, it is about ensuring a consistent feature set across environments. We have had similar discussions about PHP oriented functionality and introducing version conditional behaviors, with the same end result being that we can't have a site behave fundamentally different because of the PHP version it is running.

So the strategy - according to me - would be to follow and apply more focus on one million users and thereafter try to apply all changes to other technologies "as best as one can". I have not known a single developer in the last twenty five years, who thought otherwise.

For a distributed product, we should not be aiming to introduce features that are only available to a subset of users. These features are best backfilled by extensions if we cannot provide them reliably to every user in core.

This could not be done now without from Joomla framework as it requires a connection.

Let's be clear about something here. The core framework itself does not have a hard requirement on a database connection existing (otherwise we couldn't have the web installer at all). Many (most) of the application level features do require the database connection be active and stable in order to correctly function, and it would be wrong to try and create an environment where you try to do things without that database connection. Relying on external authentication mechanisms to tell the application "yes this user is authorized to make changes to the global configuration, even if we can't actually verify this person is a registered user on the website with super user permissions" is an inherent security risk if you don't have that external mechanism configured correctly. For Joomla to not be dependent on that type of external mechanism, the end result is that the user must be authenticated within Joomla and that the database can be queried to confirm their permissions and if that core service is unavailable then the application does not function.

Not implementing the multisite feature is more than stupid and less than foolish, and nothing in between, upon neglecting such an important demands in the industry, specifically after Joomla core has achieved to be one of the finest and most stable.

Nobody is saying that the feature is flat out rejected or that the discussion is unwelcome. However, when you have that feature request in the middle of an item with several other major architectural changes (web server based authentication, shared global tables, use of database views), discussion of the feature request is not practical because at that point you're trying to discuss too many unrelated matters in one thread. Make an item that is ONLY multi-site and that can be discussed just fine.

[brianteeman]

Joomla means "all together" so it is a fundamental principle of Joomla that all features are available to all users. Sorry you don't like that but anything that doesn't satisfy that principle will be rejected.

[DeRaja]

@SniperSister,

Noop, I did not calculate in my statistics that there will be 1,74 Million Joomla users to avail htaccess. This cannot be true. First, I only calculate roughly a total number of users in both groups and then based on some of other website readings and my knowledge, I estimated that the use of Nginx as proxy would be only 10% to be added to 912000 Apache users. Thereafter, I made a subtotal to amount as ONE MILLION USERS, which I say above repeatedly. But all these are rough estimates to understand the effectiveness of a feature on the size of a group targetted.

[DeRaja]

Dear Mr. Teeman, You are most welcome to close this feature request any time.

[brianteeman]

it is already closed

[DeRaja]

I understand. This was just a further discussion on it. No problem....

[Bakual]

Can we stop this "discussion" here as it leads nowhere. It has been said multiple times already that this request will not be implemented. Also the reasons are given and the issue is closed. Even lengthy posts will not change that. But it will waste the time of contributors which could invest their time much better.

[DeRaja]

Yes, of course I agree. I did not even kn ow that this was closed. I answered to comments further by Mr. Teeman and the discussion continued. From my side, this is my last posting to thank you all for pouring constructive criticism, however opposing it was.