P.S. In speaking about the website search function, when I say localized manual pages, I mean the 2 character language code embedded in the URL of the page. Since I'm starting from ca.php.net and have EN-US as my browser / OS locale, I don't want to have "fr" pages showing up in the search results, e.g. http://ca.php.net/manual/fr/ref.mail.php

If you search for "mail" in the "whole site" you end up with the same page repeated many times for "en", "fr", "it", "tw", "de". Whoa!

Regards

P.P.S. Regarding the website search function. There is a nasty side effect of the redirection to ch.php.net for the search results page. If you perform a second search from the search results page, you completely lose your original domain which for the first set of results is cached in the URL and appears in all the results links, e.g.
http://ch.php.net/search.php?show=wholesite&pattern=mail&base=http%3A%2F%2Fca.php.net%2F&lang=en
Instead, since the search is initiated from ch.php.net the second search results page is all links within ch.php.net. Not what I was expecting. 

So whatever magic allows search results appearing on ch.php.net to link back to the originating domain, e.g. ca.php.net should also apply to searches initiated from this results page so the domain remains ca.php.net (or whatever I stared from) at all times.

Comprende?

I'm currently having a look at the searching from the search results page issue.

Regards
--jm

Hi

Using the search box on the top of the browser while on the search results page now remembers which mirror you originated from, so that when you click on the results it takes you back to the original site you came from.

There are various links to www.php.net in the manuals, etc. for downloads, etc. as lots of people do download the manuals for use on their pc's, and linking to www.php.net does make sense.

Regards
--jm

Can you please check if the search base parameter is carried on for additional searches as you expected now? Jacques has fixed this.

The links are fixed there, because the same text is included in the HTML downloadable versions (and will be included in the PDF too), so we cannot use relative links. It may make sense to make those relative links when the manual is generated for php.net...

The search issue, is simply by design. If you search on the website, that means "the website" and not a part of it. If you search in the manual, that is a part of the website ;) Which is restricted to English now. We are still working on better language selection modes, so users really get the language they want automatically. While we still get bug reports about these, we would not like to start into modifying the search page too to use those preferences, because that would make more bug reports about this...

Regarding the search base parameter, the links on the results page are now based on my starting domain. Thank you :)

One observation, the URL of the search results the first time around contains a whack of query string parameters, whereas for subsequent searchs the URL is bare. It seems like there are two different implementations of preserving the search base parameter.

Ooops, I spoke too soon on my last post. The "search results" links are now domain based correctly, but there are other links on the results page that are still not based correctly, i.e. those in the header and footer.

I think the problem here is not a question of patching up search results to re-base them to the source domain. Rather the real problem is search results should be display by the originating domain not ch.php.net.

For example, any mirror can post a search request to ch.php.net, then the search server ch.php.net could post the results back to the originating server for the latter to display. Or pick another architecture but keep the display of results under the control of the originating domain.

Regarding hard-coded links to www.php.net on mirror sites:

> It may make sense to make those relative
> links when the manual is generated for php.net

Yes please, feature request :)

Part of this issue is fixed: Now on the search result pages, links at the top and bottom navbars also point back to the originating server, from where the search request came from...

The absolute link issue, is however not solved yet.

OK, I have comitted code to the PHP Documentation build system to use relative links when the onsite pages are generated, so all links will keep you on the same mirror.

I cannot give you any estimates, when this new code will be run to generate new documentation. It takes a very long time to generate all the languages (nearly a week) on a very high CPU load.

We are also working on more optimized manual generation ideas, but that is another question. So please be a bit patient for this new 'relative link stuff' to appear.

I am closing the bug, as the problem is solved at least in CVS, at the build system level.