Wordpress in LAMP | redirect www to non-www

NethServer Version: NS8
Module: Version 1.2.3

I’m still having trouble with the domain name resolution. The subdomain I created is www.myancestry.de

Accessing https://www.myancestry.de works perfectly.

However, accessing https://myancestry.de fails.

A redirect in the .htaccess file fails.

RewriteEngine On
RewriteCond %{HTTP_HOST}^myancestry\.de$ [NC]
RewriteRule ^(*)$ https://www.myancestry.de/$1 [R=301,L]

Here’s what I’ve figured out so far:

❯ curl -I http://myancestry.de
HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Wed, 18 Mar 2026 08:02:34 GMT
Content-Length: 19

❯ curl -I http://www.myancestry.de
HTTP/1.1 308 Permanent Redirect
Location: https://www.myancestry.de/
Date: Wed, 18 Mar 2026 08:02:59 GMT
Content-Length: 18

❯ curl -I https://www.myancestry.de
HTTP/2 403
cache-control: private, must-revalidate
content-security-policy: upgrade-insecure-requests
content-type: text/html; charset=UTF-8
date: Wed, 18 Mar 2026 08:03:25 GMT
expires: 0
permissions-policy: accelerometer=(), ambient-light-sensor=(), battery=(), camera=(), display-capture=(self), encrypted-media=(), execution-while-not-rendered=(self), execution-while-out-of-viewport=(self), fullscreen=(self), geolocation=(self), gyroscope=(), magnetometer=(), microphone=(), midi=(), navigation-override=(), payment=(), picture-in-picture=(self), publickey-credentials-get=(), screen-wake-lock=(), sync-script=(), sync-xhr=(), usb=(), vertical-scroll=(self), web-share=(), xr-spatial-tracking=()
pragma: no-cache
referrer-policy: strict-origin-when-cross-origin
server: Apache/2.4.58 (Ubuntu)
status: 403 Forbidden
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 0

❯ curl -I https://myancestry.de
HTTP/2 404
content-type: text/plain; charset=utf-8
x-content-type-options: nosniff
content-length: 19
date: Wed, 18 Mar 2026 08:03:41 GMT

The WordPress and website addresses are correctly set to https://www.myancestry.de .
www.myancestry.de is a CNAME pointing to myancestry.de , and both names resolve to the same IP address 152.53.121.241.

So DNS is not the problem.

DNS itself does not perform a redirect, but only name resolution. However, the curl responses show that www is redirected to HTTPS, while myancestry.de is not processed by the VirtualHost on ports 80 and 443.

If the .htaccess file were active, http://myancestry.de would return a 301 redirect to https://www.myancestry.de/…; instead, it returns a plain 404, meaning the file is not being processed for this host. The fact that https://www.myancestry.de returns Apache/2.4.58 and the security/cache headers also confirms that only the www host is correctly bound to the WordPress site.

This corresponds exactly to a missing Apache virtual host configuration for myancestry.de, and Apache recommends using a redirect directly within the virtual host for canonical hostnames anyway, rather than first redirecting via .htaccess.

Source: Redirecting and Remapping with mod_rewrite - Apache HTTP Server Version 2.4

If I understand correctly, on NethServer/LAMP, an alias for myancestry.de is needed within the existing virtual host for www.myancestry.de so that the same Apache site responds. As long as myancestry.de is not served directly by the virtual host, no rule in the WordPress .htaccess file can take effect.

Even if I could figure that out (probably using a custom template? How?), I’d still need an SSL certificate for myancestry.de.

At this point, I must once again ask for your help.

And wouldn’t it be better overall if the vhost had implemented the redirect from the start?

I think in this case another HTTP route without “www” is needed.

Check the current HTTP route for lamp to get the URL:

Create a HTTP route without the www part as Host, using the URL from the previous step and enable Lets Encrypt to get a valid certificate.

Now both hostnames with and without www should redirect to the web page.

EDIT:

It seems you’re using an older version of lamp. It was moved to NethForge repository, see Request to join Nethforge for ns8-lamp
Maybe you need to enable the repo to get updates for lamp.

1 Like

@capote I fear something wrong since the change of repository, do you have NethForge enabled ?

1 Like

Thanky you Markus.
Short answer: Nethforge is enabled by default after initial installation.

I thought the LAMP update would be announced automatically.

Even after reloading the repositories, “lamp-update” does not appear.

Create a HTTP route without the www part as Host

Now, for the first time, I understand what this feature is for.

I was still thinking in terms of the old categories using an alias. :face_with_peeking_eye:

1 Like

It seems my LAMP wasn’t updated, even after reloading the repositories.

Nethforge is enabled ?

I think so.
image

1 Like

@capote do you have the stephdl repo installed?

In Software Center do you see that the Repository is __local__ when you click on the lamp app instance?

do you have the stephdl repo installed?

Yepp.

do you see that the Repository is __local__

Indeed.

1 Like

I tested the manual update procedure to the NethForge version and it worked but I strongly recommend to have a backup/snapshot in case something goes wrong…

Adapt “lamp1” to your lamp app instance.

api-cli run update-module --data '{"module_url":"ghcr.io/nethserver/lamp:1.2.7","instances":["lamp1"]}'

Thanky you, @mrmarkuz
It worked

1 Like

Does this mean there needs to be a failsafe for an app that get’s upgraded along different repositories, or downgraded, while carrying the same app name??

Seems to me: yes, there should be some sort of UUID or fingerprint of an app during its lifecycle as an NS8 app. “Just” createting, updating or up/down grading an app with a certain name needs to be double checked if we are talking about the same piece of code. Same goes for repo’s.

2 Likes

we are on the same page, something wrong is coming between the switch of repos, this is the first time we do it, something needs to be fixed

3 Likes

Indeed, hence a good talk about it is a good thing, we learn as we go!

1 Like