Change "www." prefix handling

No. That is not the design.

www.* is the abberation here. The RFC for domain names does not specify its use. example.com is preferred to www.example.com.

Either turn off the www prefixing option, solve that at the server level, or change your primary domain to verkehrswende.net.

Let's fix the field description then.

The module is not intended to be used by naive users who cannot self-correct this sort of problem.

There was a larg debate about a similar issue, where I basically said -- "If your webserver is configured that www.* is the default, then it is misconfigured, and I cannot help you." I stick by that.

The 'by design' part that you are fighting is a silent correction to user misbehavior. If you configure www-prefix aliasing and set your default domain correctly, users will be silently sent to the proper host. That part is deliberate and not up for debate.

We should also have a documentation patch for section 4.1.1 of the README.txt

I have to agree with Pancho on this because if you set your default domain to use www, turn off www prefixing and solve www.example.com vs example.com at the server level you will get a message saying you have followed an incorrect link when visiting example.com.

Instead I'd prefer to set up default domain as example.com and use www prefxing however all URLs get rewritten to use example.com instead of www.example.com once user has followed a link to the site using www.example.com.
For example user lands on www.example.com, clicks on a link and the url becomes example.com/alias. For not so tech savvy users this is a big issue.
To sum it up - if www prefixing is enabled all links should use www prefix + domain name.

I realize there are two completely different issues here but they are related - finding one good solution will solve both

That logic seems totally backwards to me.

Non-tech savvy users don't even know how to read a URL host and generally don't care.

I still think this is a non-issue.

The message that users get is in response to #293453: Wildcard DNS - default domain, so you apparently have two groups of DA users asking for two different behaviors.

Actually the message appears when at the server level www.example.com and example.com point to the same location yet only one (example.com without www prefixing or www.example.com) is defined in DA.
It would be nice if both example.com and www.example.com would work for the default domain without any messages.

I like the samples in that last bit. So the issue is that our www prefix handling is universal when it should be selective?

Patches welcome. But perhaps the best fix for this is #284422: Subdomain Aliases. That patch would allow for multiple hosts to be assigned to the same domain, which is ideal.

One of the reasons I'm so testy lately is that no one seems to be testing patches, just complaining after features have been requested and committed.

And, for the record, the behavior that nonsie is describing is directly opposite the current (requested) behavior.

Very tempting to mark this a duplicate of #284422: Subdomain Aliases.

Patches welcome. But if you want maximum flexibility, then Domain Aliases is the way to go, and I am already committed to working that into the module.

And running the check first means that we would need to run two db queries each time (potentially), unless we ran something like:

  // Strip the www. off the subdomain, for checking, since it is always an alias of example.com
  $raw_domain = $_subdomain;
  $_subdomain = str_replace('www.', '', $_subdomain);
  $data = db_fetch_array(db_query("SELECT domain_id FROM {domain} WHERE subdomain IN ('%s', '%s')", $_subdomain, $raw_domain));

Would that work, or cause problems if people register both www.example.com and example.com -- which your approach would also do, right?

And in the case of the above fix, what do we do here?

  // If we stripped the www. send the user to the proper domain.  This should only
  // happen once, on an inbound link or typed URL, so the overhead is acceptable.
  if ($raw_domain != $_subdomain) {
    drupal_goto(domain_get_uri($_domain));
  }

Just to confirm - #12 would solve my problems with www prefix handling

@nonsie -- you mean #13?

Well, thanks for the vote of confidence, but I am open to suggestion here. The problem is that other users asked for the reverse functionality earlier, so I do not have a good answer for the solution to this problem.

For now, you can obviously patch your installs as needed, but -- and Domain Alias is my preferred solution -- what options do we have?

The other option that I see is a per-domain setting for www aliasing, which is certainly possible.

The ideal solution for me personally would be per-domain setting for www aliasing where if www alias is enabled it can be used throughout the site eg. if domain name is set to sub.example.com and it has an alias of www.sub.example.com users landing on www.sub.example.com will always see www prefixed domain name no matter where on the site they are (eg do not strip www for any url for the domain name if www aliasing is enabled for the domain name). It's those marketing people that apparently just can not live without www prefix:P

Haven't given Domain Alias a try yet (been too busy to get a site up and running) but I'll give it a try next week. It might provide me with a way to solve this issue however I'm a bit concerned about the extra queries that are required.

It's either going to be extra queries -- though I think the IN clause can handle that -- of an extra column in the database to store the prefix status.

Note: The #284422: Subdomain Aliases patch just became critical, because it solves the dev -> staging -> live problem for the company I work for. For instance:

If you test the site at my.testexample.com but the live site is example.com, you have to change DA settings when moving the database from staging the live. Subdomain Aliases eliminates this issue by allowing you to register both names to the same domain id.

After digging in, this is officialy a duplicate of #284422: Subdomain Aliases, which solves this problem very elegantly.

Just for the record (over a year later), the major browsers, i.e., Internet Explorer, Opera, Google Chrome, and the precious Firefox, will ALL attempt www.example.com if example.com does not resolve.
And, by the way, note how even the Drupal links autodiscovery in THIS VERY POST only converts links containing "www."
-B