[PHP-WEBMASTER] Bug #66956 [Com]: Incorrect link
Edit report at https://bugs.php.net/bug.php?id=66956&edit=1 ID: 66956 Comment by: [email protected] Reported by:hannes dot magnusson at gmail dot com Summary:Incorrect link Status: Not a bug Type: Bug Package:Website problem Operating System: * PHP Version:Irrelevant Assigned To:sobak Block user comment: N Private report: N New Comment: Maybe just replace headline "Languages" with link to "English" graph? Another idea: maybe just move "Graph" (http://doc.php.net/revcheck.php?p=graph&lang={lang}) on the default site? So general graph for English and language-specific graph for other langs. Previous Comments: [2014-03-26 14:24:42] [email protected] When I click English from that language list, I see a pretty revcheck graph. When I pick other languages I get what I thought was an error ("Please choose a specified tool from the right side."). If the language links don't do the same thing.. I would rename English to "revcheck", then add some border below it, and then list the translations -------- [2014-03-26 13:32:15] [email protected] Revcheck is working. After you choose a language menu on the right sidebar changes. It shows list of available tools for specified language. However, the fact that you reported is as a bug means that this comunicate isn't clear enough. Any suggestions to improve this? "The translation mailinglists should also be mentioned somewhere, so people interested in helping out can contact someone ([email protected]). [email protected] should also be mentioned :]" I think that proper place to mention this is just a page you are talking about. So page displayed when user selected language and haven't selected tool yet. Probably we can also add another tab in the top menu. [2014-03-26 05:18:05] hannes dot magnusson at gmail dot com Description: http://doc.php.net/ Click Japanese -> http://doc.php.net/revcheck.php?lang=ja "Please choose a specified tool from the right side." Only lang=en seems to work. The translation mailinglists should also be mentioned somewhere, so people interested in helping out can contact someone ([email protected]). [email protected] should also be mentioned :] -- Edit this bug report at https://bugs.php.net/bug.php?id=66956&edit=1 -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-WEBMASTER] Bug #66956 [Com]: Incorrect link
Edit report at https://bugs.php.net/bug.php?id=66956&edit=1 ID: 66956 Comment by: [email protected] Reported by:hannes dot magnusson at gmail dot com Summary:Incorrect link Status: Not a bug Type: Bug Package:Website problem Operating System: * PHP Version:Irrelevant Assigned To:sobak Block user comment: N Private report: N New Comment: I improved communicates - https://github.com/php/web-doc/commit/308eefcfa33ae20ab5a35fa119eb9f73486f1e3f - it would be nice if you could review this commit. I probably made some language mistakes and your English is much better than mine. Previous Comments: [2014-03-26 14:56:29] [email protected] I like your first idea better - or just name it "Translation status" or anything that actual describes what I am looking it :) But the text "Graph" doesn't tell me anything, it need to be more descriptive so I will want to click it :) ---- [2014-03-26 14:50:44] [email protected] Maybe just replace headline "Languages" with link to "English" graph? Another idea: maybe just move "Graph" (http://doc.php.net/revcheck.php?p=graph&lang={lang}) on the default site? So general graph for English and language-specific graph for other langs. [2014-03-26 14:24:42] [email protected] When I click English from that language list, I see a pretty revcheck graph. When I pick other languages I get what I thought was an error ("Please choose a specified tool from the right side."). If the language links don't do the same thing.. I would rename English to "revcheck", then add some border below it, and then list the translations -------- [2014-03-26 13:32:15] [email protected] Revcheck is working. After you choose a language menu on the right sidebar changes. It shows list of available tools for specified language. However, the fact that you reported is as a bug means that this comunicate isn't clear enough. Any suggestions to improve this? "The translation mailinglists should also be mentioned somewhere, so people interested in helping out can contact someone ([email protected]). [email protected] should also be mentioned :]" I think that proper place to mention this is just a page you are talking about. So page displayed when user selected language and haven't selected tool yet. Probably we can also add another tab in the top menu. [2014-03-26 05:18:05] hannes dot magnusson at gmail dot com Description: http://doc.php.net/ Click Japanese -> http://doc.php.net/revcheck.php?lang=ja "Please choose a specified tool from the right side." Only lang=en seems to work. The translation mailinglists should also be mentioned somewhere, so people interested in helping out can contact someone ([email protected]). [email protected] should also be mentioned :] -- Edit this bug report at https://bugs.php.net/bug.php?id=66956&edit=1 -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-WEBMASTER] [PHP-BUG] Bug #67006 [NEW]: bugs.php.net: login form in developer's section doesn't work
From: sobak Operating system: PHP version: Irrelevant Package: Website problem Bug Type: Bug Bug description:bugs.php.net: login form in developer's section doesn't work Description: When I'm in "Developer" tab on bug page, I cannot login with my access data. I'm sure that I typed them correctly, because copying and pasting same data on bugs.php.net/login.php works just fine. -- Edit bug report at https://bugs.php.net/bug.php?id=67006&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=67006&r=trysnapshot54 Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=67006&r=trysnapshot55 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=67006&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=67006&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=67006&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=67006&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=67006&r=needscript Try newer version: https://bugs.php.net/fix.php?id=67006&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=67006&r=support Expected behavior: https://bugs.php.net/fix.php?id=67006&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=67006&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=67006&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=67006&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=67006&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=67006&r=dst IIS Stability: https://bugs.php.net/fix.php?id=67006&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=67006&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=67006&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=67006&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=67006&r=mysqlcfg -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-WEBMASTER] [PHP-BUG] Bug #67401 [NEW]: people.php.net doesn't fetch notes
From: sobak Operating system: PHP version: Irrelevant Package: Website problem Bug Type: Bug Bug description:people.php.net doesn't fetch notes Description: user.php in web-people is prepared to show user notes, but it doesn't works. Probably JSON data fetched by findPHPUser() doesn't contain this info, but I have no abbility to verify this as it requires token. That's why assigned this bug to salathe. Verify: https://master.php.net/manage/users.php?username=salathe vs. http://people.php.net/user.php?username=salathe -- Edit bug report at https://bugs.php.net/bug.php?id=67401&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=67401&r=trysnapshot54 Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=67401&r=trysnapshot55 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=67401&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=67401&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=67401&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=67401&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=67401&r=needscript Try newer version: https://bugs.php.net/fix.php?id=67401&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=67401&r=support Expected behavior: https://bugs.php.net/fix.php?id=67401&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=67401&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=67401&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=67401&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=67401&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=67401&r=dst IIS Stability: https://bugs.php.net/fix.php?id=67401&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=67401&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=67401&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=67401&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=67401&r=mysqlcfg -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-WEBMASTER] Bug #67513 [Com]: Visited links are indistinguishable from unvisited links
Edit report at https://bugs.php.net/bug.php?id=67513&edit=1 ID: 67513 Comment by: [email protected] Reported by:phpbugs at kennel17 dot co dot uk Summary:Visited links are indistinguishable from unvisited links Status: Assigned Type: Bug Package:Website problem Operating System: N/A PHP Version:5.5.13 Assigned To:levim Block user comment: N Private report: N New Comment: "(On an unrelated note, the issue tracker refused to accept my submission if I selected 'Irrelevant' as the PHP version. Therefore this bug is randomly logged against a random PHP version)" Thanks for the catch, I will look into it. Previous Comments: [2014-06-25 14:54:23] phpbugs at kennel17 dot co dot uk Description: The PHP.net documentation styles visited links to look the same as unvisited links, which affects usability. Visited links should be styled differently so that it is clear to returning users what they have already visited. This serves two important purposes: * Makes it easier to re-locate a page you have previously visited (useful when returning to look for information you previously found). * Helps you avoid revisiting pages you have already read (useful when looking for specific information, to avoid frustration of repeatedly ending back on same page). Expected result: That PHP.net follows usability best-practice. Actual result: -- This browser feature has been unnecessarily disabled, resulting in a decreased user experience. (On an unrelated note, the issue tracker refused to accept my submission if I selected 'Irrelevant' as the PHP version. Therefore this bug is randomly logged against a random PHP version) -- Edit this bug report at https://bugs.php.net/bug.php?id=67513&edit=1 -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-WEBMASTER] Bug #67513 [Com]: Visited links are indistinguishable from unvisited links
Edit report at https://bugs.php.net/bug.php?id=67513&edit=1 ID: 67513 Comment by: [email protected] Reported by:phpbugs at kennel17 dot co dot uk Summary:Visited links are indistinguishable from unvisited links Status: Assigned Type: Bug Package:Website problem Operating System: N/A PHP Version:5.5.13 Assigned To:levim Block user comment: N Private report: N New Comment: Fix for your side report (connected with PHP versions) has been commited. It will take some time until it will spread across all our mirrors. Previous Comments: [2014-06-25 15:51:46] [email protected] I am not sure if the issues are resolved in all major versions of browsers, but it was an attack vector at one point to distinguish visited and unvisited links. [2014-06-25 15:39:06] [email protected] "(On an unrelated note, the issue tracker refused to accept my submission if I selected 'Irrelevant' as the PHP version. Therefore this bug is randomly logged against a random PHP version)" Thanks for the catch, I will look into it. [2014-06-25 14:54:23] phpbugs at kennel17 dot co dot uk Description: The PHP.net documentation styles visited links to look the same as unvisited links, which affects usability. Visited links should be styled differently so that it is clear to returning users what they have already visited. This serves two important purposes: * Makes it easier to re-locate a page you have previously visited (useful when returning to look for information you previously found). * Helps you avoid revisiting pages you have already read (useful when looking for specific information, to avoid frustration of repeatedly ending back on same page). Expected result: That PHP.net follows usability best-practice. Actual result: -- This browser feature has been unnecessarily disabled, resulting in a decreased user experience. (On an unrelated note, the issue tracker refused to accept my submission if I selected 'Irrelevant' as the PHP version. Therefore this bug is randomly logged against a random PHP version) -- Edit this bug report at https://bugs.php.net/bug.php?id=67513&edit=1 -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-WEBMASTER] Bug #67006 [Com]: bugs.php.net: login form in developer's section doesn't work
Edit report at https://bugs.php.net/bug.php?id=67006&edit=1 ID: 67006 Comment by: [email protected] Reported by: [email protected] Summary:bugs.php.net: login form in developer's section doesn't work Status: Closed Type: Bug Package:Website problem PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Yasuo, it works for you, great. But it doesn't mean that it's not a bug. If something works only for some people it is exactly a bug. I just investigated the reason - field for SVN password had maxlength of 20 characters in bug.php while this limit wasn't applied in any other place on PHP.net. My password was truncated so I was unable to log in. Previous Comments: ---- [2014-07-06 06:33:59] [email protected] Automatic comment on behalf of [email protected] Revision: http://git.php.net/?p=web/bugs.git;a=commit;h=95f4f5a0ba20da1c1d0aa15294bfaa6c382cdaa1 Log: Fixed bug #67006 (login form in developer's section doesn't work) [2014-07-06 01:41:50] [email protected] Works for me. Get help from someone on list. -------- [2014-04-02 10:59:03] [email protected] Description: When I'm in "Developer" tab on bug page, I cannot login with my access data. I'm sure that I typed them correctly, because copying and pasting same data on bugs.php.net/login.php works just fine. -- Edit this bug report at https://bugs.php.net/bug.php?id=67006&edit=1 -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-WEBMASTER] Bug #67629 [Com]: Can't change language to English
Edit report at https://bugs.php.net/bug.php?id=67629&edit=1 ID: 67629 Comment by: [email protected] Reported by:qbolec at gmail dot com Summary:Can't change language to English Status: Verified Type: Bug Package:Website problem PHP Version:Irrelevant Block user comment: N Private report: N New Comment: "Interesting. Yes, this is caused by the fact Polish is not an official translation anymore and I am unsure how it is still accessible (should have been deleted)." I don't know why it's still there, but it also applies to some other inactive languages: http://php.net/manual/help-translate.php - last section on this page BTW: If we delete it from php.net, is it going to be still accessible on docs.php.net? Previous Comments: [2014-07-16 16:12:58] [email protected] Interesting. Yes, this is caused by the fact Polish is not an official translation anymore and I am unsure how it is still accessible (should have been deleted). The dropdown thinks this page must be in english since it doesn't have a polish value :) How did you get to that page anyway? [2014-07-16 12:28:43] lester at lsces dot co dot uk Is this simply because polish is not listed as an option on your view? Selecting any other language and returning to English works and is something I've simply got used to when Google returns a lookup in the wrong language :) [2014-07-16 10:49:05] qbolec at gmail dot com Description: --- >From manual page: http://www.php.net/function.iconv --- When I am at http://php.net//manual/pl/function.iconv.php (which displays Polish version) I'd like to change to English, but I can not, because English is the first and thus default option in the selectbox, and clicking on it does not trigger change/select or whatever event you are listening for. Expected result: Selecting English from the dropdown should change to English Actual result: -- Nothing happens, and I still see Polish version. -- Edit this bug report at https://bugs.php.net/bug.php?id=67629&edit=1 -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-WEBMASTER] Bug #67629 [Com]: Can't change language to English
Edit report at https://bugs.php.net/bug.php?id=67629&edit=1 ID: 67629 Comment by: [email protected] Reported by:qbolec at gmail dot com Summary:Can't change language to English Status: Verified Type: Bug Package:Website problem PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Okay, thanks. That is absolutely fine for me. It's useful to have preview on docs.php.net. I just realized that those languages archived on php.net are not building regularly. I think that we should burn them asap. Previous Comments: [2014-07-16 17:26:37] [email protected] @sobak: Yes, it would still be accessible on docs as that mirror builds all translations itself rather then rsync it. As you can see though, we've lost many archives throughout the years as its not actively maintained. Besides, very old translations can be actively harmful without somesort of notification of it being old and broken [2014-07-16 17:21:00] [email protected] "Interesting. Yes, this is caused by the fact Polish is not an official translation anymore and I am unsure how it is still accessible (should have been deleted)." I don't know why it's still there, but it also applies to some other inactive languages: http://php.net/manual/help-translate.php - last section on this page BTW: If we delete it from php.net, is it going to be still accessible on docs.php.net? [2014-07-16 16:12:58] [email protected] Interesting. Yes, this is caused by the fact Polish is not an official translation anymore and I am unsure how it is still accessible (should have been deleted). The dropdown thinks this page must be in english since it doesn't have a polish value :) How did you get to that page anyway? [2014-07-16 12:28:43] lester at lsces dot co dot uk Is this simply because polish is not listed as an option on your view? Selecting any other language and returning to English works and is something I've simply got used to when Google returns a lookup in the wrong language :) [2014-07-16 10:49:05] qbolec at gmail dot com Description: --- >From manual page: http://www.php.net/function.iconv --- When I am at http://php.net//manual/pl/function.iconv.php (which displays Polish version) I'd like to change to English, but I can not, because English is the first and thus default option in the selectbox, and clicking on it does not trigger change/select or whatever event you are listening for. Expected result: Selecting English from the dropdown should change to English Actual result: -- Nothing happens, and I still see Polish version. -- Edit this bug report at https://bugs.php.net/bug.php?id=67629&edit=1 -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-WEBMASTER] Bug #53703 [PATCH]: Cannot upload patches with chars < chr(32)
Edit report at https://bugs.php.net/bug.php?id=53703&edit=1 ID: 53703 Patch added by: [email protected] Reported by:jthijssen at noxlogic dot nl Summary:Cannot upload patches with chars < chr(32) Status: Assigned Type: Bug Package:Website problem Operating System: NA PHP Version:Irrelevant Assigned To:sobak Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: test-script Revision: 1407263271 URL: https://bugs.php.net/patch-display.php?bug=53703&patch=test-script&revision=1407263271 Previous Comments: [2011-01-09 21:50:13] jthijssen at noxlogic dot nl Description: The "add-a-patch" system in the php.net bug tracker will check for mime-types after uploading a patch. When a file has some low ascii-characters, it will not be detected correctly as a plain text file. The upload will not success in that case. There are some files in the php sources that have these low ascii characters present so patches on those files cannot be uploaded correctly. Test script: --- The files: ext/standard/tests/strings/strip_tags_variation5.phpt ext/standard/tests/strings/strip_tags_variation8.phpt ext/standard/tests/strings/strip_tags_variation9.phpt have some low ascii characters: ^K and ^L. Because of this, linux' "file" command detect those files "incorrectly": jthijssen@debian-jth:~/php-src-5.3$ file ext/standard/tests/strings/strip_tags_variation5.phpt ext/standard/tests/strings/strip_tags_variation5.phpt: data jthijssen@debian-jth:~/php-src-5.3$ file ext/standard/tests/strings/strip_tags_variation4.phpt ext/standard/tests/strings/strip_tags_variation4.phpt: ASCII C program text Expected result: The patch should be added to the bug Actual result: -- The bug database reports an incorrect filetype (detected: application/octet-stream) -- Edit this bug report at https://bugs.php.net/bug.php?id=53703&edit=1 -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-WEBMASTER] Bug #67426 [Com]: Bug tracker no longer shows quick fixes
Edit report at https://bugs.php.net/bug.php?id=67426&edit=1 ID: 67426 Comment by: [email protected] Reported by:[email protected] Summary:Bug tracker no longer shows quick fixes Status: Re-Opened Type: Bug Package:Website problem Operating System: Irrelevant PHP Version:Irrelevant Assigned To:sobak Block user comment: N Private report: N New Comment: What abot this? It seems that Johannes is right and in fact there is no problem with bugsweb - we just need more resolve reasons. However, I'm not sure if that's the way it worked before. Previous Comments: [2014-10-05 22:07:48] [email protected] The reason is that the bug is in a "project" with no quick fix option applicable. See bugsweg www/bug.php aroudn line 170 $project = $bug['project']; /* ...*/ if ($edit === 1) { list($RESOLVE_REASONS, $FIX_VARIATIONS) = get_resolve_reasons($project); } ($bug comes from the database) I think somebody should add some of the quick fixes to pecl, too. I don't have database access. -------- [2014-06-12 19:28:57] [email protected] Grrh, it works but only partially. It doesn't works for packages with PECL as a project. -------- [2014-06-12 19:11:56] [email protected] Seems it works. -------- [2014-06-12 18:48:58] [email protected] Probably the most unprofessional answer over here, but this commit SHOULD fix it. The reason why I'm unsure is that I don't know actual content of bugdb_pseudo_packages and schema in repo is poor. However, this change shouldn't break anything more so I will just leave this bug as open and wait for rsync. https://github.com/php/web-bugs/commit/2b13da9454abee46614cc058df3fc03a033eabe8 Regards. [2014-06-12 16:05:23] [email protected] Description: The bug tracker no longer shows any quick fixes: http://i.imgur.com/XgNC8eH.png The select itself still appears; it's just empty. -- Edit this bug report at https://bugs.php.net/bug.php?id=67426&edit=1 -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
