I'm not sure if this is known/already fixed or what...
I created a list for another guy...and he never went in to put in the stuff like the list description and all...I think he went into the admin section once to mass subscribe a few people and that was it...
When we went to the main listinfo page, the new list was not listed, even though it was a public list. I went to the General Options page and edited the preferred hostname field and hit submit. After doing this, the new list was listed on the main public list page (with a blank short description, as I still haven't touched any of the other General Options fields).
Anyone else seen this before? It's not a biggie; and it's now fixed here...
Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Keep your faith in all beautiful things; in the sun when it is hidden, in the Spring when it is gone."
PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1
On Fri, 16 Oct 1998, Corbett J. Klempay wrote:
I'm not sure if this is known/already fixed or what...
I created a list for another guy...and he never went in to put in the stuff like the list description and all...I think he went into the admin section once to mass subscribe a few people and that was it...
When we went to the main listinfo page, the new list was not listed, even though it was a public list. I went to the General Options page and edited the preferred hostname field and hit submit. After doing this, the new list was listed on the main public list page (with a blank short description, as I still haven't touched any of the other General Options fields).
Anyone else seen this before? It's not a biggie; and it's now fixed here...
Yup. this is mailman's virtual hosting 'feature'. I posted a patchfer this earlier. Basically if there is a http 1.1 'HTTP_HOST' value, mailman tries to only show the lists whose preferred host match that value. IMHO, however the current implementation of mailman goes about this wrong. It looks at the preferred hostname for the hostname to match. However the prefered hostname is generally the hostname that goes on outgoing _email_. The hostname for email and for WWW may not always be the same (in my case it isn't) The patch I submitted makes it check against the hostname part of the base mailman URL, instead. Lastly I _strongly_ think this feature should be en/disenable-able via a switch in mm_cfg (defaulting to disabled), as it is extremely confusing. (you aren't the first to report it as a bug)
-The Dragon De Monsyne
On Fri, 16 Oct 1998, The Dragon De Monsyne wrote:
On Fri, 16 Oct 1998, Corbett J. Klempay wrote:
I'm not sure if this is known/already fixed or what...
I created a list for another guy...and he never went in to put in the stuff like the list description and all...I think he went into the admin section once to mass subscribe a few people and that was it...
When we went to the main listinfo page, the new list was not listed, even though it was a public list. I went to the General Options page and edited the preferred hostname field and hit submit. After doing this, the new list was listed on the main public list page (with a blank short description, as I still haven't touched any of the other General Options fields).
Anyone else seen this before? It's not a biggie; and it's now fixed here...
Yup. this is mailman's virtual hosting 'feature'. I posted a patch fer this earlier. Basically if there is a http 1.1 'HTTP_HOST' value, mailman tries to only show the lists whose preferred host match that value. IMHO, however the current implementation of mailman goes about this wrong. It looks at the preferred hostname for the hostname to match. However the prefered hostname is generally the hostname that goes on outgoing _email_. The hostname for email and for WWW may not always be the same (in my case it isn't) The patch I submitted makes it check against the hostname part of the base mailman URL, instead. Lastly I _strongly_ think this feature should be en/disenable-able via a switch in mm_cfg (defaulting to disabled), as it is extremely confusing. (you aren't the first to report it as a bug)
You're right, the web_page_url should have been used in the first place, and i've fixed that in the current sources. Sorry it's taken me so long to correct it. I've also created a system default value, VIRTUAL_HOST_OVERVIEW, which controls whether or not the constrain is in effect - i have made it on by default, but am open to dissuasion on that. At the least, we'll need to warn people who depend on it of the change, if we make it default to off.
(About the behavior in general - i'm sure that the effect of the option is very surprising, if you don't know about it, but i expect that it's not so complicated as to be confusing, _as long as you are aware of the cause_. And i do think it's very important for sites that are hosting different domains on single hosts, and wanting to keep the domains effectively separate - i would suppose it is crucial for ISPs that are renting out domains, for instance.)
ken manheimer klm@python.org
participants (3)
-
Corbett J. Klempay -
Ken Manheimer -
The Dragon De Monsyne