<IfModule mod_rewrite.c>
RewriteEngine On
....
</IfModule>
You may blame the J!Tracker Application for transmitting this comment.

If Apache were the only environment that the CMS is supported on, this could be possible. However:

1) The project supports Apache, IIS, and nginx, each having different server environments (IIS doesn't use .htaccess)
2) There are hosts where enabling a .htaccess file by default would cause more harm than good

I agree that enabling it by default could cause issues.

FWIW, nginx does not use .htaccess either.

But as You wrote, IIS doesn't use htaccess at all and if I am not wrong also nginx doesn't
You may blame the J!Tracker Application for transmitting this comment.

Enabling any of the configurations by default would mean that our script would have to properly detect the software running on the server AND we, the project, would be responsible for troubleshooting issues that arise from blindly enabling .htaccess (or web.config for IIS, or nginx' solution) in environments where our default configuration just does not work. It is safer to not do this and make it a deliberate action by the user to perform this step.

I have to agree with @mbabker that this might throw a lot of problems. But if i'm guessing right @Radek-Suski intention is to lower the amount of sites which are not using SEF-Urls just because they don't know about it. And this problem could be solved in different ways. One proposal: Add the ability to rename the htaccess from the backend. We could just bind it to the current "use htaccess" state and rename the htaccess.txt or htaccess-disabled (see below) to .htaccess if no .htaccess exists. Of course we need an ability to disable the htaccess, but prevent custom htaccess files from being overridden by updates. So if you disable the htaccess it should be renamed otherwise (e.g. htaccess-disabled).

It would be good if this could be done in the admin. We can test the server is supported and ensure that any existing htaccess is not overwritten without backup. This would be a great improvement just needs someone to write the code ;)

That I could support as it still requires a deliberate user action but does make it easier on the user.

Adding a back-end way to do it would be helpful. Many admins use FTP clients that are set up to ignore or not display files beginning with a period so they often have difficulties figuring out how to do this renaming.

It's also to mention that not only the mod_rewrite can cause troubles. My hoster for example doesn't allow the options directive in the .htaccess. So I have to comment out Options +FollowSymLinks or I get an internal server error.
That also means that the administrator will be unable to reach since it will trigger the same internal server error as well. So if we provide a way to rename the htaccess.txt from the backend, it may render the backend unreachable depending on hoster. That's quite bad actually.

I actually wonder if that line Options +FollowSymLinks is even needed in a default setting

@Bakual We could check if there is any trouble with "our" htaccess file. Just move the .htaccess temporary to (for example) joomla-root/tmp and check if it causes problems by getting the http status code.

I actually wonder if that line Options +FollowSymLinks is even needed in a default setting

I have no clue. It's enabled by default on my hoster anyway and I never tried on my test server to disable it.

We could check if there is any trouble with "our" htaccess file. Just move the .htaccess temporary to (for example) joomla-root/tmp and check if it causes problems by getting the http status code.

That could work if you move it to a directory which isn't used otherwise. It just sounds a bit complicated just to save the user a manual step. And it likely still wouldn't be 100% foolproof.

There is certainly a lot of risk with something like this, but also potential. I would suggest that if this were done via the backend, it be tied into the global configuration option to enable SEF URLs. Moving it temporarily to /tmp may work to check with server comparability and conflicts, but I don't think that would be a thorough enough test as it isn't checking whether or not the rewrite rules are actually working. We would probably then need to check a real SEF URL, and may even need to set the value of rewriteBase. We might even need to look at checking file permissions and writing the file like we do with configuration.php.

That said, it would be very cool if that all happened automatically when enabling SEF URLs.

There might be a pre-existing .htaccess in an installation directory, which would then be overwritten if this were changed.

In addition the OSX default to hide dotfiles would mean that a user developing in a local environment would be unaware that the file even existed.

Closing this issue as there has been no activity in 5 months.