Hi, You can find monthly graphs on nexen, the latest is http://www.nexen.net/chiffres_cles/phpversion/16636-php_statistics_for_febru... Regards NK
Wow, I didn't realize that PHP 4 is still so widely used... On 23.03.2007, at 21:36, Karoly Negyesi wrote:
Hi,
You can find monthly graphs on nexen, the latest is
http://www.nexen.net/chiffres_cles/phpversion/16636- php_statistics_for_february_2007.php
Regards
NK
Konstantin Käfer – http://kkaefer.com/
On Sat, 24 Mar 2007 06:46:18 +0100 (CET), "Karoly Negyesi" <karoly@negyesi.net> wrote:
Wow, I didn't realize that PHP 4 is still so widely used...
The mesage of the day from Rasmus with which I wholeheartedly agree: we could lead instead of follow.
Let Drupal 7 be PHP 5 only.
Unfortunately there has to be a balancing act there between leading and following. We don't want to lead ourselves straight into a small niche. :-) However, someone else (sorry, I forget who) pointed out that, like a lot of things in Drupal, Contrib could lead the way. Currently there's nothing stopping a module author from writing a module that requires PHP5. (fQuery comes to mind, and a small number of others.) Why not let more contribs move that direction, so that Drupal becomes "partially PHP5-encouraged"? Core and most modules work in PHP 4, but some variable number of modules require PHP 5. That applies upgrade pressure on hosting companies to upgrade, but in an organic, fluid, and less-risky-to-Drupal way. (Worst case, module X becomes a small niche only rather than Drupal itself, while still "leading" toward PHP 5.) Nothing stops that now, of course, as mentioned, but it's not well-noted. The simplest option, methinks, would be to create a new taxonomy vocab for PHP-version compatibility, and note in documentation somewhere about why it's there and the benefits/risks of making a PHP5-only module. (I'll volunteer to write said page if people are interested.) A module could then self-declare whether it required PHP 5 or not, and "let the market take it from there". Let PHP 4 die the death of a thousand cuts (contrib modules) if bludgeoning it to death with Core itself would be too problematic. :-) The adoption rate of such modules could also then serve as an informal guide for when it would be "market safe" to bump Drupal core's requirements. (I think that can be done with just a taxonomy, but I don't know project module well enough to know if it's a special case where it would need an extra field in the database. Derek, feel free to thwap me if I just made more work for you. <g>) --Larry Garfield
On Mar 24, 2007, at 1:24 AM, Larry Garfield wrote:
(I think that can be done with just a taxonomy, but I don't know project module well enough to know if it's a special case where it would need an extra field in the database. Derek, feel free to thwap me if I just made more work for you. <g>)
a simple taxonomy would do (sort of). however, i've run into the same problem with the "DB support" (mysql vs. pgsql vs. xxx) taxonomy term i want to apply to release nodes and/or project nodes: the DB support only makes sense for certain kinds of projects (modules), not others (themes [god help us if there's mysql-specific code in some theme], translations, etc). likewise, the "php version" vocabulary would be meaningless (and confusing) for translations at least, and probably themes as well. <crack-pipe> speaking of OO ... ;) wouldn't it be slick if node types worked like classes, and you could define a set of node types that were all "child classes" of a base node type? ;) then, we could actually have different kinds of project nodes, that were all project nodes, but some of them were module projects and others where theme projects, etc. then, you could have a vocabulary (or a view, or anything that operates on node types) that points to the "base class" ("project"), in which case it applies to all nodes that are of a type derived from that type, *or* you could have the vocabulary only apply to certain "derived types" ("module project"), not the other kinds of projects. each derived type would have all of the node fields defined in its parent type(s), plus whatever additional fields you wanted to add in the child node type. </crack-pipe> back to the question at hand, either we just use a taxonomy that applies to all projects and live with the slightly weird UI implications, or we do some extra form_alter() work to hide this vocabulary under certain conditions, or we come up with a different approach for these project-type-specific settings we want. suggested reading: http://drupal.org/node/93055 cheers, -derek p.s. in defense of my pipe dream, Dries was calling for innovation and crazy ideas for core... he was also talking about ways to "eliminate the developer". maybe this isn't one of the "killer features" he has in mind, but all of us CS geeks would sure think this is cool. ;) sadly, the amount of code it would require to make something like this possible in core is enormous, so i don't see it happening for D6, if ever...
On 3/25/07, Derek Wright <drupal@dwwright.net> wrote:
p.s. in defense of my pipe dream, Dries was calling for innovation and crazy ideas for core... he was also talking about ways to "eliminate the developer". maybe this isn't one of the "killer features" he has in mind, but all of us CS geeks would sure think this is cool. ;) sadly, the amount of code it would require to make something like this possible in core is enormous, so i don't see it happening for D6, if ever...
I hear the pipes in Oak-town are of high quality :P I've been polling folks a bit, and the "PHP is holding us back" meme is a very interesting one. Of course, this may very well be related to the discussion on PHP4 vs. newer versions. Apple maintained an internal version of OS X on Intel for years, and then came out with it and it quickly went into "Just Works" mode. What would looking at Drupal on PHP 6.x and tying into THAT production cycle bring to Drupal? To PHP? Musings..... -- Boris Mann Skype borismann http://www.bryght.com
The mesage of the day from Rasmus with which I wholeheartedly agree: we could lead instead of follow. Let Drupal 7 be PHP 5 only.
I agree, and disagree. From a developer standpoint, I agree: I like having and using the newest versions of everything, and if my favorite software forces me to "remember" to upgrade, so be it. But, from a service provider standpoint (ie., I provide a service to people who use Drupal or, alternatively, Drupal is a service I provide), I disagree entirely. The lowest common denominator, within reason [1], is what a service should attain. The fact that Rasmus suggested we be leaders provides less weight than if anyone else suggested it: for obvious reasons, he has a vested interest in making sure people use the latest version of his software, just like we have a vested interest in making people use the latest version of ours. As for forcing it in contrib, as someone else suggested, the only real modules that could make any sort of movement there are the Top 10s and, for the exact same reason as Service Provider, probably /won't/ do so. Do we /really/ want to lose a user of Drupal because Views can't be installed on a web host? As a developer, I say "Good riddance". As a service provider, I say no. Unfortunately, my feelings as a service provider allow my developer side to continue working. [1] And I mean "latest version of PHP 4", not "PHP 3", reason. -- Morbus Iff ( take this ming! i'm sick of your dynasty! ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
The lowest common denominator paints us all into a corner. Forward to an object oriented paradigm! Victor Kane http://awebfactory.com.ar On 3/24/07, Morbus Iff <morbus@disobey.com> wrote:
The mesage of the day from Rasmus with which I wholeheartedly agree: we could lead instead of follow. Let Drupal 7 be PHP 5 only.
I agree, and disagree. From a developer standpoint, I agree: I like having and using the newest versions of everything, and if my favorite software forces me to "remember" to upgrade, so be it.
But, from a service provider standpoint (ie., I provide a service to people who use Drupal or, alternatively, Drupal is a service I provide), I disagree entirely. The lowest common denominator, within reason [1], is what a service should attain. The fact that Rasmus suggested we be leaders provides less weight than if anyone else suggested it: for obvious reasons, he has a vested interest in making sure people use the latest version of his software, just like we have a vested interest in making people use the latest version of ours.
As for forcing it in contrib, as someone else suggested, the only real modules that could make any sort of movement there are the Top 10s and, for the exact same reason as Service Provider, probably /won't/ do so. Do we /really/ want to lose a user of Drupal because Views can't be installed on a web host? As a developer, I say "Good riddance". As a service provider, I say no. Unfortunately, my feelings as a service provider allow my developer side to continue working.
[1] And I mean "latest version of PHP 4", not "PHP 3", reason.
-- Morbus Iff ( take this ming! i'm sick of your dynasty! ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
The lowest common denominator paints us all into a corner.
Sure, but in the biggest room available. I'd much rather be in the corner of a conference hall than in the middle of a closet.
Forward to an object oriented paradigm!
Uh. No. Have you read the OOP doc? Or Earl's recent blog followup? -- Morbus Iff ( for safety's sake, don't humiliate me ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
According to the stats of PHP usages, we cannot afford to drop PHP4 any time soon. If the stats change a year from now, then maybe, but not before that. Think of how many people would not be able to run Drupal on shared hosts. Nice way to get an instant installed base reduction. (By the way, I am not stuck to PHP4 myself. In fact, all my sites have PHP5, but they are either dedicated or VPS, so I can choose. The issue is for people who cannot choose which PHP version to run). -- 2bits.com http://2bits.com Drupal development, customization and consulting.
a move to OOP is not necessarily a move totally away from PHP4, but perhaps a gradual one. On 3/24/07, Khalid Baheyeldin <kb@2bits.com> wrote:
According to the stats of PHP usages, we cannot afford to drop PHP4 any time soon. If the stats change a year from now, then maybe, but not before that.
Think of how many people would not be able to run Drupal on shared hosts.
Nice way to get an instant installed base reduction.
(By the way, I am not stuck to PHP4 myself. In fact, all my sites have PHP5, but they are either dedicated or VPS, so I can choose. The issue is for people who cannot choose which PHP version to run). -- 2bits.com http://2bits.com Drupal development, customization and consulting.
Yes, the OOP doc explains the limitations given the historical moment, totally acceptable and the best solution possible then (php 4 oop not up to par), inadequate now. And Earl's blog post is a promising step forward, that is, to start an OOP paradigm on Drupal a portion at a time. He suggests the first portion. Don't want to open up a whole flame war on OOP, but I would say your position is correct in the short term, but that as consultants we have to plan for the medium and long term also (relatively speaking, where months replace years) if our code is going to be reusable. saludos, Victor Kane http://awebfactory.com.ar On 3/24/07, Morbus Iff <morbus@disobey.com> wrote:
The lowest common denominator paints us all into a corner.
Sure, but in the biggest room available. I'd much rather be in the corner of a conference hall than in the middle of a closet.
Forward to an object oriented paradigm!
Uh. No. Have you read the OOP doc? Or Earl's recent blog followup?
-- Morbus Iff ( for safety's sake, don't humiliate me ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
For who do you develop Drupal, or Drupal stuff, or Drupal sites? In the end that is for yourself. And not for Zend, not to promote the latest PHP version, often not even for The Good Of The Web. Just for your own itches to be scratched. As long as there are people who have itches on a PHP4 platform that is what we will have to support. If the choice is between supporting the latest Drupal or rebuilding your server architecture to support a newer version of PHP, I am certain the mayority will choose to simply drop Drupal support. Then the argument about being leader and/or follower was brought up. While it is nice to work on a Better Internet, or whatever high goals, in the end it is your itch that needs to be scratched. When it comes to being leaders, Rasmus should talk to SuSe, RedHat, or Ubuntu, not to Drupal. The distributors should be the ones leading us into a php5 era. If they don't do that, /then/ you corner yourself. I think it is really strange that people actually think about no longer supporting something that is -in fact- the biggest part of their success: the fact that PHP and MySQL is available on nearly every host. If you move away from that, you are going to kill yourself, your business, your websites and the Drupal community. Within a few months, the bulk of the developers will have moved on to a CMS that they can actually install, using the tools and systems they have available or can afford. Bèr
On 3/24/07, Bèr Kessels <ber@webschuur.com> wrote:
I think it is really strange that people actually think about no longer supporting something that is -in fact- the biggest part of their success: the fact that PHP and MySQL is available on nearly every host. If you move away from that, you are going to kill yourself, your business, your websites and the Drupal community. Within a few months, the bulk of the developers will have moved on to a CMS that they can actually install, using the tools and systems they have available or can afford.
Bèr
There is no doubt about this. All discussion on PHP5 and OOP is based on equal availability in common hostings, etc., for a time when PHP5 is as omnipresent as PHP4 is now. The problem is, that obviously that will come in time, but we should be thinking about the implications of migration now. A paradigm shift cannot come at the drop of a hat either. Victor Kane http://awebfactory.com.ar
On 24.03.2007, at 18:04, Bèr Kessels wrote:
If the choice is between supporting the latest Drupal or rebuilding your server architecture to support a newer version of PHP, I am certain the mayority will choose to simply drop Drupal support.
Drupal is not in a position where we should try with all means that Fantastico et al keep us in their distribution. It's not that Drupal is at a point where we desperately need any user. Existing users will update their platform (I did that with MySQL) to continue using Drupal. Backwards compatibility has always been an issue. For Drupal, it has been decided to not make Drupal versions backward compatible but to only provide an upgrade path. And that's a good decisions. Take a loot at Microsoft Windows: They try to be as much backward compatible as possible, and for that reason, they always run in problems. I read recently that people complained that Vista doesn't ship the Help viewer by default and that Microsoft had to provide a Vista- compatible version. Microsoft dropped the Help viewer because it was there since Windows 3.1 (!) and didn't get any updates. In contrast to that are Mac OS and Linux: Apple generally doesn't care to provide lots of backward compatibility, new software is usually for the most recent OS and sometimes for the previous version (thus 10.3 and 10.4 atm) only. My point is that providing too much backward compatibility hinders progress. Especially in our domain, the internet, you can't afford to not advance if you want to stay up to par with competitors. I don't say however, that we should not support old versions anymore, that's something entirely different. Konstantin Käfer – http://kkaefer.com/
Hi, Karoly Negyesi wrote:
Wow, I didn't realize that PHP 4 is still so widely used...
The mesage of the day from Rasmus with which I wholeheartedly agree: we could lead instead of follow.
Let Drupal 7 be PHP 5 only.
Yes I like this, but really unless we change to real object orientated design people should be able to use the PHPCompat library from pear to get it working if they really need to. Gordon.
Yep, I agree that this is problematic for dropping support for PHP 4. I think that this is not likely to change until there's wider adoption for php 5 by the vendors who bundle LAMP with operating systems. Redhat ES 4 and Mac OSX still default ship with php 4 as the default install. My personal preference would be to hold off requiring PHP5, assuming our goal is to make drupal available to the masses :). I'm not opposed to people writing modules that require PHP 5, but I think realistically it will be hard to force this hand when the commercially supported OS's will not provide automatic updates for PHP 5. I've been frustrated by this for a while, and wonder why the big boys haven't moved in such a long time. Hmm... I wonder if it might not be good to ask this question on the drupal service providers list to see what impact it might have for those who host drupal sites? That being said my hosting vendor does provide php 5, as I do at the school I work for. Seems like we're close. On Mar 23, 2007, at 1:36 PM, Karoly Negyesi wrote:
Hi,
You can find monthly graphs on nexen, the latest is
http://www.nexen.net/chiffres_cles/phpversion/16636- php_statistics_for_february_2007.php
Regards
NK
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Metzler schrieb:
Yep, I agree that this is problematic for dropping support for PHP 4. I think that this is not likely to change until there's wider adoption for php 5 by the vendors who bundle LAMP with operating systems. Redhat ES 4 and Mac OSX still default ship with php 4 as the default install. My personal preference would be to hold off requiring PHP5, assuming our goal is to make drupal available to the masses :).
As you all should have noticed, Karoly mentioned to drop PHP4 support for Drupal 7. Drupal 7 will be released at some time next(!) year. The correct time to evaluate his proposition is therefore the time when development of Drupal 7 starts, which will be after the release of Drupal 6 later this year. By that time, several Linux distributions will have released new versions and the availability of PHP5 might have increased widely. Let's look at this again in summer then and concentrate on the development of the current Drupal version.
I'm not opposed to people writing modules that require PHP 5, but I think realistically it will be hard to force this hand when the commercially supported OS's will not provide automatic updates for PHP 5.
I have absolutely no love for these "commercially supported" Linux distros. If the vendors of these distros think they'll be able to support them for their customers till the end of time, then it is solely the concern of said vendors to either make sure upcoming version of all software runs on their distro or to support outdated versions of all software by creating security releases. Cheers, Ger»and please keep your parakeets to yourself«hard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGBXAUfg6TFvELooQRAoU+AKCLS6M+pgmHoHzwBlFhanowieBNtACgt9SI n84Jm4zcluZE+taREq3EQwY= =Mm4A -----END PGP SIGNATURE-----
On 3/24/07, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
David Metzler schrieb:
Yep, I agree that this is problematic for dropping support for PHP 4. I think that this is not likely to change until there's wider adoption for php 5 by the vendors who bundle LAMP with operating systems. Redhat ES 4 and Mac OSX still default ship with php 4 as the default install. My personal preference would be to hold off requiring PHP5, assuming our goal is to make drupal available to the masses :).
As you all should have noticed, Karoly mentioned to drop PHP4 support for Drupal 7. Drupal 7 will be released at some time next(!) year.
The correct time to evaluate his proposition is therefore the time when development of Drupal 7 starts, which will be after the release of Drupal 6 later this year.
Well said. By that time, several Linux distributions will have released new
versions and the availability of PHP5 might have increased widely.
Some distros already include it. For example, on Ubuntu 6.10 (release last October) has 5.1.6, as well as the option to install 4 if you want to. One issue is that some providers still use Fedora Core 4, or older versions of CentOS. I see these all the time and it makes my life harder. Another issue may be that some popular packages (e.g. forum software, ...etc.) would not work well with PHP5, and hence hosting companies are conservative in upgrading to PHP5. Let's look at this again in summer then and concentrate on the
development of the current Drupal version.
Agreed. I hope the landscape changes in favor of PHP5, but I am not holding my breath. -- 2bits.com http://2bits.com Drupal development, customization and consulting.
Quoting Khalid Baheyeldin <kb@2bits.com>:
On 3/24/07, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
David Metzler schrieb:
Yep, I agree that this is problematic for dropping support for PHP 4. I think that this is not likely to change until there's wider adoption for php 5 by the vendors who bundle LAMP with operating systems. Redhat ES 4 and Mac OSX still default ship with php 4 as the default install. My personal preference would be to hold off requiring PHP5, assuming our goal is to make drupal available to the masses :).
As you all should have noticed, Karoly mentioned to drop PHP4 support for Drupal 7. Drupal 7 will be released at some time next(!) year.
The correct time to evaluate his proposition is therefore the time when development of Drupal 7 starts, which will be after the release of Drupal 6 later this year.
Well said.
By that time, several Linux distributions will have released new
versions and the availability of PHP5 might have increased widely.
Some distros already include it. For example, on Ubuntu 6.10 (release last October) has 5.1.6, as well as the option to install 4 if you want to.
I can see an extention to the EOL for 6.0 will most likely happen should this venture happen. Module maintainers would need to be up to speed with php 5 supported versions and there are modules still that have not been updated to Drupal Core 5. Planning when this should occur earlier than the start of coding is a great idea because it can help publicize it with the module maintainers. The real question needs to be will the module maintainers be ready to support such a move? Earnie
On Saturday, 24. March 2007, Khalid Baheyeldin wrote:
On 3/24/07, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
The correct time to evaluate his proposition is therefore the time when development of Drupal 7 starts, which will be after the release of Drupal 6 later this year.
Well said.
By that time, several Linux distributions will have released new versions and the availability of PHP5 might have increased widely.
Some distros already include it. For example, on Ubuntu 6.10 (release last October) has 5.1.6, as well as the option to install 4 if you want to.
Good news here (from Planet Ubuntu): http://beuno.com.ar/archives/14 Debian Etch still has PHP 4 as an install option (next to PHP 5), but with at Ubuntu, SLES and RHEL/Fedora having dropped PHP 4 completely in their current releases, it seems we're on the right track. Regards, Jakob
Karoly, since you are doing translation & db support I wanted you to look over the ddl abstraction patch I'm working on. It's not complete, but this morning I start reading the SQL92 spec trying to make sure I'm compartmentalizing the clauses of an SQL statement properly. It seems a lot like translation issues. I'd appreciate if you could take a look at _db_map_column and the flow from there. I know it can be refactored to be more efficient, but I'm trying to reflect the ansi sql syntax it's easier for me to develop. Optimization can come later. The first doc block is no longer accurate. This patch does not yet work. I just want to make sure the concept is sound. On Fri, 2007-03-23 at 13:36 -0700, Karoly Negyesi wrote:
Hi,
You can find monthly graphs on nexen, the latest is
http://www.nexen.net/chiffres_cles/phpversion/16636-php_statistics_for_febru...
Regards
NK
participants (15)
-
Boris Mann -
Bèr Kessels -
Darrel O'Pry -
David Metzler -
Derek Wright -
Earnie Boyd -
Gerhard Killesreiter -
Gordon Heydon -
Jakob Petsovits -
Karoly Negyesi -
Khalid Baheyeldin -
Konstantin Käfer -
Larry Garfield -
Morbus Iff -
Victor Kane