PHP 5.3.3 / 5.2.14

PHP logo (60 pix) Afgelopen donderdag zijn er nieuwe versies van de programmeertaal PHP verschenen, namelijk een nieuwe versie uit de 5.3-serie en de laatste uit de 5.2 versie. PHP is een een recursief acroniem wat staat voor PHP: Hypertext Preprocessor en wordt voornamelijk gebruikt om op webservers dynamische webpagina's te creëren. Versie 5.2.14 is de laatste versie uit de 5.2-tak en bevat meer dan zestig bugfixes, terwijl versie 5.3.3 meer dan honderd verbeteringen aan boord heeft. Meer informatie kan in de afzonderlijke changelogs worden gevonden.

PHP 5.3.3 Released!

The PHP development team would like to announce the immediate availability of PHP 5.3.3. This release focuses on improving the stability and security of the PHP 5.3.x branch with over 100 bug fixes, some of which are security related. All users are encouraged to upgrade to this release.

For users upgrading from PHP 5.2 there is a migration guide available, detailing the changes between those releases and PHP 5.3.

For a full list of changes in PHP 5.3.3, see the ChangeLog.

PHP 5.2.14 Released!

The PHP development team would like to announce the immediate availability of PHP 5.2.14. This release focuses on improving the stability of the PHP 5.2.x branch with over 60 bug fixes, some of which are security related.

This release marks the end of the active support for PHP 5.2. Following this release the PHP 5.2 series will receive no further active bug maintenance. Security fixes for PHP 5.2 might be published on a case by cases basis. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3.

To prepare for upgrading to PHP 5.3, now that PHP 5.2's support ended, a migration guide available, details the changes between PHP 5.2 and PHP 5.3.

For a full list of changes in PHP 5.2.14 see the ChangeLog.

PHP screenshot (481 pix)

Lees meer

Reacties (30)

Peter

24 juli 2010 12:59

Noemswaardig verschil is dat methods met dezelfde naam als de class, mits de class in een namespace zit, niet langer als constructor worden gezien. Je zult dus echt __construct moeten gaan gebruiken

StM @Peter • 24 juli 2010 13:12

Het is naar mijn mening van de gekken dat ze dit aangepast hebben in een minor release...

Verwijderd @StM • 24 juli 2010 13:54

Een van de grootste kritiekpunten van PHP is altijd geweest dat er weinig design/planning bij de ontwikkeling ervan te pas is gekomen en dit bewijst het maar weer.

Peter

@StM • 24 juli 2010 14:31

Dat ben ik zeker met je eens! Het is gedrag wat, onder andere door PEAR, een hele lange tijd als best-practice werd gezien en dus zonder twijfel toegepast is in scripts. Ook scripts die namespaces gebruiken.

Daarnaast introduceert het een nieuwe inconsequentie: gelijknamige methods zijn nu soms wel, en soms geen constructors, afhankelijk van of namespaces wel of niet gebruikt worden. Als ze dit zo nodig willen verwijderen (wat van mij ook nog niet zo zeer hoeft, ondanks dat het wel beter in lijn is met andere "magische methods") zouden ze het beter in een grote release kunnen doen.

Daarnaast is dit een maintenance release, niet eens een minor.

Freeaqingme @StM • 24 juli 2010 17:15

Let wel; ze doen dit alleen als je class in een namespace anders dan \ zit. Ofwel; alleen als het aannemelijk is dat jij je code geport hebt naar php >5.3 dan gebeurt dit, anders niet.

PhoenixT @Peter • 24 juli 2010 14:26

Dat de constructor dezelfde naam heeft als de class is in vrijwel alle programmeertalen zo. Waarom zouden ze dit veranderen? Is alleen maar verwarrend toch

dajero @PhoenixT • 25 juli 2010 12:17

Het is ook gebruikelijk dat de constructor een vaste naam heeft onafhankelijk van de class name. Zo gebruik je in Objective-C een van de init methoden en in Ruby initialize.

J.J.J. Bokma @PhoenixT • 25 juli 2010 00:51

Heh, daar is en blijft het PHP voor.

Ventieldopje @Peter • 24 juli 2010 14:07

