php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Doc Bug #63490 Searching for _
Submitted: 2012-11-12 02:55 UTC Modified: 2013-05-18 00:23 UTC
From: php at jtrick dot net Assigned: danbrown (profile)
Status: Closed Package: Website problem
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Developer Edit
 [2012-11-12 02:55 UTC] php at jtrick dot net 
Description:
------------
Searching for '_' (underscore) returns the following page: 
http://us3.php.net/manual/en/about.php

A much more useful result location would be 
http://php.net/manual/en/function.gettext.php as _() is apparently a valid alias 
for gettext().

This was not known to me, and had it not been for another thoughtful user would 
have remained that way...

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-11-12 03:20 UTC] aharvey@php.net
-Package: Documentation problem +Package: Website problem
 [2012-11-12 03:20 UTC] aharvey@php.net 
I can add a hack to find_manual_page() to make this work, but I wonder if it's something that we should be handling when we generate manual-lookup.sqlite instead.

Hannes, Philip, any thoughts?
 [2012-12-02 05:59 UTC] bjori@php.net 
Thats just weird.
http://php.net/_ works just fine, I've no idea how http://us3.php.net/manual-
lookup.php?pattern=_&scope=quickref winds up on the about page...

Since this is a real alias it is most definitely in the sqlite databaes so I've 
no idea what is going on here (and haven't actually looked)..

What sort of hack where you thinking about Adam?
 [2012-12-03 01:54 UTC] aharvey@php.net 
Quite literally this, which doesn't fill me with great joy:

diff --git a/include/manual-lookup.inc b/include/manual-lookup.inc
index d12d7e1..f21dc18 100644
--- a/include/manual-lookup.inc
+++ b/include/manual-lookup.inc
@@ -83,6 +83,10 @@ function find_manual_page_slow($lang, $keyword)
 // page shortcuts, so we avoid stat() calls on the server
 function find_manual_page($lang, $keyword)
 {
+    if ($keyword == '_') {
+        $keyword = 'function.gettext';
+    }
+
     // If there is no sqlite support, or we are unable to
     // open the database, fall back to normal search. Use
     // open rather than popen to avoid any chance of confusion
 [2012-12-03 11:48 UTC] salathe@php.net 
"Since this is a real alias it is most definitely in the sqlite databaes so I've 
no idea what is going on here" -- the _ alias is not in the sqlite database 
(manual-lookup.sqlite) as there is no corresponding file in the docs (see 
systems.git/gen-phpweb-sqlite-db.php which generates the sqlite database). At 
least, it looks that way after a quick scan of the code.

For now, Adam's quick hack looks like the least invasive workaround.
 [2012-12-03 12:56 UTC] bjori@php.net 
Heh.
Looks like the fact it is an alias is just documented in an inline note.
I wonder why php.net/_ works then.


Documenting the alias properly by adding <refname>_</refname> to the refentry 
should solve this bug then.
 [2012-12-03 17:38 UTC] salathe@php.net 
http://php.net/_ works because we have n array of URI aliases in the error.php 
script such that _ redirects to function.gettext
 [2012-12-05 22:27 UTC] danbrown@php.net
-Assigned To: +Assigned To: danbrown
 [2012-12-05 23:27 UTC] danbrown@php.net 
Just pushed two commits that should permanently resolve it, including a fix to 
the manual-lookup.sqlite generator in systems.  I'll leave it to generate on its 
own tomorrow, like normal, and if it works we can close this one out.
 [2013-01-31 13:34 UTC] narf at bofh dot bg 
It doesn't directly go to gettext, but it seems to be the first suggestion now.
 [2013-05-18 00:23 UTC] vrana@php.net
-Status: Assigned +Status: Closed
 [2013-05-18 00:23 UTC] vrana@php.net 
Already fixed.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Nov 21 05:00:01 2025 UTC