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.