Lijkt me dat dit alleen verwarring op gaat brengen, ook bij mensen die hele dagen aan PHP doen, ik heb ook vaak zat dat ik moe ben en ff niet op let en dan dit soort foutjes maak

Maargoed, vind het maar irritant ..

Eagle_Erwin 24 juli 2010 13:19

Ik vind het erg jammer dat de PECL-extenties voor Windows nog steeds niet allemaal geport zijn naar 5.3.x. Sinds de release van 5.3.0, ongeveer een jaar geleden, zitten er een aantal standaard in, maar heel veel werken nog niet. Op de site http://windows.php.net wordt netjes gezegd dat ze er aan werken, maar ik heb in een jaar tijd nog geen verbetering gezien.

Voorlopig weerhoudt dat mij er nog van om de 5.2-tak te verlaten, ik gebruik een aantal van die PECL-extenties die nog niet onder 5.3 werken, zoals zip en id3.

bulle bas @Eagle_Erwin • 24 juli 2010 13:29

Ik vind het ook hemeltergend. De meeste ontwikkelaars ontwikkelen op windows, en 'deployen' het op een Linux-server. Het is ook niet zo makkelijk om het maar even zelf te doen, voor Apache moet je met VC6 compileren. Dat is een oude compiler uit 1998 die niet zomaar te krijgen meer valt.

Freeaqingme @bulle bas • 24 juli 2010 17:18

Nouja, er zijn een paar opties:
* of je compilet al die dingen zelf, zonder te klagen, en je contribute ze weer terug aan de community
* Of je gaat zelf ook lekker linux gebruiken.

Php is FOSS, op vrijwillige basis, dus gaan klagen dat anderen geen werk doen dat jij ook kan doen is vreemd. Zeker als er een werkbaar alternatief is. En ja, ik werk al een aantal jaar uitsluitend op linux, and I'm loving it

bulle bas @Freeaqingme • 24 juli 2010 22:53

* of je compilet al die dingen zelf, zonder te klagen, en je contribute ze weer terug aan de community
* Of je gaat zelf ook lekker linux gebruiken

Het eerste punt: je begrijpt het probleem denk ik nog niet helemaal goed. Het probleem is juist dat een gemiddelde ontwikkelaar dit niet voor elkaar kan krijgen, omdat MS VC6 niet meer wilt aanbieden. Het is dus nergens te verkrijgen. Hooguit kan je met 'piraterij' het proberen, maar dan weet je niet of je een trojan binnenhaalt bijvoorbeeld.

Het tweede punt kan je altijd besluiten. Voor veel php-devs die ook met het adobe-portfolio werken uitgesloten.
Als je zegt cross-platform te zijn moet je dat ook echt zijn.

Ik begin echter last te krijgen van de gedachte dat dit te maken heeft met de deal tussen Zend en MS. MS heeft voor php 5.3 uitkwam met Zend samengewerkt om php sneller te kunnen laten draaien. Op deze manier heeft het IIS van MS een voordeel boven de 'vrije stapel' AMP.

Dit is dus niet zomaar werk wat men zelf kan doen. Dus ik vind het terecht dat dit aangekaart wordt.

Freeaqingme @bulle bas • 25 juli 2010 00:21

ah, dat heb ik dan inderdaad niet goed begrepen (waarom moet dat op windows dan weer zo moeilijk zijn?

).

>> Als je zegt cross-platform te zijn moet je dat ook echt zijn.
Het PHP project is dat voor 't grootste gedeelte ook wel (met uitzondering van posix functies) of bugs. Bij Pecl ligt 't natuurlijk anders omdat het niet direct deel uitmaakt van php zelf, maar meer een soort van 3rdparty plugins welke door een centraal systeem verspreid worden zijn.

Hoe de MS-Zend deal hier mee te maken heb snap ik nog even niet?

Overigens bleek uit een recente survey van Zend (welke met name onder de ZF community, en dat gedeelte wat devzone leest gehouden is) dat 40% linux op linux developt, en 20% op Os X. Zeker gezien 't feit dat 't merendeel uiteindelijk ook gedeployed wordt op Linux kan ik me heel goed voorstellen waarom men daar 't meeste tijd in stopt. Hoewel dat natuurlijk los staat van deze discussie.

