[PHP-WEBMASTER] Bug #48726 [Com]: website search results ignores language preference
Edit report at https://bugs.php.net/bug.php?id=48726&edit=1 ID: 48726 Comment by: [email protected] Reported by:arlo at arlomedia dot com Summary:website search results ignores language preference Status: Verified Type: Bug Package:Website problem Operating System: Mac OS 10.5 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Can confirm this is still an issue (tested with 'de' and 'en'). (Additonal) Steps to reproduce: - Navigate to http://php.net/results.php?q=strpos&p=manual&l=en - Results for 'en' strpos documentation and 'de' strpos documentation will be shown. - Navigate to http://php.net/results.php?q=strpos&p=manual&l=de - Results for 'de' strpos documentation and 'en' strpos documentation will be shown. Previous Comments: [2014-08-14 05:24:07] [email protected] Ironically, this was fixed long ago but the bug has reoccurred now that we are using Google. [2009-09-17 02:31:09] FDSFS at DFDSF dot COM HHVVBVGFGFGVDFS [2009-06-30 17:18:15] arlo at arlomedia dot com I only suggested a "dirty quickfix" because I was told the functionality of the Yahoo engine was beyond your control. If in fact it supports language filtering, then yes, it would be good to fix that. I just noticed that when I perform a search of the online documentation, my language code of "en" appears as an argument in the search result URL... http://us2.php.net/results.php?q=test&p=manual&l=en ...and this has no effect on the search results. However, if I change the language code in the URL to es, hu, ru ... then the search results are correctly filtered by that language. Apparently it is only the default language of en that is being ignored. [2009-06-30 09:44:35] [email protected] Hannes, is it possible to log the actual requests to make sure the language _IS_ being supplied correctly? [2009-06-30 07:48:55] [email protected] What I don't understand is why the language detection isn't working, we are explicitly asking for the language you provide (falling back to english if none). I'd rather try to fix the language detection then to muck around with dirty quickfixes by limiting the search range based on path structure. 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=48726 -- Edit this bug report at https://bugs.php.net/bug.php?id=48726&edit=1 -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-WEBMASTER] [PHP-BUG] Req #68701 [NEW]: test bug - ignore.
From: jacob Operating system: Mac OSX PHP version: 5.6.4 Package: Website problem Bug Type: Feature/Change Request Bug description:test bug - ignore. Description: test bug - ignore. Test script: --- test bug - ignore. Expected result: test bug - ignore. Actual result: -- test bug - ignore. -- Edit bug report at https://bugs.php.net/bug.php?id=68701&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=68701&r=trysnapshot54 Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=68701&r=trysnapshot55 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=68701&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=68701&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=68701&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=68701&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=68701&r=needscript Try newer version: https://bugs.php.net/fix.php?id=68701&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=68701&r=support Expected behavior: https://bugs.php.net/fix.php?id=68701&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=68701&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=68701&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=68701&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=68701&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=68701&r=dst IIS Stability: https://bugs.php.net/fix.php?id=68701&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=68701&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=68701&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=68701&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=68701&r=mysqlcfg -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-WEBMASTER] Bug #51535 [Com]: Bug reporter allows multiple upvotes
Edit report at https://bugs.php.net/bug.php?id=51535&edit=1 ID: 51535 Comment by: [email protected] Reported by:jameswithers89 at googlemail dot com Summary:Bug reporter allows multiple upvotes Status: Verified Type: Bug Package:Website problem Operating System: Irrelevant PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Confirmed duplicate votes are still possible (both anonymous and authenticated user). Previous Comments: [2010-04-11 19:53:35] [email protected] I believe the old tracker did a few checks, but nothing too serious. Anyway, agreed that this tracker should do something similar. [2010-04-11 19:50:09] jameswithers89 at googlemail dot com Description: Your bug system allows me to vote multiple times on whether a said bug affects me. Is this allowed on purpose or is the feature supposed to only allow one vote per user in order to give accurate statistics? -- Edit this bug report at https://bugs.php.net/bug.php?id=51535&edit=1 -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-WEBMASTER] Req #66861 [Com]: Color sidebars s for deprecation/new/...
Edit report at https://bugs.php.net/bug.php?id=66861&edit=1 ID: 66861 Comment by: [email protected] Reported by:eldmannen+php at gmail dot com Summary:Color sidebars s for deprecation/new/... Status: Open Type: Feature/Change Request Package:Website problem PHP Version:Irrelevant Block user comment: N Private report: N New Comment: I quite like the idea of showing deprecation warnings on old methods however I am not sure how this could be achieved design wise - would like to see some ideas or designs on approaches. :) Previous Comments: [2014-03-13 16:58:53] [email protected] Why don't we just append or prepend the word deprecated? I guess that is language-specific, though. I vote no on changing color for deprecated functions because honestly you are more likely to click on the items that don't match. We could make it a bit transparent or something, but that treatment to the comments hasn't been well received. [2014-03-10 12:59:19] eldmannen+php at gmail dot com Was just a mockup. Yeah, the deprecated colors could be changed from black to gray to decrease their visibility. New functions could also be highlighted in green as you say to better make people aware of them. [2014-03-10 01:10:33] [email protected] Interesting idea. In your screenshot I feel the different colors actually makes you want to click it more, rather then serve as a warning. Which means.. How about adding alight green color for new functions? :) For deprecated/removed .. maybe light fadeout transparency? Or will that just be confusing and make you wanna check it out? :) [2014-03-09 13:23:18] eldmannen+php at gmail dot com Description: On the manual there is a sidebar containing a list of functions. As can be seen on http://www.php.net/manual/en/function.session-regenerate-id.php The sidebar is element with the 'layout-menu' class. I think it would be helpful and increase awarity of deprecated functions by showing a deprecation indicator (dimmed color, red color, or icon, or something) on the /function entries that are deprecated. Expected result: http://i.imgur.com/78PwTak.png -- Edit this bug report at https://bugs.php.net/bug.php?id=66861&edit=1 -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-WEBMASTER] Bug #66856 [Com]: Failed manpage lookups return 200 OK
Edit report at https://bugs.php.net/bug.php?id=66856&edit=1 ID: 66856 Comment by: [email protected] Reported by:eldmannen+php at gmail dot com Summary:Failed manpage lookups return 200 OK Status: Assigned Type: Bug Package:Website problem PHP Version:Irrelevant Assigned To:levim Block user comment: N Private report: N New Comment: > When I entered www.example.net/foo, I did *not* peform a search, I requested a > resource. If the resource was not found, it must return 404. I've reconsidered this and realised you are right. That page should definitely be returning a 404. Previous Comments: [2015-01-03 14:42:32] eldmannen+php at gmail dot com Jacob, > A 404 is intended to be delivered should an application resource cannot be > located by the server, not when a search returns no results. No, this is not limited to application resources. This is for any HTTP resource. The HTTP protocol doesn't care what underlying mechanism handles the request, if it is a file on the file system or a application. A resource was requested, if the resource is not found, it should return 404. It is true that 404 should not be returned upon a search which returns no results, however when you visit the resource example.net/foo you are *not* asking to perform a search, you are asking to retrieve a resource. > GitHub and Wikipedia's approach are slightly different to PHP.net in my > opinion as they render a straight 404 whereas PHP.net returns result sets > based on a list possible matches - so technically, the resource is found. No, the resource is not found. Instead you are served another page (which in this case performs a search). > If we return a 404, we are essentially telling the browser that the "search > results functionality" isn't available. No, we are telling the browser "the resource you requested was not found, but there are some search results that might help you". [2015-01-03 14:21:41] eldmannen+php at gmail dot com www.example.net/foo is a HTTP resource. If you request a resource, and it is not found then it should return a 404. That you do a search when requesting a resource which was not found is a different thing. I request a resource. The resource was not found. The server should return 404. The server may optionally assist me by performing a search, however that does not change the fact that the resource was not found. When I entered www.example.net/foo, I did *not* peform a search, I requested a resource. If the resource was not found, it must return 404. You are right that a search should not return 404, but I requested the resource /foo, I did not query /search?query=foo in which case you are right it should return a 200 OK. [2015-01-03 13:14:16] cmbecker69 at gmx dot de > so technically, the resource is found. IMHO, the *requested* resource is not found, for instance, when <http://php.net/doesntexist> is requested. > If we return a 404, we are essentially telling the browser that > the "search results functionality" isn't available. Note, that it is something different when you type "doesntexist" in the searchbox. You may also compare the difference in the "final" URI: <http://php.net/manual-lookup.php?pattern=doesntexist&scope=quickref> <http://php.net/manual-lookup.php?pattern=doesntexist&lang=en&scope=404quickref> The value of the scope parameter already hints at a "404". [2015-01-03 12:49:31] [email protected] GitHub and Wikipedia's approach are slightly different to PHP.net in my opinion as they render a straight 404 whereas PHP.net returns result sets based on a list possible matches - so technically, the resource is found. If we return a 404, we are essentially telling the browser that the "search results functionality" isn't available. [2015-01-03 12:41:41] cmbecker69 at gmx dot de > A 404 is intended to be delivered should an application resource > cannot be located by the server, not when a search returns no > results. Correct. However, in this case the user doesn't intend to search. Compare the respective behavior of php.net to Github[1] or Wikipedia[2], for instance. [1] <https://github.com/doesntexist> [2] <http://en.wikipedia.org/wiki/Doesntexist> The remainder of the comments for this report are too l
