1

The default .htaccess code for WordPress is:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

How can I insert the code into the Apache config to avoid having to use .htaccess? I need the code to apply to all addon domains on the server (all domains on the server are running WordPress).

In addition, WordPress recommends adding this code:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

Though I'm not sure if it's needed anymore as when I removed it and tried to load these pages, they went to 404 anyways.

My goal is to completely get rid of .htaccess files to speed up the loading of my sites.

Apache 2.4+/CentOS

MrWhite
  • 12,647
  • 4
  • 29
  • 41
Joe
  • 13
  • 3
  • The effect of having rules in configuration vs `.htaccess` is quite minimal. You should concentrate on caching on WordPress side instead, that will provide bigger benefits. – Tero Kilkanen Sep 17 '20 at 06:59
  • @Tero Kilkanen I already have maximum caching. I don't need .htaccess files as I own every site on the server and they're all Wordpress. – Joe Sep 18 '20 at 02:43
  • Anyway, the speedup from moving the rules to main Apache configuration is so small so that you cannot notice it. Therefore I don't think it is worth any effort to deviate from WP standard. – Tero Kilkanen Sep 18 '20 at 06:51
  • "Questions involving web hosting control panels are off-topic" - although the question doesn't appear to have anything to do with "web hosting control panels"; the question would seem to have been incorrectly tagged. (?) – MrWhite Sep 29 '20 at 13:03

1 Answers1

0

I need the code to apply to all addon domains on the server

How you configure this will depend on whether you have a separate <VirtualHost> (vHost) for each Addon domain, or whether you have a single vHost for all Addon domains.

Separate <VirtualHost> for each Addon domain

There are two options here. You can either inherit the common (WordPress) directives from the server config, or include a common config file into each vHost.

Inherit from server config

If your "addon domains" are served from separate <VirtualHost> containers then you could place these "common" mod_rewrite directives in the main server config (outside of the vHost) and enable mod_rewrite inheritance.

But note that in a server (or virtualhost) context these directives need to be altered slightly. For example:

RewriteEngine On

# Enable all (child) vhost configs to inherit these directives
# (Requires Apache 2.4.8+)
RewriteOptions InheritDown

RewriteRule ^/index\.php$ - [L]
RewriteCond %{LA-U:REQUEST_FILENAME} !-f
RewriteCond %{LA-U:REQUEST_FILENAME} !-d
RewriteRule ^/. /index.php [L]

Changes explained:

  • Removal of RewriteBase (not valid in server context)
  • Use of lookahead (LA-U:) to retrieve the filename the request is mapped to.
  • The URL-path that is matched and substitution strings are all root-relative and start with a slash.
  • The <IfModule> wrapper is not required.
# Enable all (child) vhost configs to inherit these directives
# (Requires Apache 2.4.8+)
RewriteOptions InheritDown

As noted, this requires Apache 2.4.8 or later. The rewrite engine still needs to be enabled in the child vHost config. These directives (in the server config) are essentially copied in-place after any existing directives in the vHost container. (The WordPress front-controller generally needs to come after other directives.)

If you are not on Apache 2.4.8+ then you will instead need to include the following in all the child vHost configs in order to inherit the parent config.

# Inherit mod_rewrite directives from the server config after the current directives
RewriteOptions Inherit

RewriteOptions Inherit in all child configs (<VirtualHost> container) is the same as specifying RewriteOptions InheritDown in the parent config.

UPDATE: Include additional config file

Instead of using mod_rewrite inheritance as mentioned above, you could simply Include the common (WordPress) config file at the appropriate place in each vHost container.

This would also allow you to keep the original directives from the .htaccess file and include these unaltered in the relevant <Directory> container. (Instead of using them directly in the vHost container or main server config.)

For example, if the contents of your original .htaccess file was in the config (include) file /etc/apache2/sites-enabled/wordpress.conf. Then in your vHost container:

DocumentRoot /var/www/example.com/public_html

<Directory /var/www/example.com/public_html>
    AllowOverride None
    Require all granted
    Include /etc/apache2/sites-enabled/wordpress.conf
</Directory>

.htaccess and <Directory> containers in the server config are both "directory" context, so the directives work unaltered.


A single <VirtualHost> for all Addon domains

Alternatively, if all your "addon domains" are served from the same <VirtualHost> container (or even all from the server config diretcly - no vHosts - although I think vHosts are easier to manage) then the above mod_rewrite code block (as modified for the server config) would just go directly in the vHost container (or use the original .htaccess directives inside a <Diretcory> container). No need for the RewriteOptions directive - no mod_rewrite inheritance required.

However, this requires additional directives to route the request for each addon domain to the appropriate WordPress installation directory. By either:

  • Use mod_rewrite to internally rewrite the request to the appropriate subdirectory or filesystem path. But note that all sites have the same DocumentRoot. You may need additional directives to prevent direct access to the "addon" subdirectory. You might need to explicitly "correct" the DOCUMENT_ROOT that WordPress uses.

  • OR, use VirtualDocumentRoot (mod_vhost_alias) based on the domain being requested to route requests to the appropriate subdirectory. This creates a dynamic DocumentRoot.

For example, using mod_vhost_alias:

<VirtualHost *:443>
    UseCanonicalName Off
    ServerAlias www.*.com
    VirtualDocumentRoot /var/www/%2+/public_html
    <Directory /var/www/*/public_html>
        AllowOverride None
        Require all granted
        Include /etc/apache2/sites-enabled/wordpress.conf
    </Directory>

    # SSL config etc. ...

</VirtualHost>

The DocumentRoot would be /var/www/example.com/public_html (or whatever hostname is requested, less the www prefix). This has the advantage that new sites can be added by simply creating a new subdirectory, no changes required to the server config and consequently no need to restart the server.

This would be more suited if all your WordPress sites require the same config. If certain sites require specific customisations then it may get more complex or "tricky" to implement. However, you could create another/separate vHost in this case.

This would also likely require additional/different steps to later separate the access/error logs for the different domains. (Although you would likely need to do something like this anyway if you are hosting many separate vHosts.)

Reference:
https://httpd.apache.org/docs/2.4/vhosts/mass.html https://httpd.apache.org/docs/2.4/mod/mod_vhost_alias.html


If you are moving away from using .htaccess then you need to ensure you completely disable .htaccess overrides in the vHost to get the full benefit. ie:

<Directory /var/www>
    AllowOverride None
</Directory>

Otherwise, Apache still wastes time searching for the .htaccess files.

MrWhite
  • 12,647
  • 4
  • 29
  • 41
  • I am going to accept your answer even though sadly, I'm using Apache 2.4.46 and the latter method you mentioned (for non-2.4.8+) is not one code that will affect all domains. At least, as I understand it, you said each domain's vHost config would need to have that code added. – Joe Sep 19 '20 at 10:33
  • "sadly, I'm using Apache 2.4.46" - 2.4.46 is much more recent than 2.4.8 (that's not "80", if that's what you were thinking?). – MrWhite Sep 19 '20 at 13:04