bulle bas @Freeaqingme • 25 juli 2010 00:52

ah, dat heb ik dan inderdaad niet goed begrepen (waarom moet dat op windows dan weer zo moeilijk zijn? ).

Ik weet dat niet precies, maar je moet daarvoor ook naar apache kijken. Want het feit dat php met VC6 wordt gecompiled voor windows, heeft te maken met het feit dat apache nog steeds daarmee aan de weer is.
Ik denk dat het te maken heeft met de luxe die MS biedt. Vergelijk het met XP. MS gaat tot het etreme om compatabiliteit te bieden. Ik geloof dat VC6 jarenlang nog ondersteunt is, terwijl het allang zwaar verouderd is.

Dat zal de apache-devs het mogelijk makkelijk hebben gemaakt om jarenlang op de zelfde manier door te gaan, zonder het buildplatform bij te houden. [Kom daar eens om bij Linux

].

MS-Zend is makkelijk te begrijpen: als de binaries voor php@apache gaan ontbreken, dan kan MS meer IIS-licenties verkopen, aangezien php@IIS nu voordelen heeft. Immers, voor die laatste zijn de binaries wel op orde. En kan je er ook nog zelf wat aan doen.

s.stok @bulle bas • 25 juli 2010 11:16

Zend werkt zelfs met VC8 in Zend Studio

Ik heb kapot gezocht naar die versie.

Ze waren namelijk zo vrij geweest om de Intl extensie niet mee te bundelen.
En aangezien VC8 en VC9 niet samen gaan ben ik drie dagen aan het rotzooien geweest om een extensie te maken. En uiteindelijk is dat gelukt.

Magicwand die was weer wel mee geleverd, maar een extensie die standaard beschikbaar is was teveel moeite

Daarnaast heb ik een keer een flinke aanvaring gehad over Zend Optimizer.
http://forums.zend.com/vi...57&t=1365&start=10#p15619

PHP is een perfecte taal om mee te werken, maar zoals ook de andere zeggen, de programmeurs laken soms echt om dingen goed te doen.

Vooral de grote veranderingen in minor versions zijn echt te gek voor woorden!
Ik hoop echt oprecht dat de PHP developers group hier meer aandacht aan gaat besteden.

Olaf van der Spek @Freeaqingme • 24 juli 2010 17:34

Dat vind ik het negatieve van veel open source developers: kritiek hebben is verboden.

Freeaqingme @Olaf van der Spek • 24 juli 2010 19:02

Kritiek hebben is zeker niet verboden, en kan soms heel goed zijn. Ik vind 't alleen wel hyprociet als die kritiek komt van mensen die niet(s) bijdragen aan de Opensource community, en zelf ook niet helpen met het zoeken naar een oplossing van hun probleem.

Katsunami @Freeaqingme • 24 juli 2010 19:42

De open source community is in mijn ogen op veel punten overhyped. Het werkt niet goed, behalve als er een groot en leidinggevend sterk bedrijf achter staat. Het lijkt -nog steeds- alsof iedereen maar doet waar hij zin in heeft. Zoiets als dit:

Noemswaardig verschil is dat methods met dezelfde naam als de class, mits de class in een namespace zit, niet langer als constructor worden gezien. Je zult dus echt __construct moeten gaan gebruiken.

Dat is toch van de ratten besnuffeld om dit zomaar even tussen de soep en aardappels te wijzigen?!

Zelf gebruik ik al __construct sinds het is geïntroduceerd, want ik had al het gevoel dat het later wel de standaard zou gaan worden. Ik kan me echter voorstellen dat er nog tig oudere scripts draaien, die met-en-met zijn geëvolueerd. Als een webhost (waar je zelf geen controle over hebt, bijvoorbeeld als je een hostingpakket afneemt) besluit om te upgraden, dan kan het wel eens zijn dat je hele site zomaar uit elkaar flikkert.

Dat is absurd.

