Re: [PHP-DEV] [RFC] Starting 5.3
.php) or as a self contained installer. But I would not recommend to ever use a phar for other purposes like in a production environment. That's the question - if phar is not to be recommended in production as deployment format, it belongs to PECL. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hi, On 5/7/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > A little note about executing a phar file, no phar extension is > required to execute a phar archive, neither to create it (see Right, but php and PEAR are required to read/create/inspect the archive. Who has inspected pear.phar? Not a lot I think, but we all installed pear using at least once (without ext/phar). Not pear directly but PHP_Archive or the pecl/phar. However phar is good to test something in a non intrusive way (no file to install, you can do "php foo.phar" or run it in a webserver if you rename it to .php) or as a self contained installer. But I would not recommend to ever use a phar for other purposes like in a production environment. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
A little note about executing a phar file, no phar extension is required to execute a phar archive, neither to create it (see Right, but php and PEAR are required to read/create/inspect the archive. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug? Raw POST data in PHP 5.2.2, take two
Sorry, I apologize. Although you were curt I should not have been so in reply. I used to manage development of a reasonably popular open source project, and if one of our developers had ever said something like that, it would have greatly annoyed me. You never really lose that. Although I still think you were somewhat rude, I should not have called you on it as such, which was rude of me. I am sorry. -[Unknown] Original Message Wow. That's a curt reply. At the risk of being curt too... at least I learned my lessons in manners? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hi, On 5/7/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > pear install phar - or - pecl install phar - done > oh wait the point is that pecl install doesn't work or is in 99% no option And what is "pear install"? I don't have such command in my Windows by default. Neither I have it on my Linux. I would have to install PEAR for that, right? Even only to know what's inside. A little note about executing a phar file, no phar extension is required to execute a phar archive, neither to create it (see http://pear.php.net/package/PHP_Archive) . We distribute pear.phar since a couple of stable releases already. It is easier/faster to create it using pecl/phar. I'm sure there is a big difference (performence) when a phar is executed with or without pecl/phar, it is slow anyway. I see this extension as a packager tool only (where end users are packages user). NB: Recent changes in the extensions may be available only in the extension, I did not follow its recent developments. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Starting 5.3
I see no value in making compatibility breaks in 5.x and not in the next major version. As it is we drive a lot of our users crazy. We already agreed this is a 6.x thing. > -Original Message- > From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] > Sent: Sunday, May 06, 2007 11:12 AM > To: Marcus Boerger > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Starting 5.3 > > IMHO one good reason to start a new branch for 5.x would be > the ability to get rid off register_globals and magic_quotes > in the 5 series without having to wait for PHP6 to come around. > > Ilia > > -- > PHP Internals - PHP Runtime Development Mailing List To > unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Btw, I think if phar is a good way of deploying self-contained apps like WAR and EAR then we should think of including this in the default distro. It definitely has value. I just don't think we're quite there yet. WAR/EAR isn't really self-contained - they are managed by the app server. So far we don't have similar system in PHP. And as I pointed out all Java *ARs are essentially zip's with some additional files inside and specific file structure. I like it better than inventing another file format. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
they most likely don't, it is designed for deployment and for running includes directly. What do you mean "directly"? Do you mean this is designed for running application only specifically crafted to run inside phar and would break some or most of the existing applications not designed specifically for it? Then even less reason to recommend it as a way to deploy real applications. If need be, i'll write a windows-commander plugin :-) Will you also write plugins for all thousand other tools people use or only for those two you personally use? ;) Note that for all other formats the tools are out there *today*. You can open zip or tgz on almost any system in existence, and almost any file manager you could find understands these formats or natively or with tons of readily available plugins. pear install phar - or - pecl install phar - done oh wait the point is that pecl install doesn't work or is in 99% no option And what is "pear install"? I don't have such command in my Windows by default. Neither I have it on my Linux. I would have to install PEAR for that, right? Even only to know what's inside. slow? bigger? overhead? Meaning, of no practical use nobody would package their real-world apps this way. Then I guess it's not really an option? Interesting and not maintained for the most. Sometimes working on one or the other very specific php version only. And often even without documentation. This is as I see for very specific applications too, and the manual says there's no currently stable version of phar. My opinion is that it is not right to recommend it as preferred way to deploy PHP applications. I know there are many people that it suits their needs - but those people as I understand have to keep in mind they work for phar anyway, so they might as well install one more extension. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] phar & apc
Before reading the thread on the idea of a PHP 5.3 branch, I had never heard of phar, so please excuse my neophyte questions, but I couldn't find a reference with the information. On a single website application environment (as opposed to a shared host type of thing), what are the performance characteristics of using a phar file to replace a largish collection of php files? Does the performance improve or not? does a fast-cgi based installation make a difference? Are stat calls for included files short-circuited since it is all really one file? Does this improve things in windows where file calls seem so damn slow? Linux? Most important, how does it work with APC? thank you for any answers or references to points of study on the web. -s -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: dw31415
I am working with the lead developers of PEAR/Structures_DataGrid on a new package. Mark Wiesemann <[EMAIL PROTECTED]> says: "please mention that you need karma for peardoc/ and pear/Structures_DataGrid_DataSource_SQLQuery/ . -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug? Raw POST data in PHP 5.2.2, take two
Wow. That's a curt reply. At the risk of being curt too... at least I learned my lessons in manners? Anyway, I did take a glance at the documentation but couldn't find anything mentioning whether it really was a global. Sorry for my mistaken assumption. Seems like it should be properly documented next to $php_errormsg here: http://www.php.net/manual/en/reserved.variables.php -[Unknown] Original Message Hello "Unknown", you are wrong, the name is right please learn your lessons before writing to internals. To the original problem: Ilia committed a fix a few hours ago which should fix the problem. Feel free to test a current snapshot. johannes On Sun, 2007-05-06 at 11:34 -0700, Unknown W. Brackets wrote: It sounds like you have register_globals off, which is a good thing imho. You are trying $HTTP_RAW_POST_DATA but my recollection tells me it is $_SERVER['HTTP_RAW_POST_DATA']. Does the latter work? Anyway, reading from php://input is more correct and doesn't depend on PHP settings as much, as far as I know. -[Unknown] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Ilia Alshanetsky wrote: IMHO one good reason to start a new branch for 5.x would be the ability to get rid off register_globals and magic_quotes in the 5 series without having to wait for PHP6 to come around. What would be the goal of that? Making it less painful to migrate to PHP 6.x since they already face similar pain when staying in the active 5.x branch? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 05/06/2007 10:11 PM, Ilia Alshanetsky wrote: IMHO one good reason to start a new branch for 5.x would be the ability to get rid off register_globals and magic_quotes in the 5 series without having to wait for PHP6 to come around. That's exactly the reason I'm against creating 5_3 branch at this moment - I'm afraid that you (and everybody else) will start patching it and 5_2 will become 4_4 as it is now - security fixes only.. once in a month.. maybe.. or maybe not. You would be busy with 5_3, even though there is enough work in 5_2 branch. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Starting 5.3
It could well be the last chance to get the mail() logger into 5.x as well, and IMHO a lot of people are waiting for this that can't/won't migrate to PHP6 quickly. Best, Mike Robinson Ilia Alshanetsky writes: > IMHO one good reason to start a new branch for 5.x would be > the ability to get rid off register_globals and magic_quotes > in the 5 series without having to wait for PHP6 to come around. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug? Raw POST data in PHP 5.2.2, take two
Hello "Unknown",
you are wrong, the name is right please learn your lessons before
writing to internals.
To the original problem: Ilia committed a fix a few hours ago which
should fix the problem. Feel free to test a current snapshot.
johannes
On Sun, 2007-05-06 at 11:34 -0700, Unknown W. Brackets wrote:
> It sounds like you have register_globals off, which is a good thing imho.
>
> You are trying $HTTP_RAW_POST_DATA but my recollection tells me it is
> $_SERVER['HTTP_RAW_POST_DATA']. Does the latter work?
>
> Anyway, reading from php://input is more correct and doesn't depend on
> PHP settings as much, as far as I know.
>
> -[Unknown]
>
>
> Original Message
>
> > I believe this is a bug in PHP 5.2.2. I've tried to report this for PHP
> > 5.2.2RC2 but apparently wasn't making myself clear or wasn't following
> > the proper procedures ...
> >
> > Anyway, as I wrote before[1], "raw" POST data isn't making it through in
> > PHP 5.2.2 which results in XML-RPC communications to fail, at least when
> > using the PEAR::XML_RPC package.
> >
> > Consider this little script (send.php):
> >
> > --- snip ---
> > >
> > require_once 'XML/RPC.php';
> >
> > $sourceURI = 'http://www.example.com/'; // doesn't matter here
> > $targetURI = $sourceURI;
> >
> > $client = new XML_RPC_Client('/receive.php', $_SERVER['HTTP_HOST']);
> > $client->setDebug(1);
> > $msg = new XML_RPC_Message('pingback.ping',
> > array(new XML_RPC_Value($sourceURI, 'string'),
> > new XML_RPC_Value($targetURI, 'string')));
> >
> > $response = $client->send($msg, 0, 'http');
> >
> > ?>
> > --- snip ---
> >
> > This makes a simple XML-RPC call as used for Pingbacks. For the
> > receiving end of the communication, let's use this as receive.php:
> >
> > --- snip ---
> > >
> > print_r(getallheaders());
> >
> > echo $GLOBALS['HTTP_RAW_POST_DATA'] . "\n\n";
> >
> > ?>
> > --- snip ---
> >
> > Now when I call up send.php (both located in the web root of a server
> > running PHP 5.2.2), I get this output:
> >
> > ---GOT---
> > HTTP/1.1 200 OK
> > Date: Fri, 04 May 2007 20:07:58 GMT
> > Server: Apache/1.3.37 (Unix) PHP/5.2.2
> > X-Powered-By: PHP/5.2.2
> > Connection: close
> > Content-Type: text/html
> >
> > Array
> > (
> > [Content-Length] => 282
> > [Content-Type] => text/xml
> > [Host] => myhost.example.com
> > [User-Agent] => PEAR XML_RPC
> > )
> >
> > Notice: Undefined index: HTTP_RAW_POST_DATA in /usr/local/
> > apache/vhost/geeklog/public_html/receive.php on line 5
> >
> > ---END---
> >
> > So $GLOBALS['HTTP_RAW_POST_DATA'] is not set. The PEAR::XML_RPC package
> > actually uses $HTTP_RAW_POST_DATA on the receiving end, but that doesn't
> > appear to be set either. And the always_populate_raw_post_data option in
> > php.ini doesn't make a difference.
> >
> > Switching back to PHP 5.2.1 (same machine, same configuration) makes
> > everything work as expected:
> >
> > ---GOT---
> > HTTP/1.1 200 OK
> > Date: Fri, 04 May 2007 20:11:28 GMT
> > Server: Apache/1.3.37 (Unix) PHP/5.2.1
> > X-Powered-By: PHP/5.2.1
> > Connection: close
> > Content-Type: text/html
> >
> > Array
> > (
> > [Content-Length] => 282
> > [Content-Type] => text/xml
> > [Host] => myhost.example.com
> > [User-Agent] => PEAR XML_RPC
> > )
> >
> >
> > pingback.ping
> >
> >
> > http://www.example.com/
> >
> >
> > http://www.example.com/
> >
> >
> >
> >
> > ---END---
> >
> > This is on a Linux box, but I have confirmation (thanks, Mike) of the
> > same thing happening on Windows.
> >
> > Can anyone please
> >
> > 1) confirm this or tell me what I'm doing wrong and
> > 2) tell me what else I should have done (other than posting here and
> > emailing Ilia, as the PHP 5 release manager), in case I ever run into
> > something similar again.
> >
> > Thanks.
> >
> > bye, Dirk
> >
> > [1]
> >
> >
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug? Raw POST data in PHP 5.2.2, take two
It sounds like you have register_globals off, which is a good thing imho.
You are trying $HTTP_RAW_POST_DATA but my recollection tells me it is
$_SERVER['HTTP_RAW_POST_DATA']. Does the latter work?
Anyway, reading from php://input is more correct and doesn't depend on
PHP settings as much, as far as I know.
-[Unknown]
Original Message
I believe this is a bug in PHP 5.2.2. I've tried to report this for PHP
5.2.2RC2 but apparently wasn't making myself clear or wasn't following
the proper procedures ...
Anyway, as I wrote before[1], "raw" POST data isn't making it through in
PHP 5.2.2 which results in XML-RPC communications to fail, at least when
using the PEAR::XML_RPC package.
Consider this little script (send.php):
--- snip ---
http://www.example.com/'; // doesn't matter here
$targetURI = $sourceURI;
$client = new XML_RPC_Client('/receive.php', $_SERVER['HTTP_HOST']);
$client->setDebug(1);
$msg = new XML_RPC_Message('pingback.ping',
array(new XML_RPC_Value($sourceURI, 'string'),
new XML_RPC_Value($targetURI, 'string')));
$response = $client->send($msg, 0, 'http');
?>
--- snip ---
This makes a simple XML-RPC call as used for Pingbacks. For the
receiving end of the communication, let's use this as receive.php:
--- snip ---
--- snip ---
Now when I call up send.php (both located in the web root of a server
running PHP 5.2.2), I get this output:
---GOT---
HTTP/1.1 200 OK
Date: Fri, 04 May 2007 20:07:58 GMT
Server: Apache/1.3.37 (Unix) PHP/5.2.2
X-Powered-By: PHP/5.2.2
Connection: close
Content-Type: text/html
Array
(
[Content-Length] => 282
[Content-Type] => text/xml
[Host] => myhost.example.com
[User-Agent] => PEAR XML_RPC
)
Notice: Undefined index: HTTP_RAW_POST_DATA in /usr/local/
apache/vhost/geeklog/public_html/receive.php on line 5
---END---
So $GLOBALS['HTTP_RAW_POST_DATA'] is not set. The PEAR::XML_RPC package
actually uses $HTTP_RAW_POST_DATA on the receiving end, but that doesn't
appear to be set either. And the always_populate_raw_post_data option in
php.ini doesn't make a difference.
Switching back to PHP 5.2.1 (same machine, same configuration) makes
everything work as expected:
---GOT---
HTTP/1.1 200 OK
Date: Fri, 04 May 2007 20:11:28 GMT
Server: Apache/1.3.37 (Unix) PHP/5.2.1
X-Powered-By: PHP/5.2.1
Connection: close
Content-Type: text/html
Array
(
[Content-Length] => 282
[Content-Type] => text/xml
[Host] => myhost.example.com
[User-Agent] => PEAR XML_RPC
)
pingback.ping
http://www.example.com/
http://www.example.com/
---END---
This is on a Linux box, but I have confirmation (thanks, Mike) of the
same thing happening on Windows.
Can anyone please
1) confirm this or tell me what I'm doing wrong and
2) tell me what else I should have done (other than posting here and
emailing Ilia, as the PHP 5 release manager), in case I ever run into
something similar again.
Thanks.
bye, Dirk
[1]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
IMHO one good reason to start a new branch for 5.x would be the ability to get rid off register_globals and magic_quotes in the 5 series without having to wait for PHP6 to come around. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
David Coallier wrote: Yes we have discussed that on IRC with edin and the whole idea was USING tabs. So here I'll state exactly the idea as it seems to misunderstood: The idea is clearly and simply to use tabs for the different branches. Using javascript was just simple and fast in this case and yes we should handle the tabs statically. The only reason why we are *making it work* in javascript is not because I want it to be in javascript, but more because I wanted to have tabs working quickly and easy which is why I did in javascript without the need of PHP. I hereby say that yes, we will be using tabs as it is much easier to code and it will work on more browsers (I am thinking of links/lynx) for instance. Using tabs is also a good idea, especially because you avoid space problems by that. My second draw would look like this: http://hp-film.pytalhost.de/test/php/snaps_draw2.png Because I am currently short of time I didn't include the new features for the 5.2.x branch this time but I hope you see how I mean it... I think it would be better to write the date for the next snapshot next to the snapshot itself (like I have done it in my draw) and not to write it in a list on the left of the page. I have some difficulties with finding out to which snapshots on the right the dates on the left belong. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
On 5/6/07, Tijnema ! <[EMAIL PROTECTED]> wrote: On 5/6/07, M.Sokolewicz <[EMAIL PROTECTED]> wrote: > Tijnema ! wrote: > > On 5/6/07, David Coallier <[EMAIL PROTECTED]> wrote: > >> On 5/6/07, Tijnema ! <[EMAIL PROTECTED]> wrote: > >> > On 5/6/07, David Coallier <[EMAIL PROTECTED]> wrote: > >> > > On 5/5/07, Jan Reininghaus <[EMAIL PROTECTED]> wrote: > >> > > > I am currently working on my second draw for the page, but I have a > >> > > > question. For my first draw I assumed that all of the new > >> features will > >> > > > be available for all three branches, but is this actually true? > >> > > > > >> > > > By the way, I don't know whether you are aware that all build > >> processes > >> > > > of the win32 snapshots have failed for one day now. > >> > > > > >> > > > -- > >> > > > PHP Internals - PHP Runtime Development Mailing List > >> > > > To unsubscribe, visit: http://www.php.net/unsub.php > >> > > > > >> > > > > >> > > > >> > > Perhaps something like this could be cool: > >> > > http://dev.agoraproduction.com/php/snaps/ > >> > > > >> > > The css might be a bit off as I just wanted to do it quick, but you > >> > > see the idea :) > >> > > > >> > > > >> > > David > >> > > >> > Yes, it is quick, as it doesn't work good in IE6, which is the most > >> > common browser (http://www.w3schools.com/browsers/browsers_stats.asp) > >> > Might be a good alternative for the snaps site, as it is never too > >> > larg :) But it should work on IE6 too of course. > >> > > >> > Tijnema > >> > > >> Oops, well works in IE6.. just looks like hell.. I'd be interested in > >> seeing the % of the browsers on that specific site, it's not like any > >> common website thus can't rely on w3schools imho. > > > > Not that it matters how many users are using IE6, PHP should be > > atleast IE6, IE7, FF, Mozilla, Safari and Netscape compatible. (maybe > > more?) > >> > >> Anyways, you are right, looks like hell in IE6, try it in firefox or > >> opera .. the goal is to get an idea... not having a stable state with > >> everything working right away, etc... > > > > Ok, but are you sure it will be possible in IE6? Didn't take a look at > > your code yet, and i guess it will work, but we need to be sure of > > course. > >> > >> So look with a decent browser (wink) and tell me f you like the idea > >> of the tabs, that's the main point I am looking to get feedbacks on. > >> > >> > >> David > > > > Yeah, i tested it with Firefox, and it's a good idea. I don't like the > > style of the button, i think it doesn't really fit into the website, > > so maybe if you could change the buttons to a little bit more PHP-like > > it is cool for me, but well, it's not my site :P > > > > Tijnema > > Instead of using all tat javascript and trying to "make it work" in all > possible browsers, why don't you simply make multiple pages, with static > links from page to page (ie. page1.html for the first button, page2.html > for the 2nd, etc.). I wouldn't call the pages page1.html etc. These pages are all generated by a PHP script, so it's better to use like this: page.php?version=4, page.php?version=5, page.php?version=6 Yes we have discussed that on IRC with edin and the whole idea was USING tabs. So here I'll state exactly the idea as it seems to misunderstood: The idea is clearly and simply to use tabs for the different branches. Using javascript was just simple and fast in this case and yes we should handle the tabs statically. The only reason why we are *making it work* in javascript is not because I want it to be in javascript, but more because I wanted to have tabs working quickly and easy which is why I did in javascript without the need of PHP. I hereby say that yes, we will be using tabs as it is much easier to code and it will work on more browsers (I am thinking of links/lynx) for instance. $0.02 > And as for button appearances, just make it look > like the tabs in the PHP bug tracker and it'll all be fine IMO. Yes, good point :) These buttons would fit nice into the snaps site. But that's only how the PHP version are organized, how would you organize the files on a page? Tijnema -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
On 5/6/07, M.Sokolewicz <[EMAIL PROTECTED]> wrote: Tijnema ! wrote: > On 5/6/07, David Coallier <[EMAIL PROTECTED]> wrote: >> On 5/6/07, Tijnema ! <[EMAIL PROTECTED]> wrote: >> > On 5/6/07, David Coallier <[EMAIL PROTECTED]> wrote: >> > > On 5/5/07, Jan Reininghaus <[EMAIL PROTECTED]> wrote: >> > > > I am currently working on my second draw for the page, but I have a >> > > > question. For my first draw I assumed that all of the new >> features will >> > > > be available for all three branches, but is this actually true? >> > > > >> > > > By the way, I don't know whether you are aware that all build >> processes >> > > > of the win32 snapshots have failed for one day now. >> > > > >> > > > -- >> > > > PHP Internals - PHP Runtime Development Mailing List >> > > > To unsubscribe, visit: http://www.php.net/unsub.php >> > > > >> > > > >> > > >> > > Perhaps something like this could be cool: >> > > http://dev.agoraproduction.com/php/snaps/ >> > > >> > > The css might be a bit off as I just wanted to do it quick, but you >> > > see the idea :) >> > > >> > > >> > > David >> > >> > Yes, it is quick, as it doesn't work good in IE6, which is the most >> > common browser (http://www.w3schools.com/browsers/browsers_stats.asp) >> > Might be a good alternative for the snaps site, as it is never too >> > larg :) But it should work on IE6 too of course. >> > >> > Tijnema >> > >> Oops, well works in IE6.. just looks like hell.. I'd be interested in >> seeing the % of the browsers on that specific site, it's not like any >> common website thus can't rely on w3schools imho. > > Not that it matters how many users are using IE6, PHP should be > atleast IE6, IE7, FF, Mozilla, Safari and Netscape compatible. (maybe > more?) >> >> Anyways, you are right, looks like hell in IE6, try it in firefox or >> opera .. the goal is to get an idea... not having a stable state with >> everything working right away, etc... > > Ok, but are you sure it will be possible in IE6? Didn't take a look at > your code yet, and i guess it will work, but we need to be sure of > course. >> >> So look with a decent browser (wink) and tell me f you like the idea >> of the tabs, that's the main point I am looking to get feedbacks on. >> >> >> David > > Yeah, i tested it with Firefox, and it's a good idea. I don't like the > style of the button, i think it doesn't really fit into the website, > so maybe if you could change the buttons to a little bit more PHP-like > it is cool for me, but well, it's not my site :P > > Tijnema Instead of using all tat javascript and trying to "make it work" in all possible browsers, why don't you simply make multiple pages, with static links from page to page (ie. page1.html for the first button, page2.html for the 2nd, etc.). I wouldn't call the pages page1.html etc. These pages are all generated by a PHP script, so it's better to use like this: page.php?version=4, page.php?version=5, page.php?version=6 And as for button appearances, just make it look like the tabs in the PHP bug tracker and it'll all be fine IMO. Yes, good point :) These buttons would fit nice into the snaps site. But that's only how the PHP version are organized, how would you organize the files on a page? Tijnema -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
Tijnema ! wrote: On 5/6/07, David Coallier <[EMAIL PROTECTED]> wrote: On 5/6/07, Tijnema ! <[EMAIL PROTECTED]> wrote: > On 5/6/07, David Coallier <[EMAIL PROTECTED]> wrote: > > On 5/5/07, Jan Reininghaus <[EMAIL PROTECTED]> wrote: > > > I am currently working on my second draw for the page, but I have a > > > question. For my first draw I assumed that all of the new features will > > > be available for all three branches, but is this actually true? > > > > > > By the way, I don't know whether you are aware that all build processes > > > of the win32 snapshots have failed for one day now. > > > > > > -- > > > PHP Internals - PHP Runtime Development Mailing List > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > > Perhaps something like this could be cool: > > http://dev.agoraproduction.com/php/snaps/ > > > > The css might be a bit off as I just wanted to do it quick, but you > > see the idea :) > > > > > > David > > Yes, it is quick, as it doesn't work good in IE6, which is the most > common browser (http://www.w3schools.com/browsers/browsers_stats.asp) > Might be a good alternative for the snaps site, as it is never too > larg :) But it should work on IE6 too of course. > > Tijnema > Oops, well works in IE6.. just looks like hell.. I'd be interested in seeing the % of the browsers on that specific site, it's not like any common website thus can't rely on w3schools imho. Not that it matters how many users are using IE6, PHP should be atleast IE6, IE7, FF, Mozilla, Safari and Netscape compatible. (maybe more?) Anyways, you are right, looks like hell in IE6, try it in firefox or opera .. the goal is to get an idea... not having a stable state with everything working right away, etc... Ok, but are you sure it will be possible in IE6? Didn't take a look at your code yet, and i guess it will work, but we need to be sure of course. So look with a decent browser (wink) and tell me f you like the idea of the tabs, that's the main point I am looking to get feedbacks on. David Yeah, i tested it with Firefox, and it's a good idea. I don't like the style of the button, i think it doesn't really fit into the website, so maybe if you could change the buttons to a little bit more PHP-like it is cool for me, but well, it's not my site :P Tijnema Instead of using all tat javascript and trying to "make it work" in all possible browsers, why don't you simply make multiple pages, with static links from page to page (ie. page1.html for the first button, page2.html for the 2nd, etc.). And as for button appearances, just make it look like the tabs in the PHP bug tracker and it'll all be fine IMO. - tul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
On 5/6/07, David Coallier <[EMAIL PROTECTED]> wrote: On 5/6/07, Tijnema ! <[EMAIL PROTECTED]> wrote: > On 5/6/07, David Coallier <[EMAIL PROTECTED]> wrote: > > On 5/5/07, Jan Reininghaus <[EMAIL PROTECTED]> wrote: > > > I am currently working on my second draw for the page, but I have a > > > question. For my first draw I assumed that all of the new features will > > > be available for all three branches, but is this actually true? > > > > > > By the way, I don't know whether you are aware that all build processes > > > of the win32 snapshots have failed for one day now. > > > > > > -- > > > PHP Internals - PHP Runtime Development Mailing List > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > > Perhaps something like this could be cool: > > http://dev.agoraproduction.com/php/snaps/ > > > > The css might be a bit off as I just wanted to do it quick, but you > > see the idea :) > > > > > > David > > Yes, it is quick, as it doesn't work good in IE6, which is the most > common browser (http://www.w3schools.com/browsers/browsers_stats.asp) > Might be a good alternative for the snaps site, as it is never too > larg :) But it should work on IE6 too of course. > > Tijnema > Oops, well works in IE6.. just looks like hell.. I'd be interested in seeing the % of the browsers on that specific site, it's not like any common website thus can't rely on w3schools imho. Not that it matters how many users are using IE6, PHP should be atleast IE6, IE7, FF, Mozilla, Safari and Netscape compatible. (maybe more?) Anyways, you are right, looks like hell in IE6, try it in firefox or opera .. the goal is to get an idea... not having a stable state with everything working right away, etc... Ok, but are you sure it will be possible in IE6? Didn't take a look at your code yet, and i guess it will work, but we need to be sure of course. So look with a decent browser (wink) and tell me f you like the idea of the tabs, that's the main point I am looking to get feedbacks on. David Yeah, i tested it with Firefox, and it's a good idea. I don't like the style of the button, i think it doesn't really fit into the website, so maybe if you could change the buttons to a little bit more PHP-like it is cool for me, but well, it's not my site :P Tijnema -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
On 5/6/07, Tijnema ! <[EMAIL PROTECTED]> wrote: On 5/6/07, David Coallier <[EMAIL PROTECTED]> wrote: > On 5/5/07, Jan Reininghaus <[EMAIL PROTECTED]> wrote: > > I am currently working on my second draw for the page, but I have a > > question. For my first draw I assumed that all of the new features will > > be available for all three branches, but is this actually true? > > > > By the way, I don't know whether you are aware that all build processes > > of the win32 snapshots have failed for one day now. > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > Perhaps something like this could be cool: > http://dev.agoraproduction.com/php/snaps/ > > The css might be a bit off as I just wanted to do it quick, but you > see the idea :) > > > David Yes, it is quick, as it doesn't work good in IE6, which is the most common browser (http://www.w3schools.com/browsers/browsers_stats.asp) Might be a good alternative for the snaps site, as it is never too larg :) But it should work on IE6 too of course. Tijnema Oops, well works in IE6.. just looks like hell.. I'd be interested in seeing the % of the browsers on that specific site, it's not like any common website thus can't rely on w3schools imho. Anyways, you are right, looks like hell in IE6, try it in firefox or opera .. the goal is to get an idea... not having a stable state with everything working right away, etc... So look with a decent browser (wink) and tell me f you like the idea of the tabs, that's the main point I am looking to get feedbacks on. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
On 5/6/07, David Coallier <[EMAIL PROTECTED]> wrote: On 5/5/07, Jan Reininghaus <[EMAIL PROTECTED]> wrote: > I am currently working on my second draw for the page, but I have a > question. For my first draw I assumed that all of the new features will > be available for all three branches, but is this actually true? > > By the way, I don't know whether you are aware that all build processes > of the win32 snapshots have failed for one day now. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Perhaps something like this could be cool: http://dev.agoraproduction.com/php/snaps/ The css might be a bit off as I just wanted to do it quick, but you see the idea :) David Yes, it is quick, as it doesn't work good in IE6, which is the most common browser (http://www.w3schools.com/browsers/browsers_stats.asp) Might be a good alternative for the snaps site, as it is never too larg :) But it should work on IE6 too of course. Tijnema -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
