[PHP-DOC] cvs: livedocs / livedoc-index.php
momoMon Feb 2 15:33:28 2004 EDT
Modified files:
/livedocs livedoc-index.php
Log:
support dynamic mode.
http://cvs.php.net/diff.php/livedocs/livedoc-index.php?r1=1.6&r2=1.7&ty=u
Index: livedocs/livedoc-index.php
diff -u livedocs/livedoc-index.php:1.6 livedocs/livedoc-index.php:1.7
--- livedocs/livedoc-index.php:1.6 Fri Jan 23 09:58:38 2004
+++ livedocs/livedoc-index.php Mon Feb 2 15:33:28 2004
@@ -18,7 +18,7 @@
// | Livedocs index |
// +--+
//
-// $Id: livedoc-index.php,v 1.6 2004/01/23 14:58:38 didou Exp $
+// $Id: livedoc-index.php,v 1.7 2004/02/02 20:33:28 momo Exp $
echo index_page_header();
@@ -48,7 +48,8 @@
if ($q) {
while ($r = sqlite_fetch_array($q, SQLITE_NUM)) {
list($title, $id) = $r;
-echo "$title\n";
+$url = FORCE_DYNAMIC ? "?l=$lang&q=$id#$id" : "$lang/$id#$id";
+echo "$title\n";
}
}
}
Re: [PHP-DOC] PECL/PEAR in Docs
Well, we are (or I am?) focusing on the right place :) See http://php.net/imagecreatetruecolor for example. It is a manual page of function defined by php_gd2.dll on windows. It needs to be enabled in php.ini (or by dl()), but still you could find out from the manual page that the DLL that shipped with PHP 4.0.6 already contained this and all the DLLs in later versions too. I second Goba's point of view. It might be of interest to know the version of a PECL Extension, of course, but this could not answer the simple questiion: Is this function/extension available with PHP xxx, and am I able (in theory) to use this function/extension with PHP xxx. Therefore it is really important to know, if you can (in theory) use a particular function/extension with your installed PHP Version. My proposal: For _bundled_ (delivered with PHP xxx) PECL extension we should be able to give the version info as now provided in the manual, as we do with any other bundled extension. I am pretty sure, most users do not care about, if this extension/functions was bundled from PECL From users pov this is just an ordinary extension, not less not more. And the version of the extensions should be available with phpinfo, no? Of course the availability to use the extension depends wether it is compiled in and/or enabled. For _real_ (not delivered with PHP xxx) PECL extension: We could provide the general info, that this extension is available throug PECL. No extension version, please. At the function level we should be able to use the same schema as for the "regular" docs. For example: extension BAR, has functions foo_1, foo_2,, foo_n. extension/version info for foo_1 <= 2.4 extension/version info for foo_12 >= 4.9 If an extension from PECL would be delivered with PHP xxx, the extension info should change to the version info PHP xxx >=xxx Is that nonsense? Comments? You two are talking at the two extreams (or my flu is not fully cured yet, and I interpret it incorrectly :). For PECL extensions we should provide both the PHP release and PECL extension version numbers in the manual where applicable. PHP versoin PECL ext. version PHP bundled PECL ext YESYES PECL ext (not in php dist)NO YES The only NO in this table is just because we don't know... If there would be some automation we could know what PHP version that PECL ext will work with (ie. zendAPI version number, internal dependencies), then we could flip that NO to YES... So we should provide all the information available to us, which can be used by developers when version compatibility decisions / checks need to be made. It is this simple. Goba
Re: [PHP-DOC] PECL/PEAR in Docs
> - Hartmut's function list script collection should be extended > to handle PECL extensions and PECL version numbers, since this > script collection generates the version information you have > problems with. The most complicated part will probably be > the handling of bundled extensions, since corresponding PECL > / PHP version numbers need to be known... > >>> > >>>Is that really an issue? I can see the point in knowing the version > >>>which came with the a php release, but for a function itself, the only > >>>important information is the version of the extension. Since a > >>>PECL-Extension can be updated regardless if there used to be a bundled > >>>one, i don't see that as a really big problem. It's rather a nice to > >>>know thing imho. > >> > >>Think about *windows users*: if you set up PHP 5 on windows, it will not > > >>help you if you see on the Tidy documentation page that some functions > >>are useable in version 1.1. Hey, you have just installed PHP 5... You > >>would like to know if you can use it with the PHP you installed or > not... > > > > I can see your point but you still don't know if the "admin" did enable > > that extension or not, so you do have to check anyway. There's hardly > > any difference in checking if the extension actually IS enabled or to > > verify its version. > > > > I do see the point in your comment though and i'm not trying to say it's > > a bad idea.. just nothing we must focus on in the first place. > > Well, we are (or I am?) focusing on the right place :) See > http://php.net/imagecreatetruecolor for example. It is a manual page of > function defined by php_gd2.dll on windows. It needs to be enabled in > php.ini (or by dl()), but still you could find out from the manual page > that the DLL that shipped with PHP 4.0.6 already contained this and all > the DLLs in later versions too. > I second Goba's point of view. It might be of interest to know the version of a PECL Extension, of course, but this could not answer the simple questiion: Is this function/extension available with PHP xxx, and am I able (in theory) to use this function/extension with PHP xxx. Therefore it is really important to know, if you can (in theory) use a particular function/extension with your installed PHP Version. My proposal: For _bundled_ (delivered with PHP xxx) PECL extension we should be able to give the version info as now provided in the manual, as we do with any other bundled extension. I am pretty sure, most users do not care about, if this extension/functions was bundled from PECL From users pov this is just an ordinary extension, not less not more. And the version of the extensions should be available with phpinfo, no? Of course the availability to use the extension depends wether it is compiled in and/or enabled. For _real_ (not delivered with PHP xxx) PECL extension: We could provide the general info, that this extension is available throug PECL. No extension version, please. At the function level we should be able to use the same schema as for the "regular" docs. For example: extension BAR, has functions foo_1, foo_2,, foo_n. extension/version info for foo_1 <= 2.4 extension/version info for foo_12 >= 4.9 If an extension from PECL would be delivered with PHP xxx, the extension info should change to the version info PHP xxx >=xxx Is that nonsense? Comments? Regards Friedhelm -- GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...) jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++
Re: [PHP-DOC] PECL/PEAR in Docs
- Hartmut's function list script collection should be extended to handle PECL extensions and PECL version numbers, since this script collection generates the version information you have problems with. The most complicated part will probably be the handling of bundled extensions, since corresponding PECL / PHP version numbers need to be known... Is that really an issue? I can see the point in knowing the version which came with the a php release, but for a function itself, the only important information is the version of the extension. Since a PECL-Extension can be updated regardless if there used to be a bundled one, i don't see that as a really big problem. It's rather a nice to know thing imho. Think about *windows users*: if you set up PHP 5 on windows, it will not help you if you see on the Tidy documentation page that some functions are useable in version 1.1. Hey, you have just installed PHP 5... You would like to know if you can use it with the PHP you installed or not... I can see your point but you still don't know if the "admin" did enable that extension or not, so you do have to check anyway. There's hardly any difference in checking if the extension actually IS enabled or to verify its version. I do see the point in your comment though and i'm not trying to say it's a bad idea.. just nothing we must focus on in the first place. Well, we are (or I am?) focusing on the right place :) See http://php.net/imagecreatetruecolor for example. It is a manual page of function defined by php_gd2.dll on windows. It needs to be enabled in php.ini (or by dl()), but still you could find out from the manual page that the DLL that shipped with PHP 4.0.6 already contained this and all the DLLs in later versions too. Goba
[PHP-DOC] #27097 [Opn]: checkdate asks for long doc says int
ID: 27097 Updated by: [EMAIL PROTECTED] Reported By: trancer at trancer dot nl Status: Open Bug Type: Documentation problem Operating System: Windows XP PHP Version: 4.3.4 New Comment: What should we do then? Maybe its better to add a note to http://php.net/manual/en/language.types.php explaining that long is similar to an integer. Ideas? Previous Comments: [2004-01-30 11:14:57] [EMAIL PROTECTED] Derick: Then why does zend_zval_type_name return "integer"? [2004-01-30 11:13:31] [EMAIL PROTECTED] When i think more about it, it doesn't really make sense for checkdate to accept "1e1" (which is "numeric" but not an integer) but not "1d1", so it is either too strict or not strict enough. Any thoughts? [2004-01-30 11:13:05] [EMAIL PROTECTED] No, the error message is correct. We use a long, internal type is long, parse_parameters uses the "l" as type specifier... the docs needs fixing. [2004-01-30 11:03:51] [EMAIL PROTECTED] Note that "int" in php is a "signed long int"(32 bit), so int and long are equivalent. But i think you shouldn't have to know C to read error messages, so IMO the error message should change. I'll send a patch for that to the list. Additionally, checkdate() doesn't convert to int like other php functions do, but since it's a validating function, that strictness is desirable behaviour imo, but should be documented. I'll add a note to the manual. [2004-01-30 10:48:55] [EMAIL PROTECTED] should the proto be number ? 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/27097 -- Edit this bug report at http://bugs.php.net/?id=27097&edit=1
Re: [PHP-DOC] PECL/PEAR in Docs
On Mon, 2004-02-02 at 16:12, Gabor Hojtsy wrote: > >> - Hartmut's function list script collection should be extended > >>to handle PECL extensions and PECL version numbers, since this > >>script collection generates the version information you have > >>problems with. The most complicated part will probably be > >>the handling of bundled extensions, since corresponding PECL > >>/ PHP version numbers need to be known... > > > > Is that really an issue? I can see the point in knowing the version > > which came with the a php release, but for a function itself, the only > > important information is the version of the extension. Since a > > PECL-Extension can be updated regardless if there used to be a bundled > > one, i don't see that as a really big problem. It's rather a nice to > > know thing imho. > > Think about *windows users*: if you set up PHP 5 on windows, it will not > help you if you see on the Tidy documentation page that some functions > are useable in version 1.1. Hey, you have just installed PHP 5... You > would like to know if you can use it with the PHP you installed or not... I can see your point but you still don't know if the "admin" did enable that extension or not, so you do have to check anyway. There's hardly any difference in checking if the extension actually IS enabled or to verify its version. I do see the point in your comment though and i'm not trying to say it's a bad idea.. just nothing we must focus on in the first place. Regards, Arne -- Arne Blankerts <[EMAIL PROTECTED]>
[PHP-DOC] cvs: phpdoc /en/appendices migration4.xml migration5.xml
nlopess Mon Feb 2 10:53:23 2004 EDT Modified files: /phpdoc/en/appendices migration4.xml migration5.xml Log: fix examples role=apache some CS http://cvs.php.net/diff.php/phpdoc/en/appendices/migration4.xml?r1=1.35&r2=1.36&ty=u Index: phpdoc/en/appendices/migration4.xml diff -u phpdoc/en/appendices/migration4.xml:1.35 phpdoc/en/appendices/migration4.xml:1.36 --- phpdoc/en/appendices/migration4.xml:1.35Sun Dec 21 09:42:17 2003 +++ phpdoc/en/appendices/migration4.xml Mon Feb 2 10:53:23 2004 @@ -1,5 +1,5 @@ - + Migrating from PHP 3 to PHP 4 @@ -63,20 +63,20 @@ changes. The MIME types recognized by the PHP module have changed. - + - - + + You can make your configuration files work with both versions of PHP (depending on which one is currently compiled into the server), using the following syntax: - + - + In addition, the PHP directive names for Apache have changed. @@ -94,15 +94,15 @@ Starting with PHP 4.0, there are only four Apache directives that relate to PHP: - + - - + + There are two differences between the Admin values and the non admin values: http://cvs.php.net/diff.php/phpdoc/en/appendices/migration5.xml?r1=1.3&r2=1.4&ty=u Index: phpdoc/en/appendices/migration5.xml diff -u phpdoc/en/appendices/migration5.xml:1.3 phpdoc/en/appendices/migration5.xml:1.4 --- phpdoc/en/appendices/migration5.xml:1.3 Mon Feb 2 10:27:30 2004 +++ phpdoc/en/appendices/migration5.xml Mon Feb 2 10:53:23 2004 @@ -1,5 +1,5 @@ - + Migrating from PHP 4 to PHP 5 @@ -82,7 +82,7 @@ Migrate the Apache configuration is extremely easy. See the example below to check the change you need to do: - +
[PHP-DOC] cvs: phpdoc /en/appendices migration5.xml
nlopess Mon Feb 2 10:27:30 2004 EDT Modified files: /phpdoc/en/appendices migration5.xml Log: added new section: migrate configuration files http://cvs.php.net/diff.php/phpdoc/en/appendices/migration5.xml?r1=1.2&r2=1.3&ty=u Index: phpdoc/en/appendices/migration5.xml diff -u phpdoc/en/appendices/migration5.xml:1.2 phpdoc/en/appendices/migration5.xml:1.3 --- phpdoc/en/appendices/migration5.xml:1.2 Fri Jan 30 18:14:46 2004 +++ phpdoc/en/appendices/migration5.xml Mon Feb 2 10:27:30 2004 @@ -1,5 +1,5 @@ - + Migrating from PHP 4 to PHP 5 @@ -70,6 +70,51 @@ + + Migrating Configuration Files + +Since the ISAPI modules changed their names, from php4xxx to php5xxx, you +need to make some changes in the configuration files. There were also +changes in the CLI and CGI filenames. Please refer to the corresponding +section for more information. + + +Migrate the Apache configuration is extremely easy. See the example below +to check the change you need to do: + + + + + + + +If your webserver is running PHP in CGI mode, you should note that the +CGI version has changed its name from php.exe to php-cgi.exe. +In Apache you should do something like this: + + + + + + + +In other webservers you need to change either the CGI or the ISAPI module +filenames. + + +
Re: [PHP-DOC] PECL/PEAR in Docs
We should change that to be of something more meaning full, maybe even with a link to the matching PECL/PEAR entry rather then leaving the user in doubt if he/she can actually make use of the function in his/her environment. Steps we need to take to better handle PECL extensions: - Move PECL extension docs from peardoc to PHPdoc (split as needed) This might be a bit of a problem as some extensions where moved to PECL but previously where part of the core. This might be a bit of a confusion for the user... Telling a user he has to install this extension from PECL even though for his version of PHP its still shiped within the default distribution might be even more confusing... The docteam will be able to care about documenting exceptions if an extension was part of the distribution before... - Hartmut's function list script collection should be extended to handle PECL extensions and PECL version numbers, since this script collection generates the version information you have problems with. The most complicated part will probably be the handling of bundled extensions, since corresponding PECL / PHP version numbers need to be known... Is that really an issue? I can see the point in knowing the version which came with the a php release, but for a function itself, the only important information is the version of the extension. Since a PECL-Extension can be updated regardless if there used to be a bundled one, i don't see that as a really big problem. It's rather a nice to know thing imho. Think about *windows users*: if you set up PHP 5 on windows, it will not help you if you see on the Tidy documentation page that some functions are useable in version 1.1. Hey, you have just installed PHP 5... You would like to know if you can use it with the PHP you installed or not... Goba
Re: [PHP-DOC] PECL/PEAR in Docs
On Mon, 2004-02-02 at 14:46, Gabor Hojtsy wrote: > > We should change that to be of something more meaning full, maybe even > > with a link to the matching PECL/PEAR entry rather then leaving the user > > in doubt if he/she can actually make use of the function in his/her > > environment. > Steps we need to take to better handle PECL extensions: > > - Move PECL extension docs from peardoc to PHPdoc (split as needed) This might be a bit of a problem as some extensions where moved to PECL but previously where part of the core. This might be a bit of a confusion for the user... Telling a user he has to install this extension from PECL even though for his version of PHP its still shiped within the default distribution might be even more confusing... > - Hartmut's function list script collection should be extended > to handle PECL extensions and PECL version numbers, since this > script collection generates the version information you have > problems with. The most complicated part will probably be > the handling of bundled extensions, since corresponding PECL > / PHP version numbers need to be known... Is that really an issue? I can see the point in knowing the version which came with the a php release, but for a function itself, the only important information is the version of the extension. Since a PECL-Extension can be updated regardless if there used to be a bundled one, i don't see that as a really big problem. It's rather a nice to know thing imho. Regards, Arne -- Arne Blankerts <[EMAIL PROTECTED]>
Re: [PHP-DOC] PECL/PEAR in Docs
Hi! (Also CC-ig King Of PECL :) while hunting down some information about some PECL/PEAR related things, i found it very disturbing to have "no version, might be cvs only" as the Version-Information for the functions created by those extensions. We should change that to be of something more meaning full, maybe even with a link to the matching PECL/PEAR entry rather then leaving the user in doubt if he/she can actually make use of the function in his/her environment. Any comments/ideas how that could/should be done? Steps we need to take to better handle PECL extensions: - Move PECL extension docs from peardoc to PHPdoc (split as needed) Analisys: I have checked those files, and some of them are there with a lot of CVS history which might not be a good idea to loose. So all 'en' files should be moved in the filesystem with history to phpdoc/en/functions (yes, the old dir, since these are files per extensions). Then Hartmut's split script should be executed on them (hope it will still work :). Then the translated files could be moved by hand, since even phpdoc's own old one-file-per-extension files are not kept for translations... That is means a small amount of work for systems@ :) :)) : - Hartmut's function list script collection should be extended to handle PECL extensions and PECL version numbers, since this script collection generates the version information you have problems with. The most complicated part will probably be the handling of bundled extensions, since corresponding PECL / PHP version numbers need to be known... Any objections with starting the first step (khm, with asking at systems@)? Goba
Re: [PHP-DOC] Re: Setting up a website for the phpdoc team
David: we'd be interested in what you have to offer - please contact me directly and we will figure something out. :) thanks, - james
Re: [PHP-DOC] Re: Setting up a website for the phpdoc team
On 1 Feb 2004, at 12:09, Mehdi Achour wrote: Derick Rethans wrote: On Sat, 31 Jan 2004, Mehdi Achour wrote: a big big big +1 here :) It will be great to allow some ssh access for some active persons of the doc team. Having the doc.php.net on another (isolated) machine will also make happy systems@ IMHO :) Why do you need ssh access? Because you always say that you're too busy ? :) It's also handy for webmastering to have the ability of quickly updating the site. For the last problem with bugs.php.net, all I was able to do was sitting there at three a.m. in the morning fighting my sleep to see if the errors were fixed. If only I was able to do something like : ssh bugs.php.net cd /var/www/ cvs up -PAd Which would break everything because all the systems are running a very precise set of scripts and structures that someone not familiar with would essentially break. I understand that systems staff can be a little unresponsive - we do, after all, have day jobs. If some other members of the project wished to become responsible for infrastructure, i'm sure we'd consider additions to the group.
Re: [PHP-DOC] Re: Setting up a website for the phpdoc team
On 31 Jan 2004, at 22:20, David Costa wrote: On Jan 31, 2004, at 11:15 PM, Mehdi Achour wrote: Gabor Hojtsy wrote: - revcheck output hosting - build logs, error reports Those will end up on the doc build machine, which is now sc1.php.net (and yes, they still need to be enabled) So then it will be ideal to set up this docteam website on the same machine, since a lot of the needed checkouts are already present there... I'm not too happy with that, as this box has no visible websites, it doesn't even run apache or mysql. It's solely meant for rsync, snapsbuilding and docbuilding. Ah, all right... Understandable. Then the question is still up to systems@ whether there is some willingness to set up a machine/vhost, or we will better do with opening a vhost on some new donated machine offered by a docteam member? I am available for a full machine donation e.g. a server at www.servercove.com ( nice guys as you can chose which distribution and pretty fast on tickets) or ev1servers.net is something I could sponsor (monthly fee). Any provider will do for me, as long as it is within the same budget ;) The docs leader could have the ssh access of everything they want as my role would be of mere sponsor (and no, I don't need any particular mention/link on the site..so it's a pure donation). Let me know if there is any interest. I am ready Regards David Costa The added benefit of the latter option would be that we will not be reliant on the systems@ group for configuration changes, but the site could still be registered as doc.php.net, and we can be more flexible with its development and setup... The more I think about it, the more I like this option :) -- James Cox (Editor) :: [EMAIL PROTECTED] :: http://www.apress.com/ Apress. The Experts Voice (tm)
[PHP-DOC] PECL/PEAR in Docs
Heya, while hunting down some information about some PECL/PEAR related things, i found it very disturbing to have "no version, might be cvs only" as the Version-Information for the functions created by those extensions. We should change that to be of something more meaning full, maybe even with a link to the matching PECL/PEAR entry rather then leaving the user in doubt if he/she can actually make use of the function in his/her environment. Any comments/ideas how that could/should be done? Regards, Arne Blankerts -- Arne Blankerts <[EMAIL PROTECTED]>
Re: [PHP-DOC] Smarty-2.6.1
This is not a support forum. Please look at http://smarty.php.net for
smarty support...
Goba
[EMAIL PROTECTED] wrote:
Hello,
I have downloaded Smarty-2.6.1.
Very good templates. But using it I have found one bug (I think
that's bug) with {html_table tr_attr=...}
For example this code does not change the colors of row in table.
index.php:
--
require('Smarty.class.php');
$smarty = new Smarty;
$smarty->assign('data',array(1,2,3,4,5,6,7,8,9));
$smarty->assign('tr',array('bgcolor="#ee"','bgcolor="#dd"'));
$smarty->display('index.tpl');
index.tpl:
--
{html_table loop=$data cols=4 tr_attr=$tr}
But in Smarty-2.5.0 that was working. When I changed new file with old
(from v.2.5.0) it began working.
[PHP-DOC] Re: php-master-web patch
Would any great person of karma like to commit a small patch that will allow lazy^H^H^H^Hhard working phpdoc helpers to more easily stop bad notes before they hit the mirrors? Below, I've attached a patch against php-master-web/manage/user-notes.php. Comitted. Goba
Re: [PHP-DOC] Smarty-2.6.1
> I have downloaded Smarty-2.6.1.
> Very good templates. But using it I have found one bug (I think
> that's bug) with {html_table tr_attr=...}
This is PHP documentation list, please see
http://smarty-web.ispi.net/resources.php?category=7 for appropriate
list to ask your question.
Jakub Vrana
Re: [PHP-DOC] Re: Setting up a website for the phpdoc team
I agree...many bugs are initially entered as php-bugs, but a big part of them are most likely "mal-comprehension" issues or bad documented behaviour, so this transition should be easy at any time. "Gabor Hojtsy" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > >> - have an independent bug system ? > > BTW I would not support an independent bug system yet... Maybe on the > long term... There are valid reasons for this, but we are not ready yet > for such a system IMHO. The other points mentioned by Mehdi are fine :)) > > Goba
[PHP-DOC] Re: Setting up a website for the phpdoc team
Great idea! As it was mentioned above, it will help very much to newbies and to translation teams. However, every translation is a completely "new" documentation, so the TODO list would be very useful. Like that each new "docer" will know where the team is and he can start almost immediately to work. +1 Kouber Saparev