Een verandering zoals deze zou bijvoorbeeld een jaar van te voren, voor PHP 6.0, aangekondigd moeten worden. Ik wil best meehelpen om hier en daar iets voor FOSS te doen (want ik ben op zich wel een voorstander van het idee), maar dan moet ik wel weten waar ik mee bezig ben. Met de ongeplande wendingen die sommige projecten echter vaak nemen, weet ik soms echter van de ene op de andere dag niet meer wat nou de bedoeling is.

[Reactie gewijzigd door Katsunami op 22 juli 2024 14:52]

user109731 @Katsunami • 24 juli 2010 20:07

De open source community is in mijn ogen op veel punten overhyped. Het werkt niet goed, behalve als er een groot en leidinggevend sterk bedrijf achter staat. Het lijkt -nog steeds- alsof iedereen maar doet waar hij zin in heeft. Zoiets als dit:

Dat is toch van de ratten besnuffeld om dit zomaar even tussen de soep en aardappels te wijzigen?!

Dit is idd slordig, mar merk op dat PHP ook niet enkel door vrijwilligers gemaakt wordt. Veel dingen (Zend Engine bijvoorbeeld, de core van PHP) komen bij Zend vandaan, dus een bedrijf erachter zegt ook niet alles. PHP is wat dat betreft wel een beetje berucht, veel dingen in de taal zijn eigenlijk bugs of designfouten.

Andere open-source projecten zoals Python (en Ruby denk ook) zijn hier veel stricter in, en daar staat ook niet direct een groot bedrijf achter (tegenwoordig werken een aantal Python-developers bij Google, maar dat is niet altijd zo geweest). Daar wordt voor zulke wijzigingen ook eerst een voorstel geschreven, daar wordt uitgebreid over gesproken, en dan wordt er beslist hoe en wat er geimplementeerd kan worden.

Wat dat betreft is het PHP-project (gelukkig) niet representatief voor alle open-source projecten, o.a. Python laat zien dat het ook anders kan

[Reactie gewijzigd door user109731 op 22 juli 2024 14:52]

bulle bas @user109731 • 24 juli 2010 23:13

Sja ik stuur ook niet zomaar meer bug-meldingen in. De meeste rapporten die je daar vind worden onmiddelijk op bogus gezet—een term die trouwens een van de slechtste manieren is om de bug-melder van feedback te voorzien. Eclipse gebruikt gewoon "not a bug".

Mijn ervaringen zijn niet positief. Je bent eerst bezig de mensen te overtuigen om de melding te bekijken na een bogus-status. Dan blijkt het toch echt een bug te zijn en dan wordt hij aan de eigenaaar toegewezen die er eigenlijk geen trek in heeft.
Dat laatste kan ik hem niet kwalijk nemen, het is vrijwilligerswerk en zoiets kan je ook niet eisen, want dan zou het even goed van mij geëist kunnen worden.

De regie ontbreekt. Binnen Linux heb je Torvalds en bij php zou je Zend moeten hebben. Probleem is alleen dat de originele eigenaren van PHP precies die laissez-faire-mentaliteit hebben, de reden waarom de taal vanaf het begin al niet zo netjes was. Dus zij hebben nimmer de rol gespeeld van coördinator. Zend houdt zich bezig met randtechnologieën als Zend Server, Zend Framework etc.

Voor een geïnterpreteerde taal presteert PHP wel erg goed, het heeft een gunstig 'eco-systeem' en is echt voor het web gesneden. De pragmatische aanpak is denk ik wel juist ook onderdel geweest van het succes.
Het had groter kunnen zijn als Zend zich had bekommerd over consistentie.

Bij Python had je altijd al Guido Van Rossum erachter, een wetenschapper die uit was op een elegante en praktische taal.

Het punt is dus eerder dat degene met de meeste autoriteit binnen een bepaalde programmeertaalgemeenschap welomlijnde ideeën en nauwgezetheid koestert.

Freeaqingme @Katsunami • 24 juli 2010 20:08

Zoals ik al eerder in deze thread heb opgemerkt geldt deze wijziging enkel voor namespaced classes. Dus tenzij je in php >5.3 code nog de oldstyle constructors gebruikte merk je er niets van.

