Re: [PHP-DOC] reference: where to obtain files. was Re: [PHP-DOC]cvs: phpdoc /en/faq obtaining.xml
I see three options: a) Update the faq by hand with links used in reference.xml b) Create an autogenerated list here c) Remove most of the faq and simply state that the info has been moved as each extension now lists how to obtain.. I like the idea of (c). I also like the idea of (b) in the future but this doesn't really belong in the faq but rather when we finally autogenerate a list of all configure options, it'd go near there. c) + autogenerate the list in the future to an appendix. This information should really be in the reference sections, and not in a faq. This information is core. On a related note. Windows dll information should be listed within every reference.xml too as currently only some list this information. Like: a) If the dll is bundled b) If it's compiled in the binary (no dll needed) c) If the dll can be found offsite (mcrypt is an example) Windows dll information should also be moved out of the install (or configure?) section where it is currently (a list of Windows dlls), and moved to the reference sections with all information available ;) Goba -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] manual page uncluttering
1. Put language listing into a dropdown, not a link list. +1 for me, and while we are at this: why dont change the names > of the various languages to those in that language (i.e.: 'italian' > would become 'italiano' and 'german' would become 'deutsch')? what do you think? Well, that name list is something we use at every place. Now that language name list is used to: - print out available languages at docs.php and download-docs.php - print out language switch information on all manual pages - print out mirror language information on mirrors.php - it is also remotely included in the mirror administration page So the phpweb/include/languages.inc is a central place where all possible manual languages are defined and used in all places possible. Therefore I think this modification is not right now. By the way I am thinking about some methods to enable php.net to be translated, but I am actually unable to come up with a really good working solution in my mind... Maybe it needs some time to get some form... 2. Remove link underline from left sidebar links. +1 but with a caveat: add some way to be sure that the reader know > that those are actual links (dont give it for granted). I would > prefer having an 'hover' rule in the style sheet, so when the > mouse is hover them they change color or something. I think you > got what I mean. OK for me. Goba -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] once again: install part
Three main parts divided by OS. - MacOS - Linux Apache Apache2 thttp - Unices like HP/UX, BSD'S - Windows Apache Apache2 IIS/PWS Netscape OmniHTTP Sambar Xitami Each main OS-chapter contains: Installation of PHP Supported Webservers and install instructions Cool +1. I think this would be more user friendly and better to maintain. Some Informations from the install files are hard to find, spread over different places, sometimes even double. Yep. The current structure is very bad. We need more deep sections (not sections emulated in titles). The current state is quite bad. The files also need a polish, rename, etc. It will be a hard time to move user notes with the pages, so this also need to be taken with care. Maybe integrate all possible user notes and drop the others... I don't care about if you get boring about this old story. Asap I search the archives for the often discussed but never descided topic. The results will go in RFC, also the upcoming answers in this thread. Wow ;) Some progress! :)) Goba -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] cvs: phpdoc /en/reference/wddx/functionswddx-add-vars.xml
- wddx_add_vars + boolwddx_add_vars Shouldn't make test check for this type of error? Like, a missing return type! As long as the DTD does not require it, it is not a problem for make test... And the DocBook DTD has no requirement to have a type there... http://www.docbook.org/tdg/en/html/methodsynopsis.html We can of course modify that to require the type, but that needs a customization of the DTD [which I proposed for the sections already at dtds/phpbook.dtd]. The customization to require a type would do no harm, as it is even backward compatible to DocBook... Goba -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] manual page uncluttering
At 12.40 25/01/03 +0100, Gabor Hojtsy wrote: >>>1. Put language listing into a dropdown, not a link list. >>+1 for me, and while we are at this: why dont change the names >> of the various languages to those in that language (i.e.: 'italian' >> would become 'italiano' and 'german' would become 'deutsch')? >>what do you think? > >Well, that name list is something we use at every place. Now that language name list >is used to: > > - print out available languages at docs.php and download-docs.php > - print out language switch information on all manual pages > - print out mirror language information on mirrors.php > - it is also remotely included in the mirror administration page Ok, my fault. I underestimated these problems. And this would be too much work for too little improvement. -- Simone Cortesi http://cortesi.com/ blog * photos * PHP in italian did I help you? http://cortesi.com/wishlist.php -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] Notes Status, 8630 total
Following are the top 20 pages of the manual, sorted by the number of user notes contributed. These sections could use a polish, those notes represent 11.4% of the 8630 total user notes. Notes | Page ---+- 84 | http://php.net/manual/en/function.preg-replace.php 64 | http://php.net/manual/en/language.oop.php 61 | http://php.net/manual/en/features.file-upload.php 58 | http://php.net/manual/en/function.header.php 55 | http://php.net/manual/en/ref.imap.php 54 | http://php.net/manual/en/ref.pdf.php 53 | http://php.net/manual/en/function.include.php 52 | http://php.net/manual/en/function.fopen.php 49 | http://php.net/manual/en/function.mail.php 48 | http://php.net/manual/en/function.exec.php 47 | http://php.net/manual/en/ref.mail.php 42 | http://php.net/manual/en/function.date.php 41 | http://php.net/manual/en/function.eval.php 41 | http://php.net/manual/en/ref.domxml.php 41 | http://php.net/manual/en/ref.exec.php 39 | http://php.net/manual/en/ref.oci8.php 39 | http://php.net/manual/en/function.mssql-connect.php 38 | http://php.net/manual/en/function.md5.php 38 | http://php.net/manual/en/function.imagettftext.php 38 | http://php.net/manual/en/function.mktime.php -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/reference/mysql/functions mysql-get-proto-info.xml
derick Sat Jan 25 12:16:34 2003 EDT Modified files: /phpdoc/en/reference/mysql/functionsmysql-get-proto-info.xml Log: - I am not picky :) Index: phpdoc/en/reference/mysql/functions/mysql-get-proto-info.xml diff -u phpdoc/en/reference/mysql/functions/mysql-get-proto-info.xml:1.5 phpdoc/en/reference/mysql/functions/mysql-get-proto-info.xml:1.6 --- phpdoc/en/reference/mysql/functions/mysql-get-proto-info.xml:1.5Sun Dec 1 21:37:29 2002 +++ phpdoc/en/reference/mysql/functions/mysql-get-proto-info.xmlSat Jan 25 +12:16:34 2003 @@ -1,5 +1,5 @@ - + @@ -35,7 +35,7 @@ -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] documenting new function
On Sat, 25 Jan 2003 07:06:13 +0900 Moriyoshi Koizumi <[EMAIL PROTECTED]> wrote: > On Fri, Jan 24, 2003 at 10:27:00PM +0100, Maxim Maletsky wrote: > > I would need to add a few changes to the NEWS file. I remember trying it a > > while ago, but at the moment `@-' prefixing of CVS commit message did > > not work. Would anyone offer to add a few entries to the NEWS file for > > me? The two entries are as follows: > > > > - Added OCIPasswordChange() which allows renewing the expired Oracle users. > > (Maxim) > > - Fixed bug #16798 (Compile failure with LOB support for Oracle versions > > under 8.1). (Maxim) > > Why don't you add the entries to NEWS by hand? It seems that I don't have the karma for it, Moriyoshi. --- Maxim Maletsky [EMAIL PROTECTED] -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21877 [NEW]: fread may read less bytes than requested even if EOF is not reached ...
From: [EMAIL PROTECTED] Operating system: * PHP version: 4CVS-2003-01-25 (stable) PHP Bug Type: Documentation problem Bug description: fread may read less bytes than requested even if EOF is not reached ... i asume this not only true for C fread() but also for PHP ? if so -> should be documented as such ... -- Edit bug report at http://bugs.php.net/?id=21877&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21877&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21877&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21877&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21877&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21877&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21877&r=support Expected behavior: http://bugs.php.net/fix.php?id=21877&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21877&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21877&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21877&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21877&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21877&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21877&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21877&r=gnused -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21877 [Opn]: fread may read less bytes than requested even if EOF is not reached ...
ID: 21877 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: * PHP Version: 4CVS-2003-01-25 (stable) Assigned To: hholzgra New Comment: ok, it only true for non-blocking php streams ... but still this should be mentioned on the fread() page Previous Comments: [2003-01-25 12:56:17] [EMAIL PROTECTED] i asume this not only true for C fread() but also for PHP ? if so -> should be documented as such ... -- Edit this bug report at http://bugs.php.net/?id=21877&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19862 [Opn->Bgs]: online documentation is bugged...
ID: 19862
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Documentation problem
Operating System: any
PHP Version: 4.2.3
New Comment:
see http://php.net/xml_parse :
[...]
data
Chunk of data to parse. A document may be parsed piece-wise by
calling xml_parse() several times with new data, as long as the
is_final parameter is set and TRUE when the last data is parsed.
is_final (optional)
If set and TRUE, data is the last piece of data sent in this parse.
[...]
it is totaly valid to split data chunks wherever you want,
you may even feed xml_parse() character by character.
the manual example will not only work for local files but also for e.g.
http: remote streams where you can't get the input size in advance, and
for any kind of non-blocking stream where fread() may return less than
the requested number of bytes even if EOF is not yet reached
Previous Comments:
[2002-10-11 08:54:43] [EMAIL PROTECTED]
Expat is a SAX parser. It can handle blocks (or streams as they're
preferred to be called these days) and doesn't care whether a document
is valid or even when it is a document.
The point of using a stream-based parser, is that you're not required
to open up files entirely (in fact - your input can be a socket).
Allthough the manual example dies, as soon as a parser error is
detected, one can actually retrieve the linenumber of the error, store
everything from that line on in a buffer, process the lines before that
and retrieve the next block, appending it to the buffer.
So I agree, the example is not very useful in some cases, but not for
your reasoning.
[2002-10-11 08:01:36] [EMAIL PROTECTED]
URL: http://www.php.net/manual/en/ref.xml.php
how the files are opened is not the correct way or the input/output may
get mixed up or truncated on same cases...
I mean ... you should not open files in blocks, but whole file ... I
copy pasted your example to my code and when some block (of those 4096
bytes) end and next blocks start value somehow happened to be in the
middle XML value, then the value was truncated or cutted half in
output. anyway the input (cycle) should be in one piece (whole file at
once) or row by row, not by constant number of bytes.
Example 1. (your version)
$file = "data.xml";
$depth = array();
function startElement($parser, $name, $attrs) {
global $depth;
for ($i = 0; $i < $depth[$parser]; $i++) {
print " ";
}
print "$name\n";
$depth[$parser]++;
}
function endElement($parser, $name) {
global $depth;
$depth[$parser]--;
}
$xml_parser = xml_parser_create();
xml_set_element_handler($xml_parser, "startElement", "endElement");
if (!($fp = fopen($file, "r"))) {
die("could not open XML input");
}
while ($data = fread($fp, 4096)) {
if (!xml_parse($xml_parser, $data, feof($fp))) {
die(sprintf("XML error: %s at line %d",
xml_error_string(xml_get_error_code($xml_parser)),
xml_get_current_line_number($xml_parser)));
}
}
xml_parser_free($xml_parser);
BUT THIS SHOULD BE (my version):
Example 1.
$file = "data.xml";
$depth = array();
function startElement($parser, $name, $attrs) {
global $depth;
for ($i = 0; $i < $depth[$parser]; $i++) {
print " ";
}
print "$name\n";
$depth[$parser]++;
}
function endElement($parser, $name) {
global $depth;
$depth[$parser]--;
}
$xml_parser = xml_parser_create();
xml_set_element_handler($xml_parser, "startElement", "endElement");
if (!($fp = fopen($file, "r"))) {
die("could not open XML input");
}
$data = fread($fp, filesize($file)));
if (!xml_parse($xml_parser, $data, feof($fp)))
{
die(sprintf("XML error: %s at line %d",
xml_error_string(xml_get_error_code($xml_parser)),
xml_get_current_line_number($xml_parser)));
}
xml_parser_free($xml_parser);
--
Edit this bug report at http://bugs.php.net/?id=19862&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20522 [Opn->Csd]: german+spanish translation: $HTTP_ENCODING instead of $HTTP_ACCEPT_ENCODING
ID: 20522 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: N/A PHP Version: 4.2.2 Assigned To: k.schroeder New Comment: fixed in CVS Previous Comments: [2002-11-20 12:02:34] [EMAIL PROTECTED] I think there is a mistake in the german translation http://www.php.net/manual/de/language.variables.predefined.php and in the file language.variables.predefined.html in the german offline/downloadable version (03-11-2002) "$HTTP_ENCODING Inhalt des Accept-Encoding:-Headers der aktuellen Anforderung (wenn es einen gibt). Beispiel: 'gzip'." I think it should say: $HTTP_ACCEPT_ENCODING instead of $HTTP_ENCODING --- On my Apache/1.3.26 with PHP/4.2.2 $HTTP_ENCODING is undefined, i.e. isset($HTTP_ENCODING)==false whereas $HTTP_ACCEPT_ENCODING contains the Accept-Encoding Header, e.g. for Mozilla: "gzip, deflate, compress;q=0.9" --- The German version http://www.php.net/manual/de/language.variables.predefined.php seems to be quite old (or even outdated?) and is very different from the English version and all other translations (which have the warning concerning register_globals etc.) http://www.php.net/manual/en/language.variables.predefined.php --- I think there is quite a similar error in the spanish translation, which also is older and different from the English version: http://www.php.net/manual/es/language.variables.predefined.php "HTTP_ENCODING Los contenidos de la cabecera Accept-Encoding: de la petición actual, si la hay. Por ejemplo: 'gzip'." I think that there, too, it should say HTTP_ACCEPT_ENCODING instead of HTTP_ENCODING --- Kind regards from Switzerland Thomas Luethi -- Edit this bug report at http://bugs.php.net/?id=20522&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20570 [Opn->Csd]: description of MAX_FILE_SIZE should be clear
ID: 20570 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: independency PHP Version: 4.3.0RC1 New Comment: there is no step 3, php itself does not check MAX_FILE_SIZE (unless your script does) will add the "user won't have to wait to long" part Previous Comments: [2002-11-22 08:38:47] [EMAIL PROTECTED] [quote from php manual mian>>feature>>handling file uploads] The MAX_FILE_SIZE hidden field must precede the file input field and its value is the maximum filesize accepted. The value is in bytes. [warnning] warning: The MAX_FILE_SIZE is advisory to the browser. It is easy to circumvent this maximum. So don't count on it that the browser obeys you wish! The PHP-settings for maximum-size, however, cannot be fooled. [/warnning] [/quote] it doesn't tell how php check the size 1 year ago I 1st time read it, and re-read it today, finally get what it means document should tell more to programmers: -- 1. user's file size is checked at the beginning of transfer before upload is done 2. hard limit: file size is check against "PHP-settings for maximum-size", file which larger will be refused 3. then, soft limit: check against "MAX_FILE_SIZE" if there is one hidden value before input file field 4. when transfer done, php-script is active, manage to store the uploaded-file, however, value of MAX_FILE_SIZE easy to circumvent, and cannot be trust on, your php-script should re-check the uploaded file size as u wish. FAQ: u said MAX_FILE_SIZE is untrustable, why we should make use of it? why not use only php-script to check filesize? answer: in current php, handling of upload file, scirpt is not active, thus, cannot check filesize until transfer of upload file is done. MAX_FILE_SIZE get ability to soft limit the filesize before user have to wait too long. -- this is what i comprehend :) yes, it's too long, hope u guys can refine it, and put into new version of phpmanual -- Edit this bug report at http://bugs.php.net/?id=20570&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20644 [Opn]: Incrementing/Decrementing booleans != boolean+1
ID: 20644 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: all PHP Version: 4.3.0-dev New Comment: compare this to $a = "a"; $a = $a + 1; and $a = "a"; $a = $a++; ++ is defined as increment, which may have different meanings on different types it is *not* defined as "is always the same as +=1 " so it is definetly not a bug IHMO the documentation issue is still valid Previous Comments: [2002-11-27 04:24:49] [EMAIL PROTECTED] it's still not a bug, and there was some discussion about this on php-dev or some other list a while ago..can't find that now thouhg, but there was also "fix" for this, but it was reverted. (iirc) [2002-11-27 02:56:32] [EMAIL PROTECTED] Please explain how this is to be documented (why this isn't a bug) as I fail to understand the seemingly inconsistent behavior of this example: $t = true; $a = $t + 1; (same as $t += 1; // 2) $b = ++$t; print "a: $a b: $b"; // a: 2 b: 1 In otherwords, incrementing/decrementing a boolean keeps it as boolean while adding an integer, such as 1, changes it to an integer. Reclassifying as a scripting engine problem so php-dev gets this report. Please provide a documentable reason for this behavior. [2002-11-27 01:49:34] [EMAIL PROTECTED] Reclassified. [2002-11-27 01:24:49] [EMAIL PROTECTED] it was really an user error, sorry. i found than "++" operator doesn't make type conversion from boolean to int, and if variable is boolean and equals TRUE than after ++ it remains as TRUE, so $a = TRUE; echo ($a++).$a; produces output "11" this behavior of increment operator was unexpected to me and i suppose that it can be the same to others, so i wrote an user note at "type juggling" part at online documentation [2002-11-26 20:37:54] [EMAIL PROTECTED] Not known and most likely user error. Please provide a reproducing script. 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/20644 -- Edit this bug report at http://bugs.php.net/?id=20644&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] win32 builtin zlib
Hi, I rewrote the part in the phpdoc manual about building on windows. zlib is builtin with 4.3.0 but the shipped Workspace for VC++ relies on a precompilded external zlib.lib. Therefore building on win32, out of the box, is not possible without downloading zlib sources, compiling them and either modify the workspace or figure out where to place zlib.lib. Two points: 1.) In the released 4.3.0 source dist, the workspace points to ../../zlib, 2.) for example snapshot php4-STABLE-200301241430 points to ../../zlib/Release This is hard to document 1.) Are there future plans to include the zlib sources? 2.) Should users be advised to modify config.win32.h.in 3.) Should users be advised to download zlib sources, building zlib.lib? Thanks for any thoughts, suggestions, corrections Regards Friedhelm Betz -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] Re: [PHP-DEV] win32 builtin zlib
At 19:59 25/01/2003, Friedhelm Betz wrote: Hi, I rewrote the part in the phpdoc manual about building on windows. zlib is builtin with 4.3.0 but the shipped Workspace for VC++ relies on a precompilded external zlib.lib. Therefore building on win32, out of the box, is not possible without downloading zlib sources, compiling them and either modify the workspace or figure out where to place zlib.lib. Two points: 1.) In the released 4.3.0 source dist, the workspace points to ../../zlib, 2.) for example snapshot php4-STABLE-200301241430 points to ../../zlib/Release This is hard to document 1.) Are there future plans to include the zlib sources? No. zlib is included in a similar way to the way we include bindlib_w32. It's in a different repository on cvs.php.net, that we expect to be checked out and built by the time you build PHP. 2.) Should users be advised to modify config.win32.h.in Nope (this particular file doesn't exist anymore, btw) 3.) Should users be advised to download zlib sources, building zlib.lib? Not sure - I think that zlib should be in the win32build.zip archive. If you put it where bindlib_w32.lib is, we should be fine :) Zeev -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] Re: [PHP-DEV] win32 builtin zlib
Saturday, January 25, 2003, Zeev Suraski wrote: >>1.) Are there future plans to include the zlib sources? > No. zlib is included in a similar way to the way we include > bindlib_w32. It's in a different repository on cvs.php.net, that we expect > to be checked out and built by the time you build PHP. Ok, from users point the same... Maybe my question was a bit misleading, I meant provided within win32build.zip, maybe. >>2.) Should users be advised to modify config.win32.h.in > Nope (this particular file doesn't exist anymore, btw) Hm, you are right, at least not in the snapshots, but in the official release 4.3.0 from php.net... anyway. >>3.) Should users be advised to download zlib sources, building >> zlib.lib? > Not sure - I think that zlib should be in the win32build.zip archive. Nope;-) As zlib is builtin and the workspaces rely on, it would be really nice for users if they are done by downloading php4.xxx.tar.gz, win32build.zip and bindlib_w32.zip, the way like other standard builtin modules are fine with. So what would be the "offical" advise from php.net showing up in the manual? Checking out zlib from cvs? Where to place, so that the workspaces shipped with releases from php.net working out of the box? Regards Friedhelm Betz -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] Re: [PHP-DEV] win32 builtin zlib
On Sat, 25 Jan 2003 18:59:37 +0100 Friedhelm Betz <[EMAIL PROTECTED]> wrote: > Hi, > > I rewrote the part in the phpdoc manual about building on windows. > zlib is builtin with 4.3.0 but the shipped Workspace for VC++ > relies on a precompilded external zlib.lib. This is just what I run into a few hours ago trying to build php5 checkout with VC6. > Therefore building on win32, out of the box, is not possible without > downloading zlib sources, compiling them and either modify the > workspace or figure out where to place zlib.lib. I had to download zlib.lib from w3c.org before building (here: http://dev.w3.org/cvsweb/libwww/Library/External/zlib.lib?sortby=file) > Two points: > > 1.) In the released 4.3.0 source dist, the workspace points to ../../zlib, > 2.) for example snapshot php4-STABLE-200301241430 points to > ../../zlib/Release > > This is hard to document > > 1.) Are there future plans to include the zlib sources? probably the quickiest way, unless there are some problems with it, not really sure. > 2.) Should users be advised to modify config.win32.h.in This would mean that every distribution would have to be modified beforeit is built for win32, not the best way IMO. > 3.) Should users be advised to download zlib sources, building > zlib.lib? The link above from w3c could be a good idea to point the user to. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] Re: [PHP-DEV] win32 builtin zlib
[...] > The link above from w3c could be a good idea to point the user to. Sure, but not a very smart solution IMHO ;-). It think it should be possible (and preferable) to bundle the required whatever files with win32build.zip ;-) Friedhelm -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] Re: [PHP-DEV] win32 builtin zlib
On Sat, 25 Jan 2003 23:39:36 +0100 Friedhelm Betz <[EMAIL PROTECTED]> wrote: > > [...] > > The link above from w3c could be a good idea to point the user to. > > Sure, but not a very smart solution IMHO ;-). It think it should be > possible (and preferable) to bundle the required whatever files > with win32build.zip ;-) I completely agree. I didn't know about the win32build.zip untill Zeev mentioned it. --- Maxim Maletsky [EMAIL PROTECTED] -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/reference/image/functions imagecolorallocatealpha.xml
pollita Sat Jan 25 20:34:13 2003 EDT Added files: /phpdoc/en/reference/image/functionsimagecolorallocatealpha.xml Log: New function. Index: phpdoc/en/reference/image/functions/imagecolorallocatealpha.xml +++ phpdoc/en/reference/image/functions/imagecolorallocatealpha.xml imagecolorallocatealpha Allocate a color for an image Description intimagecolorallocatealpha resourceimage intred intgreen intblue intalpha imagecolorallocatealpha behaves identically to imagecolorallocate with the addition of the transparency parameter alpha which may have a value between 0 and 127. 0 indicates completely opaque while 127 indicates completely transparent. Returns &false; if the allocation failed. -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20570 [Csd]: description of MAX_FILE_SIZE should be clear
ID: 20570
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Documentation problem
Operating System: independency
PHP Version: 4.3.0RC1
New Comment:
sorry, there is step 3, php itself does check MAX_FILE_SIZE
if MAX_FILE_SIZE is for script not for php itself, it shouldn't mention
by document
look at these code:
safe_php_register_variable(param, value, array_ptr, 0 TSRMLS_CC);
if (!strcmp(param, "MAX_FILE_SIZE")) {
max_file_size = atol(value);
}
==
else if (max_file_size && (total_bytes > max_file_size)) {
sapi_module.sapi_error(E_WARNING, "MAX_FILE_SIZE of %ld bytes
exceeded - file [%s=%s] not saved", max_file_size, param, filename);
cancel_upload = UPLOAD_ERROR_B;
} else if
...
Previous Comments:
[2003-01-25 13:18:54] [EMAIL PROTECTED]
there is no step 3, php itself does not check MAX_FILE_SIZE
(unless your script does)
will add the "user won't have to wait to long" part
[2002-11-22 08:38:47] [EMAIL PROTECTED]
[quote from php manual
mian>>feature>>handling file uploads]
The MAX_FILE_SIZE hidden field must precede the file input field and
its value is the maximum filesize accepted. The value is in bytes.
[warnning]
warning: The MAX_FILE_SIZE is advisory to the browser. It is easy to
circumvent this maximum. So don't count on it that the browser obeys
you wish! The PHP-settings for maximum-size, however, cannot be fooled.
[/warnning]
[/quote]
it doesn't tell how php check the size
1 year ago I 1st time read it, and re-read it today, finally get what
it means
document should tell more to programmers:
--
1. user's file size is checked at the beginning of transfer before
upload is done
2. hard limit: file size is check against "PHP-settings for
maximum-size", file which larger will be refused
3. then, soft limit: check against "MAX_FILE_SIZE" if there is one
hidden value before input file field
4. when transfer done, php-script is active, manage to store the
uploaded-file, however, value of MAX_FILE_SIZE easy to circumvent, and
cannot be trust on, your php-script should re-check the uploaded file
size as u wish.
FAQ: u said MAX_FILE_SIZE is untrustable, why we should make use of it?
why not use only php-script to check filesize?
answer: in current php, handling of upload file, scirpt is not active,
thus, cannot check filesize until transfer of upload file is done.
MAX_FILE_SIZE get ability to soft limit the filesize before user have
to wait too long.
--
this is what i comprehend :)
yes, it's too long, hope u guys can refine it, and put into new version
of phpmanual
--
Edit this bug report at http://bugs.php.net/?id=20570&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20570 [Csd->Opn]: description of MAX_FILE_SIZE should be clear
ID: 20570
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: Documentation problem
Operating System: independency
-PHP Version: 4.3.0RC1
+PHP Version: 4.3.0
New Comment:
Still open, more information is needed in these docs regarding all of
this.
Previous Comments:
[2003-01-25 20:04:02] [EMAIL PROTECTED]
sorry, there is step 3, php itself does check MAX_FILE_SIZE
if MAX_FILE_SIZE is for script not for php itself, it shouldn't mention
by document
look at these code:
safe_php_register_variable(param, value, array_ptr, 0 TSRMLS_CC);
if (!strcmp(param, "MAX_FILE_SIZE")) {
max_file_size = atol(value);
}
==
else if (max_file_size && (total_bytes > max_file_size)) {
sapi_module.sapi_error(E_WARNING, "MAX_FILE_SIZE of %ld bytes
exceeded - file [%s=%s] not saved", max_file_size, param, filename);
cancel_upload = UPLOAD_ERROR_B;
} else if
...
[2003-01-25 13:18:54] [EMAIL PROTECTED]
there is no step 3, php itself does not check MAX_FILE_SIZE
(unless your script does)
will add the "user won't have to wait to long" part
[2002-11-22 08:38:47] [EMAIL PROTECTED]
[quote from php manual
mian>>feature>>handling file uploads]
The MAX_FILE_SIZE hidden field must precede the file input field and
its value is the maximum filesize accepted. The value is in bytes.
[warnning]
warning: The MAX_FILE_SIZE is advisory to the browser. It is easy to
circumvent this maximum. So don't count on it that the browser obeys
you wish! The PHP-settings for maximum-size, however, cannot be fooled.
[/warnning]
[/quote]
it doesn't tell how php check the size
1 year ago I 1st time read it, and re-read it today, finally get what
it means
document should tell more to programmers:
--
1. user's file size is checked at the beginning of transfer before
upload is done
2. hard limit: file size is check against "PHP-settings for
maximum-size", file which larger will be refused
3. then, soft limit: check against "MAX_FILE_SIZE" if there is one
hidden value before input file field
4. when transfer done, php-script is active, manage to store the
uploaded-file, however, value of MAX_FILE_SIZE easy to circumvent, and
cannot be trust on, your php-script should re-check the uploaded file
size as u wish.
FAQ: u said MAX_FILE_SIZE is untrustable, why we should make use of it?
why not use only php-script to check filesize?
answer: in current php, handling of upload file, scirpt is not active,
thus, cannot check filesize until transfer of upload file is done.
MAX_FILE_SIZE get ability to soft limit the filesize before user have
to wait too long.
--
this is what i comprehend :)
yes, it's too long, hope u guys can refine it, and put into new version
of phpmanual
--
Edit this bug report at http://bugs.php.net/?id=20570&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] Re: [PHP-DEV] win32 builtin zlib
At 00:25 26/01/2003, Friedhelm Betz wrote: Saturday, January 25, 2003, Zeev Suraski wrote: >>1.) Are there future plans to include the zlib sources? > No. zlib is included in a similar way to the way we include > bindlib_w32. It's in a different repository on cvs.php.net, that we expect > to be checked out and built by the time you build PHP. Ok, from users point the same... Maybe my question was a bit misleading, I meant provided within win32build.zip, maybe. >>2.) Should users be advised to modify config.win32.h.in > Nope (this particular file doesn't exist anymore, btw) Hm, you are right, at least not in the snapshots, but in the official release 4.3.0 from php.net... anyway. >>3.) Should users be advised to download zlib sources, building >> zlib.lib? > Not sure - I think that zlib should be in the win32build.zip archive. Nope;-) As zlib is builtin and the workspaces rely on, it would be really nice for users if they are done by downloading php4.xxx.tar.gz, win32build.zip and bindlib_w32.zip, the way like other standard builtin modules are fine with. I'm not really following. I have to admit I never built PHP from the pre-made library binaries, so it sounds awkward to me. Are we making people download the bindlib source and build it? If so, we should do the same with zlib (looking into it, I guess it means creating a zlib.zip file, like bindlib_w32.zip). zlib and bindlib sit in exactly the same level of integration with PHP. To me it sounds a bit weird that the ready-made builds of these libraries don't come bundled in win32build.zip, but I guess that's fine as long as it's documented. Zeev -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
