The problem is not specific to ref.recode.php but rather every ref.whatever and pretty much anything.anything.php such as function.foo.php ...

The phpweb team is aware of similar problems but here's another bug report to solve, this is a pretty major bug as it makes manual links useless :)

website problems can't be critical.

Assign to Wez to make him recognize this for sure. This bug report means that none of the error_docref links work... Sad thing.

This problem is now magnified as many times google archives pages by short names, for example:

 http://www.php.net/function.mysql-connect

The above causes an endless loop of google searches as google matches link here too.  They work fine on most (perhaps all) mirrors though...

  http://us4.php.net/function.mysql-connect

Sorry, Philip, but I am afraid I cannot understand what endless loop are you talking about...

This also works as expected for me.

Going here: 
http://www.php.net/function.mysql-connect

Sends us here:
http://www.google.com/search?q=function.mysql-connect+site:www.php.net&l=en

And Google result #1 links to here:
http://www.php.net/function.mysql-connect

Which again sends us here:
http://www.google.com/search?q=function.mysql-connect+site:www.php.net&l=en

...

http://www.php.net/function.mysql-connect

sends me to

http://us3.php.net/function.mysql-connect (as expected, it's supposed to send me to a mirror)

Andrew, it is not meant to redirect you to a mirror in case the server is in a good health. I also get redirected to the hu/hu2 mirror, so I was not able to reproduce the problem. So then this is still up to the system@ guys who created the sqlite db, which is responsible for these kind of lookups. 

IMHO the code is not ready for "better qualified" short URLs like this.

I successfuly set up sqlite on my local mirror, and so I added some code to work with these prexfixed lookups. So after php.net updates, this should work again [with sqlite]

It fixed some things, but others remain broken.  For example:

This works:
http://us2.php.net/variables.external

While this does not (endless loop again):
http://www.php.net/variables.external

Philip, the question is if all these shortcuts with dots are fully valid parts of the path. More precisely if they can be put into a /manual/LANG/SHORTCUT_HERE.php path?

That is true for function.echo or variables.external. Is it true for all these shortcuts? Can you provide any exceptions? If you can, then a totally diferent solution may be needed, than what I am thinking about.

Assign to me...

I can't think of any exceptions (except the unrelated $uri_aliases), just that it's only part of the url and it's common to only use part of the url.  If just php.net/external or php.net/language should work, idk, I don't think they need to.  But just variables.external should as people use this and it's even what google indexes it as.

Here are some more examples:

Doesn't work (on mirrors either):
http://www.php.net/language

Works:
http://www.php.net/language.variables

Works:
http://www.php.net/language.variables.external

Note: php.net/langref works fine.

And another example without the langref->language type switch:

Doesn't work:
http://www.php.net/features.file-upload.errors

Doesn't work (on mirrors either):
http://www.php.net/file-upload.errors

Doesn't work:
http://www.php.net/features.file-upload

Works:
http://www.php.net/features

OK, I have employed a different method for searching the DB if a . is present in the shortcut. Hope that it now works correctly, and you won't be able to find more exceptions ;) Close this bug if you agree that it works.

Seems to be working! :)

This problem still exists. I am a user from Australia.

Frequently when I attempt to go to
php.net/function_name_here for a quick reference, I will get redirected to google which will point me again to php.net/function_name_here, creating a loop. 

The problem is not 100% reproducable because some of the servers seem to deliver you to the correct page and others don't. Depending on which of the AU servers I get redirected to. 

Is the correct functionality to mirror the original? being that php.net/<query> is a best match search of the PHP functions reference, otherwise you get the php.net search page that will give you likely matches? I prefer the way it used to work. This google business is rather distracting :(

Happy to help out with any tests.

I have commented on this in the new bug report you opened...