-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
John W. Baxter wrote:
On 11/26/05 1:25 AM, "Stephen J. Turnbull" stephen@xemacs.org wrote:
>"Max" == Max Bowsher maxb1@ukf.net writes:
Max> Is there any reason not to add web_page_url to the Max> configurable options in the admin GUI? Right below host_name Max> in the general category would be a good place.
Yes, please!
Yes, there is a reason. It is the same reason that the ability was taken out many Mailman versions ago.
Thought experiment:
Make a typo which cripples the URL such that you can't reach the admin web page.
Now fix it from the browser.
The sort of thing in #1 (sometimes not a typo but a more fundamental mistake) happened often enough to make removing the ability seem quite desirable.
One thing which has changed since the decision is that a much higher proportion of list operators don't have command line access than was the case then. So *perhaps* it would make sense to revisit the decision (making it a site option, please).
OK, that is a good reason.
Still, sometimes it really is necessary to change web_page_url. So here are two different possibilities for providing some amount of web_page_url control through the admin GUI, whilst avoiding the possibility of typos blocking web admin access:
OPTION ONE: Whenever the host_name configvar is changed, *if* the new value can be found in mm_cfg.VIRTUAL_HOSTS, *then* recalculate web_page_url based on mm_cfg.DEFAULT_URL_PATTERN and mm_cfg.VIRTUAL_HOSTS.
OPTION TWO: Make links and form action URLs within the admin interface relative, so that an incorrect web_page_url does not render the admin interface inoperable.
What do you think? Either? Both?
Thanks,
Max.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDiLGVfFNSmcDyxYARAhZyAJ4n9mKI7AgnHiVbLLFjFG6nt5UE1ACgwyT+ AvLCTzCXVRxKx8Q3l6f+dBs= =Di43 -----END PGP SIGNATURE-----