Doc #63490 [Com]: Searching for _

From: Date: Thu, 31 Jan 2013 13:34:08 +0000
Subject: Doc #63490 [Com]: Searching for _
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-9500@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=63490&edit=1 ID: 63490 Comment by: narf at bofh dot bg Reported by: php at jtrick dot net Summary: Searching for _ Status: Assigned Type: Documentation Problem Package: Website problem PHP Version: Irrelevant Assigned To: danbrown Block user comment: N Private report: N New Comment: It doesn't directly go to gettext, but it seems to be the first suggestion now. Previous Comments: ------------------------------------------------------------------------ [2012-12-05 23:27:53] 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. ------------------------------------------------------------------------ [2012-12-03 17:38:42] 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-03 12:56:21] 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 11:48:34] 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 01:54:21] 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 ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63490 -- Edit this bug report at https://bugs.php.net/bug.php?id=63490&edit=1

« previous php.doc.bugs (#9500) next »