To install HumHub, Wikipedia (MediaWiki), and WordPress on a single domain where HumHub occupies the main directory, you will use a subdirectory structure. This setup allows example.com to lead to HumHub, while ://example.com and example.com/blog lead to the other applications. [1, 2, 3]
You must create separate folders for the secondary applications within your web server's root directory (usually /var/www/html/ or public_html/). [2]
Each application needs its own data storage. You have two options: [2]
Because HumHub is in the root, its .htaccess file (used for "pretty URLs") might interfere with subdirectories. [13]
RewriteEngine On RewriteCond %{REQUEST_URI} ^/(wiki|blog) [NC] RewriteRule .* - [L]
| Application [12] | URL Path | Installation Location |
|---|---|---|
| HumHub | example.com/ | Root Folder (/public_html/) |
| MediaWiki | ://example.com | /public_html/wiki/ |
| WordPress | ://example.com | /public_html/blog/ |
Do you need help with the specific Apache or Nginx configuration for these three apps to work together smoothly?
[1] https://serverfault.com [2] https://jetpack.com [3] https://docs.humhub.org [4] https://wiki.crowncloud.net [5] https://www.reddit.com [6] https://www.accuwebhosting.com [7] https://docs.humhub.org [8] https://runcloud.io [9] https://solidwp.com [10] https://docs.humhub.org [11] https://docs.humhub.org [12] https://www.atlantic.net [13] https://docs.humhub.org [14] https://wordpress.stackexchange.com [15] https://hueston.co [16] https://www.hostinger.com
The reason you see a HumHub "Page Not Found" error is that HumHub’s routing rules are "greedy." The final lines in your .htaccess tell Apache: "If the request isn't a physical file, send everything to HumHub's index.php." Since /w/ and /b/ don't technically exist as single files, HumHub tries to process them as internal social network pages. To fix this, you need to tell the HumHub .htaccess to ignore those specific directories.
Open your .htaccess file and find the section where the RewriteRules begin. You need to add two "exclusion" lines immediately before the final RewriteRule .? %{ENV:BASE}/index.php [L] line. Modify that section to look like this:
# ... previous rules ...
# 1. Skip rewriting for the WordPress and MediaWiki directories
RewriteCond %{REQUEST_URI} ^/(w|b)/ [NC]
RewriteRule ^ - [L]
# 2. Existing rule for physical files (Keep this)
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule .? - [L]
# 3. Final HumHub routing (This stays at the bottom)
RewriteRule .? %{ENV:BASE}/index.php [L]Once you apply this, your sub-apps should load. However:
To get everything running smoothly, you need to configure each application to acknowledge it is living in a subfolder. Here are the specific configurations for MediaWiki and WordPress.
Open your LocalSettings.php file (located inside the /w/ folder) and ensure these variables reflect the subdirectory path:
default is /wiki. Change this to /w if your folder is named 'w' $wgScriptPath = "/w";
Note: This matches the 'Article Path' $wgArticlePath = "/wiki/$1";
$wgServer = "https://montessori.rocks";
Pro Tip: If you want users to see montessori.rocks/wiki/Page_Name instead of montessori.rocks/w/index.php?title=Page_Name, you will need a small .htaccess file inside the /w/ folder as well.
WordPress is usually good at detecting its home, but if you have trouble logging in or see broken images, add these lines to your wp-config.php file (located inside the /b/ folder):
define( 'WP_HOME', 'https://montessori.rocks' ); define( 'WP_SITEURL', 'https://montessori.rocks' );
Crucial Step for WordPress Permalinks:
After updating the root .htaccess (with the exclusion rules we discussed previously) and these settings:
To enable "Short URLs" for MediaWiki (so your links look like montessori.rocks/wiki/Page_Name instead of montessori.rocks/w/index.php...), you need to create a new .htaccess file inside your /w/ folder.
Create or edit /w/.htaccess and paste this in:
RewriteEngine On
RewriteRule ^/?wiki(/.*)?$ %{DOCUMENT_ROOT}/w/index.php [L]
RewriteRule ^/?w/?$ %{DOCUMENT_ROOT}/w/index.php [L]
For the rules above to work, your LocalSettings.php must have these exact lines:
$wgScriptPath = "/w"; // The actual folder on your server $wgArticlePath = "/wiki/$1"; // The "fake" URL users see in the browser
Since we are using /wiki/ as the virtual path for your MediaWiki, make sure your main HumHub .htaccess (in the root) also ignores the /wiki/ path, or HumHub will try to grab those requests. Update that specific line in your root .htaccess to include the virtual wiki path:
RewriteCond %{REQUEST_URI} ^/(w|b|wiki)/ [NC] RewriteRule ^ - [L]
Are you seeing any "403 Forbidden" errors or "Internal Server Errors" after adding these files?
If yes follow the next steps.
If you are seeing 403 Forbidden or 500 Internal Server Errors, it usually means there is a permission conflict or a syntax error in how the .htaccess files are interacting. Let’s troubleshoot the most common causes for this setup:
HumHub’s .htaccess often includes Options +FollowSymLinks. Some shared hosts forbid this and require Options +SymLinksIfOwnerMatch instead. If you have both or the wrong one, the server crashes. Fix: In your root .htaccess, ensure only one is active. Try commenting both out just to test:
Since HumHub is in the root, it might be trying to apply its base path to the subfolders. Fix: Inside your /w/ and /b/ folders, ensure their respective .htaccess files explicitly set their own base.
A 403 error usually means the web server (Apache) doesn't have permission to read the new folders or the .htaccess files inside them. Fix:
If you visit montessori.rocks/w/ and see a 403, it might be because the server is looking for index.html instead of index.php. Fix: Add this line to the top of your root .htaccess:
DirectoryIndex index.php index.html
To find out exactly which file is causing the error:
If the error persists do the following check