[PHP-DOC] Bug #17324 Updated: charset in polish chm is wrong
ID: 17324 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: win98 PHP Version: 4.2.1 New Comment: It's true. Additionaly, users can't search the manual because of incompatible charsets. I've investigated this problem about month ago. There is no other way to solve it than converting the whole manual to cp-1250 and changing meta before compiling chm. I hope it would be possible with the new version of chm. Previous Comments: [2002-05-20 19:50:39] [EMAIL PROTECTED] codepage in polish chm is wrong. In head of all html files included into chm documentation charset is set to iso8952-2 but letters are written like this: Rozdzia#179; instead of Rozdzia³ But also in list on the left, polish letters are shown wrong despite of that are written ok. best regards Andrzej Korcala -- Edit this bug report at http://bugs.php.net/?id=17324edit=1
Re: [PHP-DOC] cvs: phpdoc /en/functions imap.xml
Rasmus Lerdorf wrote: rasmusMon May 20 16:38:39 2002 EDT Modified files: /phpdoc/en/functions imap.xml Log: Add imap_popen() note stupid me, need more slep ... anyway, the en/function files only still around for CVS history digging, you want to change en/reference/imap/functions/imap-popen.xml instead -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 Wir stellen für Sie aus, auf der INTERNET WORLD in Berlin. Besuchen Sie uns vom 4. bis 6. Juni 2002 in Halle 4.2, Stand A9
[PHP-DOC] cvs: phpdoc /en/appendices aliases.xml
tom Tue May 21 13:16:43 2002 EDT Modified files: /phpdoc/en/appendices aliases.xml Log: deleted aliases to themselves Index: phpdoc/en/appendices/aliases.xml diff -u phpdoc/en/appendices/aliases.xml:1.18 phpdoc/en/appendices/aliases.xml:1.19 --- phpdoc/en/appendices/aliases.xml:1.18 Thu May 9 19:37:01 2002 +++ phpdoc/en/appendices/aliases.xmlTue May 21 13:16:42 2002 -1,5 +1,5 ?xml version=1.0 encoding=iso-8859-1? -!-- $Revision: 1.18 $ -- +!-- $Revision: 1.19 $ -- appendix id=aliases titleList of Function Aliases/title para -599,11 +599,6 entrylink linkend=ref.msqlmSQL/link/entry /row row - entrymsql_affected_rows/entry - entryfunctionmsql_affected_rows/function/entry - entrylink linkend=ref.msqlmSQL/link/entry -/row -row entrymsql_createdb/entry entryfunctionmsql_create_db/function/entry entrylink linkend=ref.msqlmSQL/link/entry -1454,11 +1449,6 entrylink linkend=ref.mingMing (flash)/link/entry /row row - entryswfbutton_keypress/entry - entryfunctionswfbutton_keypress/function/entry - entrylink linkend=ref.mingMing (flash)/link/entry -/row -row entryswffill/entry entryfunctionswffill_init/function/entry entrylink linkend=ref.mingMing (flash)/link/entry -1506,26 +1496,6 row entryunlink/entry entryfunctiondomxml_unlink_node/function/entry - entrylink linkend=ref.domxmlDOM XML/link/entry -/row -row - entryxpath_eval/entry - entryfunctionxpath_eval/function/entry - entrylink linkend=ref.domxmlDOM XML/link/entry -/row -row - entryxpath_eval_expression/entry - entryfunctionxpath_eval_expression/function/entry - entrylink linkend=ref.domxmlDOM XML/link/entry -/row -row - entryxpath_init/entry - entryfunctionxpath_init/function/entry - entrylink linkend=ref.domxmlDOM XML/link/entry -/row -row - entryxpath_new_context/entry - entryfunctionxpath_new_context/function/entry entrylink linkend=ref.domxmlDOM XML/link/entry /row row
[PHP-DOC] cvs: phpdoc-nl / language-defs.ent
derick Tue May 21 13:22:31 2002 EDT Modified files: /phpdoc-nl language-defs.ent Log: - Fix language-defs Index: phpdoc-nl/language-defs.ent diff -u phpdoc-nl/language-defs.ent:1.5 phpdoc-nl/language-defs.ent:1.6 --- phpdoc-nl/language-defs.ent:1.5 Thu Nov 22 16:11:12 2001 +++ phpdoc-nl/language-defs.ent Tue May 21 13:22:30 2002 -1,12 +1,14 !ENTITY PHPManual PHP Handleiding !ENTITY Date Datum: !ENTITY GettingStarted Om te beginnen +!ENTITY Installation Installatie !ENTITY LanguageReference Syntax !ENTITY Features Functionaliteit !ENTITY FunctionReference Functie naslag !ENTITY Appendixes Appendixes !ENTITY PEAR PEAR: the PHP Extension and Application Repository !ENTITY FAQFAQ: Frequently Asked Questions (veel gestelde vragen) -!ENTITY FAQabbrev FAQ -!ENTITY FunctionIndex Function Index - +!ENTITY FAQabbre FAQ +!ENTITY FunctionIndex Functie Index +!ENTITY CHMEdition HTML Help Editie +!ENTITY ReservedConstants Voorgedefineerde Constanten
[PHP-DOC] Bug #16792 Updated: [chm] bug on features.http-auth.html
ID: 16792 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Documentation problem Operating System: windows PHP Version: 4.1.2 New Comment: This bug can be closed after feedback about the version from http://weblabor.hu/php-doc-chm/manual_notes_test.zip tom Previous Comments: [2002-05-20 15:33:02] [EMAIL PROTECTED] Can you please test this with http://weblabor.hu/php-doc-chm/manual_notes_test.zip Thank you Goba [2002-04-24 14:01:47] [EMAIL PROTECTED] What OS do you exactly use? What IE do you have installed. Aren't there errors on other pages? This error should pop up on all pages all the time, or nowhere, or on all pages sometimes, depending on what is the real error ;) (Note for phpdoc bug readers: this is the form of bug reports from the new chms. I hope it is good enough. I have included automations to post page names and CHM dates for guys to be able to trace if this error is corrected since that CHM release or not.) [2002-04-24 09:14:07] [EMAIL PROTECTED] I have found a bug on page features.http-auth.html [chm date: 2002-04-20]... I found at least 2 bugs with the same message reported: 'document.all.unotes' is null or not an object Reported on openning following items: HTTP authentication with PHP and Function reference items on line 3, char 25. Manual php_manual_en.chm distributed in php_manual_sample_5.zip -- Edit this bug report at http://bugs.php.net/?id=16792edit=1
[PHP-DOC] Bug #12839 Updated: Descrepancy in Manual (Appendix G)
ID: 12839 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: win32 (9x SE) PHP Version: 4.0.6 New Comment: This bug has been fixed in CVS. You can grab a snapshot of the CVS version at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites. Thank you for the report, and for helping us make PHP better. Previous Comments: [2001-08-19 09:44:53] [EMAIL PROTECTED] Follow up on previous - Here's a quick list of what appears to be erratta in Appendix G: function listed as aliases to themselves: xpath_eval xpath_eval_expression xpath_init xpath_new_context As I'm still working my way through these, there may be more.. like the msql function prevously noted. [2001-08-19 07:22:36] [EMAIL PROTECTED] This may just be my misunderstanding.. in either case, i'm sure that if I'm a little confused, others might be as well. I've been working on assembling an expression file for HomeSite.. in so doing I wanted to create a set which highlights those functions which are aliases.. So, I'm working with Appendix G and noted the following: The appendix essentailly states the reverse of the function documentation... The manual indicates the chop() is an alias to rtrim(), while the appendix indicates the reverse, naming chop() the master function.. and rtrim() the alias...??? Also, on a different note - msql_affected_rows is labeled as as alias of itself? how can a function be an alias of itself? Can someone please clarify Appendix G? from the manual on chop: This function is an alias of rtrim(). Whil Appendix G indicates that chop() is the master function? This is repeated with most functions listed in G. Thanks, in advance for the input. -- Edit this bug report at http://bugs.php.net/?id=12839edit=1
[PHP-DOC] Bug #12868 Updated: Appendix G Descrepancies..
ID: 12868 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: win32 PHP Version: 4.0.6 New Comment: This bug has been fixed in CVS. You can grab a snapshot of the CVS version at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites. Thank you for the report, and for helping us make PHP better. Previous Comments: [2001-12-11 16:50:39] [EMAIL PROTECTED] This seems okay now. But, maybe the alias appendix should be auto-generated via something like genaliasindex ? [2001-08-21 13:35:12] [EMAIL PROTECTED] It doesn't matter at all indeed. For chop/rtrim: chop used to be main function, but since it's in perl and behaving differently over there, _and_ rtrim is consistent with trim and ltrim, I decided to document chop as the alias. Will update aliases.xml too. I recently suggested a better indication to aliases (in phpdoc/README - CONVENTIONS), but that hasn't been implemented yet - be patient. Btw: is_float will be master now, is_double the alias... PHP doesn't have double-precision floats, there's only one flavour. [2001-08-21 01:28:38] [EMAIL PROTECTED] Update status... [2001-08-21 01:28:13] [EMAIL PROTECTED] I don't understand why it matters which is the 'master' and which is the alias? I would guess that the reason for the inconsistency in the documentation is that it really doesn't matter which is which, so the doc team is not all that careful about it. But that's just a guess...this wouldn't be all that hard to clear up. FWIW, rtrim() is an alias to chop() and fputs() is an alias to fwrite(). [2001-08-21 00:12:18] [EMAIL PROTECTED] This is truly a followup to my previous post - message about what appears to be descrepancies in Appendix G.. which has further some confusion as to which functions are truly an alias and which is the master function.. I guess I need to understand what the master function is supposed to be, and what an alias is supposed to be. Perhaps I have these backwards, and thus the confusion, but some of this doesn't quite set right.. The first function in the list (chop) is labeled as the master function, and it's alias as (rtrim).. but when you go to the master function, (chop) it's documentation indicates it's the alias. and to see rtrim for details. There are some functions in this list like - fwrite() and fputs() - where fwrite is labled as the master and fputs the alias.. while the documentaion for both functions do not indicate either as an alias.. This goes on.. naturally some of these make perfect sense, if you looke at is_double() marked as a master - having aliases of is_float() and is_real().. the documentation corresponds perfectly.. i.e. if you call up is_float() or is_real() it directs you to is_double().. which brings some understanding back. and jives with what I would preceive as the relationship between a master function and an alias. Input on this matter would greatly be appreciated.. thanks a bunch. -- Edit this bug report at http://bugs.php.net/?id=12868edit=1
[PHP-DOC] cvs: phpdoc-nl / translation.xml
mathieu Tue May 21 14:24:31 2002 EDT Modified files: /phpdoc-nl translation.xml Log: - Added myself to translation.xml Index: phpdoc-nl/translation.xml diff -u phpdoc-nl/translation.xml:1.4 phpdoc-nl/translation.xml:1.5 --- phpdoc-nl/translation.xml:1.4 Fri Apr 5 08:41:52 2002 +++ phpdoc-nl/translation.xml Tue May 21 14:24:31 2002 @@ -11,10 +11,11 @@ translators person name=Dirkjan Ochtman email=[EMAIL PROTECTED] nick=manuzhai cvs=yes / person name=Derick Rethans email=[EMAIL PROTECTED] nick=derickcvs=yes / + person name=Mathieu Kooiman email=[EMAIL PROTECTED] +nick=mathieu cvs=yes / /translators work-in-progress - file name=chapters/intro.xml person=derick type=offline revision=1.32 date=01/04/2002 / + file name=chapters/intro.xml person=mathieu type=offline +revision=1.32 date=21/05/2002 / file name=functions/array.xmlperson=manuzhai type=offline revision=1.172 date=05/04/2002 / /work-in-progress
[PHP-DOC] cvs: phpdoc-nl / translation.xml
mathieu Tue May 21 14:28:15 2002 EDT Modified files: /phpdoc-nl translation.xml Log: - Make derick happy (names alphabetically) Index: phpdoc-nl/translation.xml diff -u phpdoc-nl/translation.xml:1.5 phpdoc-nl/translation.xml:1.6 --- phpdoc-nl/translation.xml:1.5 Tue May 21 14:24:31 2002 +++ phpdoc-nl/translation.xml Tue May 21 14:28:15 2002 @@ -9,9 +9,9 @@ /intro translators + person name=Mathieu Kooiman email=[EMAIL PROTECTED] +nick=mathieu cvs=yes / person name=Dirkjan Ochtman email=[EMAIL PROTECTED] nick=manuzhai cvs=yes / person name=Derick Rethans email=[EMAIL PROTECTED] nick=derickcvs=yes / - person name=Mathieu Kooiman email=[EMAIL PROTECTED] nick=mathieu cvs=yes / /translators work-in-progress
[PHP-DOC] cvs: phpdoc-nl / language-defs.ent
mathieu Tue May 21 14:54:41 2002 EDT Modified files: /phpdoc-nl language-defs.ent Log: - Fix typo (abbre - abbrev) Index: phpdoc-nl/language-defs.ent diff -u phpdoc-nl/language-defs.ent:1.6 phpdoc-nl/language-defs.ent:1.7 --- phpdoc-nl/language-defs.ent:1.6 Tue May 21 13:22:30 2002 +++ phpdoc-nl/language-defs.ent Tue May 21 14:54:40 2002 -8,7 +8,7 !ENTITY Appendixes Appendixes !ENTITY PEAR PEAR: the PHP Extension and Application Repository !ENTITY FAQFAQ: Frequently Asked Questions (veel gestelde vragen) -!ENTITY FAQabbre FAQ +!ENTITY FAQabbrev FAQ !ENTITY FunctionIndex Functie Index !ENTITY CHMEdition HTML Help Editie !ENTITY ReservedConstants Voorgedefineerde Constanten
[PHP-DOC] cvs: phpdoc-nl / translation.xml /chapters intro.xml
mathieu Tue May 21 15:34:14 2002 EDT Modified files: /phpdoc-nl/chapters intro.xml /phpdoc-nl translation.xml Log: - Fix'N Finish intro.xml, bump 1.32 to 1.34 Index: phpdoc-nl/chapters/intro.xml diff -u phpdoc-nl/chapters/intro.xml:1.10 phpdoc-nl/chapters/intro.xml:1.11 --- phpdoc-nl/chapters/intro.xml:1.10 Mon Apr 1 12:26:30 2002 +++ phpdoc-nl/chapters/intro.xmlTue May 21 15:34:08 2002 -1,14 +1,14 ?xml version=1.0 encoding=iso-8859-1? -!-- EN-Revision: 1.32 Maintainer: derick Status: partial -- +!-- EN-Revision: 1.34 Maintainer: derick Status: ready -- chapter id=introduction - titleIntroduction/title + titleIntroductie/title sect1 id=intro-whatis titleWat is PHP?/title simpara PHP (officieel PHP: Hypertext Preprocessor) is een veel gebruikte Open Source general-purpose scripting taal die speciaal is uitgerust voor Web -development, en kan worden embed in HTML. +development en kan in HTML worden ingekapseld. /simpara para Dat was een simpel antwoord, maar wat wordt er mee bedoeld? Een voorbeeld: -36,7 +36,7 /para para Zie je hoe verschillend dit is van een script geschreven in andere -talen zoals Perl of C -- in plaats van een programma te schrijven met +talen zoals Perl of C ? In plaats van een programma te schrijven met veel commando's om HTML te laten zien, kun je een HTML script scrhijven met ingebouwde code die iets doen (in dit geval een stuk tekst laten zien). De PHP code is omgeven door speciale link -45,24 +45,23 stappen. /para para -Wat PHP onderscheid van client-side talen zoals Javascript is dat -de code op de server wordt uitgevoerd. Als een een gelijk achtig -script gebruikt zoals het hierboven staande voorbeeld, zal de browser -de resultaten van het script ontvangen en zal op geen enkele manier +Wat PHP onderscheidt van client-side talen zoals Javascript is dat +de code op de server wordt uitgevoerd. Als een soortgelijk +script wordt gebruikt zoals het hier boven staande voorbeeld, zal de browser +de resultaten van het script ontvangen en zal deze op geen enkele manier kunnen achterhalen wat de onderliggende code is. Het is zelfs mogelijk -om alle HTML bestanden op jouw website te laten parsen door PHP, en -er is geen enkele manier dat gebruikers merken dat er ook maar iets -gaande is. +om alle HTML bestanden op jouw website te laten parsen door PHP zonder dat je +gebruikers door hebben dat dit gebeurd. /para para -De mooiste dingen van PHP is dat het relatief eenvoudig is voor een +Een van de mooiste dingen van PHP is dat het relatief eenvoudig is voor een beginner, maar dat het nog steeds krachtig is voor de professionele gebruiker. U hoeft niet bang te zijn van de enorme lijst functies die PHP heeft. U kunt eenvoudig instappen, en in een korte tijd simpele scripts schrijven. /para para -Alhoewel PHP is gefocussed overe server-side scripting kunt u er nog veel +Alhoewel PHP vooral gebruikt wordt voor Webdevelopment kan je er nog veel meer mee doen. Lees verder, en leer meer in de sectie link linkend=intro-whatcandoWat kan PHP voor u betekenen?/link. /para -71,7 +70,7 sect1 id=intro-whatcando titleWat kan PHP voor u betekenen?/title para -Alles. PHP is vooral bedoeld voor server-sie scripting, dus u kunt alles +Alles. PHP is vooral bedoeld als server-side scripting taal, dus je kan alles doen wat elk ander CGI script kan doen, zoals het ophalen van form gegevens, het genereren van dynamisch pagina's of het sturen en ontvangen van cookies. Maar PHP kan veel meer betekenen. -81,82 +80,77 itemizedlist listitem simpara - Server-side scripting. This is the most traditional - and main target field for PHP. You need three things - to make this work. The PHP parser (CGI or server - module), a webserver and a web browser. You need to - run the webserver, with a connected PHP installation. - You can access the PHP program output with a web browser, - viewing the PHP page through the server. See the - link linkend=installationinstallation instructions/link - section for more information. + Server-side scripting. Dit is het meest traditionele + en tevens het hoofd doel van PHP. Om dit aan de praat + te krijgen heb je 3 dingen nodig. De PHP parser (CGI of server + module), een webserver en natuurlijk een web browser. De + webserver dient te draaien met een werkende PHP installatie. + Door nu met de web browser de PHP pagina op te vragen kun je het + resultaat van het script zien. Voor meer informatie kun je bij de + sectie link linkend=installationinstallatie instructies/link + kijken. /simpara /listitem listitem simpara -
[PHP-DOC] Bug #16660 Updated: Documentation bz2 archive format is not appropriate
ID: 16660 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Windows PHP Version: 4.2.0 New Comment: The problem with HTML-Help is that it does only run on true win machines with IE4+, not on Unixes, PDAs or old Win machines (Laptops). I.e. if you _organize_ your docs on a late win machine but _use_ them on others you get problems with bz2. Why not offer _both_ formats bz2 and tar.gz? Any religious reasons? Once again, least astonishment should rule. Previous Comments: [2002-04-26 10:43:45] [EMAIL PROTECTED] Hm, I don't understand it either... But maybe... Maybe the HTMLHelp is too windowish, and the bz2 compression too unixish? I think we should stick to RARed Klingonese. [2002-04-26 10:39:47] [EMAIL PROTECTED] What is the problem with the HTML Help manuals? Why do we go too far?? BTW we already decided to provide .tar.gz files again, just it seems it didn't make it to the generation system... [2002-04-26 10:29:47] [EMAIL PROTECTED] I think the problem is a lack of choice. bz2 might be better than other formats, but you (people at php.net) are little going too far with bz2 and that HTML Help... [2002-04-17 12:40:46] [EMAIL PROTECTED] Nope, this is a documentation problem. [2002-04-17 11:42:30] [EMAIL PROTECTED] Reclassified. -Tal 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 http://bugs.php.net/16660 -- Edit this bug report at http://bugs.php.net/?id=16660edit=1
[PHP-DOC] Bug #16660 Updated: Documentation bz2 archive format is not appropriate
ID: 16660 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Windows PHP Version: 4.2.0 New Comment: We have special formats for PDAs, we have PDF which is quite system independent. So I still don't know why we have gone too far with a special HTML Help format? BTW we already agreed on hosting the .tar.gz formats again, just noone activated the builds and downloads again... Previous Comments: [2002-05-21 15:49:37] [EMAIL PROTECTED] The problem with HTML-Help is that it does only run on true win machines with IE4+, not on Unixes, PDAs or old Win machines (Laptops). I.e. if you _organize_ your docs on a late win machine but _use_ them on others you get problems with bz2. Why not offer _both_ formats bz2 and tar.gz? Any religious reasons? Once again, least astonishment should rule. [2002-04-26 10:43:45] [EMAIL PROTECTED] Hm, I don't understand it either... But maybe... Maybe the HTMLHelp is too windowish, and the bz2 compression too unixish? I think we should stick to RARed Klingonese. [2002-04-26 10:39:47] [EMAIL PROTECTED] What is the problem with the HTML Help manuals? Why do we go too far?? BTW we already decided to provide .tar.gz files again, just it seems it didn't make it to the generation system... [2002-04-26 10:29:47] [EMAIL PROTECTED] I think the problem is a lack of choice. bz2 might be better than other formats, but you (people at php.net) are little going too far with bz2 and that HTML Help... [2002-04-17 12:40:46] [EMAIL PROTECTED] Nope, this is a documentation problem. 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 http://bugs.php.net/16660 -- Edit this bug report at http://bugs.php.net/?id=16660edit=1
[PHP-DOC] Bug #16660 Updated: Documentation bz2 archive format is not appropriate
ID: 16660 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Windows PHP Version: 4.2.0 New Comment: To make the point clear: HTML-help is great on Win-machines - so thanks for the good work to the people who did it! bz2 will be fine as soon as Winzip supports it. For now: Let's get tar.gz back asap. Previous Comments: [2002-05-21 16:46:43] [EMAIL PROTECTED] We have special formats for PDAs, we have PDF which is quite system independent. So I still don't know why we have gone too far with a special HTML Help format? BTW we already agreed on hosting the .tar.gz formats again, just noone activated the builds and downloads again... [2002-05-21 15:49:37] [EMAIL PROTECTED] The problem with HTML-Help is that it does only run on true win machines with IE4+, not on Unixes, PDAs or old Win machines (Laptops). I.e. if you _organize_ your docs on a late win machine but _use_ them on others you get problems with bz2. Why not offer _both_ formats bz2 and tar.gz? Any religious reasons? Once again, least astonishment should rule. [2002-04-26 10:43:45] [EMAIL PROTECTED] Hm, I don't understand it either... But maybe... Maybe the HTMLHelp is too windowish, and the bz2 compression too unixish? I think we should stick to RARed Klingonese. [2002-04-26 10:39:47] [EMAIL PROTECTED] What is the problem with the HTML Help manuals? Why do we go too far?? BTW we already decided to provide .tar.gz files again, just it seems it didn't make it to the generation system... [2002-04-26 10:29:47] [EMAIL PROTECTED] I think the problem is a lack of choice. bz2 might be better than other formats, but you (people at php.net) are little going too far with bz2 and that HTML Help... 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 http://bugs.php.net/16660 -- Edit this bug report at http://bugs.php.net/?id=16660edit=1
[PHP-DOC] Bug #17344: memory_limit still deceiving
From: [EMAIL PROTECTED] Operating system: FreeBSD PHP version: 4.2.1 PHP Bug Type: Documentation problem Bug description: memory_limit still deceiving I just compiled 4.2.1 and looked at the supplied php.ini files, and there still is no indication that --enable-memory-limit needs to be enabled. In php.ini, there simply is: max_execution_time = 30 memory_limit = 8M Very misleading. Thanks, Hans -- Edit bug report at http://bugs.php.net/?id=17344edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17344r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17344r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17344r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17344r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17344r=support Expected behavior: http://bugs.php.net/fix.php?id=17344r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17344r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17344r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17344r=globals
[PHP-DOC] Bug #14770 Updated: phps truncates long sources
ID: 14770 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Linux/Windows 98SE PHP Version: 4.2.0 Assigned To: yohgaki New Comment: Dillo (http://dillo.cipsga.org.br/) handles .phps files fine, though others (mozilla, ie) don't. And as a user of .phps, I'd just like to venture the humble opinion that it's more secure and convenient in many cases to make a symlink than a security-conscious source viewer program. Previous Comments: [2002-04-25 23:14:14] [EMAIL PROTECTED] Thanks for reply. Here is why, phps feature is implemented as Zend feature. Therefore, it does not work well with output bufffering, since output buffering is PHP feature. (some problems with output like you have, don't work with built in output callback functions, etc) hilight_file (show_source or highlight_string) provides the same feature with much better way. If you are using apache and mod_rewrite, you can have script like ?php // If you need access control write here. $filename = // Code to dicide file to show $src = hilight_file($filename, TRUE); // Do what ever you need // Add header/footer, translate encoding, etc print $src; ? to show sources you want to hilight. You don't even have to create symlinks and this method works with any configuration. Refer to mod_rewrite manual how you can do that w/o creating files. BTW, last time I checked, phps does not work with zlib.output_compression. I might be able to make phps work under any configuration, but I don't think it worth to do. (Patches are welcome, though) [2002-04-25 22:46:07] [EMAIL PROTECTED] As per my first post ;) ... Yes, 4.2.0, and yes on Linux. I'm not the original reporter, I can't update this bug's fields. I have to ask why .phps won't be used. It's -very- convenient and well established in the community. What is as simple using show_source()? At present all I had to do was make a symlink to my source with .phps as the extension. Irrespective, my source is plain english, no special chars involved, etc. [2002-04-25 19:29:33] [EMAIL PROTECTED] After document is updated I'll take a look at output buffering code. (If there is problem here, it should be fixed) David, Did you tested with 4.2.0? What is your OS? Please update Version and OS field, thanks. [2002-04-25 19:20:15] [EMAIL PROTECTED] This problem probably will not be fixed. 1) It does not worth the effort. 2) There is show_source() 3) phps does not work under certain encodings. Use show_source() instead... I made this report as Documentation problem to encourage use of show_source(). Someday, when ZendEngine became fully i18n, someone may care to fix phps. [2002-04-25 18:16:06] [EMAIL PROTECTED] Setting output_buffering to anything over 16386 (which by the way is the magic number of bytes that wget/lynx fetch, breaks all attempts at fetching the source. Note, the php script itself still performs fine. 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 http://bugs.php.net/14770 -- Edit this bug report at http://bugs.php.net/?id=14770edit=1