Verder kan je natuurlijk de php bugtracker eens openen, en een bug vinden die jou schikt (of waar je bijvoorbeeld zelf ook last van hebt), en daar een patch voor aandragen. Doe je dat een aantal keer met succes krijg je vanzelf svn access. Mocht je nou geen C(++) kunnen kan je ook bijvoorbeeld helpen met het unittesten van php, of helpen aan een project wat door veel php'ers gebruikt wordt (bijvoorbeeld het Zend Framework, als je daar iets mee hebt).

cariolive23 @Katsunami • 25 juli 2010 11:22

De open source community is in mijn ogen op veel punten overhyped. Het werkt niet goed, behalve als er een groot en leidinggevend sterk bedrijf achter staat.

Onzin, je hebt goed project management nodig. En dat is schaars, zowel bij open als closed source.

Dat is toch van de ratten besnuffeld om dit zomaar even tussen de soep en aardappels te wijzigen?!

En dit soort blunders worden niet door closed source producenten gemaakt? Of de grote leidinggevende bedrijven achter een open source product? o.a. MySQL (en dus SUN en Oracle) staat bol van dit soort fout gedrag.

Dit soort fouten hebben niets met de licentievorm te maken maar alles met het management van het product en project.

Olaf van der Spek @Freeaqingme • 24 juli 2010 23:45

Ik vind 't alleen wel hyprociet als die kritiek komt van mensen die niet(s) bijdragen aan de Opensource community,

Jij hebt vast ook kritiek op dingen waar je zelf niks aan bijdraagt. Voetbal, de politiek, wat anders...

Freeaqingme @Olaf van der Spek • 25 juli 2010 00:16

Ik stem, ik communiceer (soms) met politici, en heb ooit eens een petitie gehouden.

Verder is de FOSS wereld er eentje die zich karakteriseert door het feit dat "iedereen" kan bijdragen. Juist daarom is het extra hypocriet.

hostname @bulle bas • 24 juli 2010 14:28

Was een van de punten van 5.3 niet dat je ook met VC9 kon gaan compileren?

bulle bas @hostname • 24 juli 2010 14:47

Ja maar daar hebben we niks aan. VC9 is bedoeld voor IIS, dat gaat niet werken op Apache.

If you are using PHP with Apache 1 or Apache2 from apache.org you need to use the VC6 versions of PHP

If you are using PHP with IIS you should use the VC9 versions of PHP

Olaf van der Spek @bulle bas • 24 juli 2010 17:03

voor Apache moet je met VC6 compileren.

FastCGI anyone?
Compileren lijkt me het problemen niet, dat kunnen PHP mensen net zo goed.

[Reactie gewijzigd door Olaf van der Spek op 22 juli 2024 14:52]

field33P @bulle bas • 24 juli 2010 14:11

zonder piraterij dan he.

Jan-E @Eagle_Erwin • 25 juli 2010 22:55

Ik zit met iets vergelijkbaars. Ik maak veel gebruik van php_ffmpeg.dll en heb dat nu draaiend onder 5.2.12. 5.2.14 zal vermoedelijk ook nog wel lukken. Maar een versie voor de 5.3.x tak ben ik nog niet tegengekomen. Even snel compileren voor 5.3.x zie ik me ook niet doen, want van deze beschrijving word ik niet veel wijzer.

Op dit item kan niet meer gereageerd worden.

Versienummer	5.3.3 / 5.2.14
Releasestatus	Final
Besturingssystemen	Scripttaal
Website	PHP
Download	http://www.php.net/downloads.php
Licentietype	Voorwaarden (GNU/BSD/etc.)

11-'24	PHP 8.4.1	43
11-'23	PHP 8.3.0	2
07-'23	PHP 8.2.8 / 8.1.21	1
06-'23	PHP 8.2.7 / 8.1.20 / 8.0.29	5
12-'22	PHP 8.2.0	3
12-'22	PHP 8.1.13 / 8.0.26	3
11-'21	PHP 8.1.0	38
07-'21	PHP 8.0.8 / 7.4.21 / 7.3.29	0
05-'21	PHP 8.0.6 / 7.4.19	13
11-'20	PHP 8.0.0	7

Software-update: PHP 5.3.3 / 5.2.14

Update-historie

Lees meer

Reacties (30)

Sorteer op:

Weergave: