Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
PHP Programming

PHP 4.3.0 Released 243

Posted by michael from the choice-of-a-new-generation dept.
aftk2 writes "PHP.Net has just reported the release of PHP 4.3.0. The update sports a unified method of handling files and sockets, a bundled GD library (for working with images), and finalizes PHP's command line interface. For other information, check out the ChangeLog."
This discussion has been archived. No new comments can be posted.

PHP 4.3.0 Released More

PHP 4.3.0 Released

Comments Filter:

  • That's great (Score:5, Insightful)

    by Karamchand ( 607798 ) on Friday December 27, 2002 @03:05PM (#4968356)
    Thanks go to the PHP team for all this great work!! :-)

    It's a pity though that Apache 2 support is still experimental. I hope the Apache and the PHP team get the work done fast so that Apache 2 can spread faster! :)

    • Re:That's great (Score:2, Interesting)

      by ajayrockrock ( 110281 )
      The last time I asked about apache2 support on the #PHP IRC channel, someone told me that the apache2 api is still a moving target and that's why it's taking so long for php to be "stable" on apache2.

      I can't wait to use Apache2 but I need PHP support to be stable before I can upgrade.

      later,
      ajay
    • Yes, this is a shame. I too hope they can get together and freeze the API or whatever it is thats holding things up.

      Last time I tried php with apache (4.2.2 + 2.0.43 IIRC), apache would segfault when it received a SIGHUP after log rotation. It seems libphp4 was not handling the signal correctly.

      This may have been solved by now, but I'm not going to use PHP with Apache 2.x until it gets better than this.
  • To eliminate duplicate Slashdot posts

  • Best New Feature (Score:5, Interesting)

    by The-Perl-CD-Bookshel ( 631252 ) on Friday December 27, 2002 @03:09PM (#4968385) Homepage Journal
    Is the friendly error messages [php.net] , they point you back to the PHP Documentation [php.net]. Being a regular in #PHP IRC channels, this is going to save me a lot of headaches :) Praise the lord, the newbies have fully automated RTFM messaging!!

    • Re:Best New Feature (Score:3, Interesting)

      by netsharc ( 195805 )
      Hehe, you say it right, PHP is nowadays too popular that every "I know Frontpage!" idiot has begun trying it.

      Yes I'm an elitist. Leave computing to the real guys.
      • My favorite are the Web Monkey'esque articles that show you how to create a content management system that can be "hacked" by an 11 year old with little more PHP knowledge than O'Reilly's pocket reference.

  • PGSQL support problem? (Score:3, Informative)

    by DragonMagic ( 170846 ) on Friday December 27, 2002 @03:13PM (#4968403) Homepage
    I'll have to recheck this later, but I installed PHP 4.3.0 on a Cobalt RaQ3 over a PHP 4.2.3 install using the same configuration line, simply adding the GD install flags. The PostgreSQL make errored out on the install, when it was compiled in 4.2.3 without a problem. Took it out of the configure line, and it installed fine.

    I really do enjoy having Postgre and MySQL support on the same machine, but for now I guess I'll have to stick with MySQL until I figure this one out.

    But above all, CONGRATS on the changes, PHP team, and please keep up with the good work! It's a great software and a great asset to server administrators, programmers and scripters around.

  • In a related note.... (Score:5, Informative)

    by Davorama ( 11731 ) on Friday December 27, 2002 @03:22PM (#4968473) Journal
    ...this just came in to my inbox. PEAR at version 1.0. Good job folks!
    The new PEAR package PEAR-1.0 (stable) has been released at http://pear.php.net/.

    Release notes
    -------------
    * set default cache_ttl to 1 hour
    * added "clear-cache" command

    Package Info
    -------------
    The PEAR package contains:
    * the PEAR base class
    * the PEAR_Error error handling mechanism
    * the PEAR installer, for creating, distributing
    and installing packages

    Related Links
    -------------
    Package home: http://pear.php.net/package-info.php?package=PEAR
    Changelog: http://pear.php.net/package-changelog.php?package= PEAR
    Download: http://pear.php.net/get/PEAR-1.0.tgz

    Authors
    - ------------
    Stig Bakken <ssb@fast.no> (lead)
    Thomas V.V.Cox <cox@idecnet.com> (developer)
    Martin Jansen <mj@php.net> (helper)

  • XML? (Score:2, Interesting)

    by King of the World ( 212739 )
    One of the problems I'm having is that there's no way in the standard PHP build to deal with XML. I either have to treat it as a string and write regular expressions (which, as anyone who knows the regexp xml problem, isn't reliable) or build my own with some external xml library, meaning that as I want to allow others to use my code I have to get each user to recompile too (which is like asking people to recompile their kernel, some will do it, some won't, and there's _usually_ no good reason why it had to happen in the first place).

    Does this release change what's bundled in the base XML support? They mention function call changes but usually those functions are useless without a recompile.

    PHP is still mostly a web page language. XML support should be just bread and butter to it. I need it to deal with RSS or RDF. I need it to deal with user input (if I want to do XHTML I don't want a user typing posts that are malformed - right now I have no way of knowing that).

    //

    Php has strip_tags() which, naturally, strips tags from a string. But as there's little functional difference between tags and attributes it seems strange that I'm unable to strip attributes with as easy a syntax (yes, I have to use regexps again).

    //

    I hope this doesn't sound too down on PHP. It's a good language. It's just not a great language like Java or .NET (lets face it, OO in PHP isn't great, and that's what most people have been waiting on PHP 4.3 to fix)

    • Re:XML? (Score:3, Informative)

      by DragonMagic ( 170846 )
      PHP can be configured for XML support, but I've seen PHP move from HTML to XHTML support instead. One thing I'd love to see is a way for an install-level configuration for using XHTML or XML on PHP output. Also, yes, the striptags and htmlentities and such will barf on XML codings, and there should be better support for this, hopefully in 4.4.0
    • You should consider switching to the Zope [zope.org] platform. Although XML parsing is not yet out-of-the-box in Zope, there are several products for the platform available free of charge that should do what you want it to do.

    • Re:XML? (Score:2, Informative)

      by HarrisonFisk ( 624200 )
      PHP has built in support for expat XML parser [php.net] The parser has come with PHP since PHP 4.0 Beta 4.

      There also is a nice wrapper called XML_parser [php.net] in PEAR. That package is installed by default in PHP 4 I believe.

      If you are going to deal with RSS and RDF stuff, then I definately recommend you check out the PEAR XML_RSS package [php.net]

      I see nothing lacking with PHPs XML support.
      • > I see nothing lacking with PHPs XML support.

        Expat/SAX in PHP rocks. XSLT is pretty good. The PEAR XML parser isn't bad, either.

        However, XML-DOM (DOMXML, whatever) sucks because, well, can you say, "Shifting APIs"? On the one hand, I appreciate the fact that it's getting fairly close to W3 specs now, and that's a Very Good Thing(tm); on the other, the function names and definitions (along with some of the interfaces themselves) have changed in very non-trivial ways with nearly every single bloody point release since 4.0.0 and it's a royal pain in the arse. I'm working on a project right now that would be much better done if we could depend on consistent DOM support.

        My pet peeve aside, the new release looks pretty good. :)

        (Before you flame, please consider the possibility that there might be other uses for the Document Object Model besides making stuff fly around in browser windows. Thank you.)
    • >>OO in PHP isn't great, and that's what most people have been waiting on PHP 4.3 to fix

      No, that's what people have been waiting on PHP 5 with Zend 2.0 to fix. Big difference.

      However, your comments about XML and string handling have nothing to do with PHP's OO capabilities. I would argue that PHP's string handling and regex are better than the standard ones you find in Java or .NET.

      XML support? Well, yes PHP isn't a native XML-handling language, nor is Java (.NET might be another story).

      With any standard programming language, though, XML support is not "native". You have to include the appropriate modules or classes. Ditto with Java.

    • Comment removed based on user account deletion
    • I too would love to see XML natively available for PHP. I've written a module that gives a nice simple API to XML, it's available here [progressiv...ishing.com], but the problem is it needs to come with PHP as standard for it to become widely used.

      Phillip.
  • I haven't used PHP much in some time, but I remember it using GD years ago - what exactly was added in that regard?
    • On Windows, libgd was installed by default, but on *NIX and other platforms, you had to install all the libraries to support GD, and then install GD, and then configure PHP for GD support. With 1.6, 1.8 and 2.0 versions, many things did not work properly between all these versions on *NIX systems, compared to Windows PHP. Plus there were some bugs that couldn't be worked out in PHP because they were in the GD code.

      To make it more compatible cross-platform, get a unified libgd version to use, and add functions not normally found and fix bugs, PHP has added GD as a bundled extension. This is a good thing.

  • Student suspended over suspected use of PHP (Score:5, Funny)

    by happypizzaguy ( 325415 ) on Friday December 27, 2002 @03:40PM (#4968576)
    I thought this [bbspot.com] might apply here. Hypertext preprocessors are pretty dangerous. Everyone use 4.3.0 with caution.

  • consider running an opcode cache (Score:4, Informative)

    by Kunta Kinte ( 323399 ) on Friday December 27, 2002 @03:42PM (#4968581) Journal
    Most server side scripting engines nowadays employ opcode caching. Code is compiled the first time executed, but run from memory the rest of the time.

    This is different from HTML output caching.

    Opcode caching is said to increase performance by 30-200% depending on the cache code you use and your app.

    With about 30% of apache installs running PHP, and with more than 50% of the web running apache, I'm surprise the PHP does not include an opcode cache with the install.

    That's a lot of wasted cpu cycles :) Just compiling PHP scripts on every page hit.

    There are open source caches out there, see the link in my sig.

    • Re:consider running an opcode cache (Score:4, Interesting)

      by MmmmAqua ( 613624 ) on Friday December 27, 2002 @04:05PM (#4968710)
      Why no official PHP Opcode cache [weblogs.com]? 30-200% performance gain

      Simply asked, simply answered: there is no "official" PHP opcode caching because PHP relies on the Zend engine and the PHP developers work very closely with the people at Zend, who sell the Zend Performance Suite [zend.com] (formerly Zend Accelerator), and the guys at PHP are not about to cut into Zend's livelihood by bundling a product with PHP which makes the Zend product redundant.
      • Simply asked, simply answered: there is no "official" PHP opcode caching because PHP relies on the Zend engine and the PHP developers work very closely with the people at Zend, who sell the Zend Performance Suite

        That's the main answer I'm hearing. But zend is very expensive.

        Maybe there's a compromise. How about a modest PHP opcode cache that has only some of zend's features; ie. a little bit slower and more conservative than zends.

        I appreciate the work the zend guys have done, trust me I do. But that's an important feature to leave out.

    • Just compiling PHP scripts on every page hit.

      Ok, lets see, in the same thread there is a post about PHP not having an XML parser of any kind (the author mentions having to use regexp, insane as that sounds), I am assuming that means there is no HTML parser (or an equivalent of HTML::TreeBuilder at that) either.

      Call this "informative-flame" bait, but I am trying to figure out why people get upset when PHP isn't refered to as the greatest thing of all time. I personally haven't used it for a couple of years, so I don't know about many of these features.

      What does PHP use in terms of a browser agent (a la LWP)? Is there really no support simple filebased db persistence? (by which I mean something along the lines of tieing a hash to BerkleyDB). How well does it hook into the other stages of the Apache request handling pipeline?

      Oh and something I'm curious about (too lazy to look it up, I guess) what sort of exception handling does PHP have (ie it's equivalent of 'try {} catch {} finally {}')?

      What sort of logging modules are available? (log4PHP?) I'd also be curious to know about how PHP's templating systems measure up, from someone who's had experience with this sort of thing...

      Anyway, this is a troll, but I am curious about the answers to those.

      • "Ok, lets see, in the same thread there is a post about PHP not having an XML parser of any kind (the author mentions having to use regexp, insane as that sounds), I am assuming that means there is no HTML parser (or an equivalent of HTML::TreeBuilder at that) either.'

        PHP has both SAX and DOM based XML parsers. It also has an xmltree function to instantly build you an object hierarchy from an XML document. There is also the most excellent phpxpath object available here [sourceforge.net]

        "What does PHP use in terms of a browser agent (a la LWP)?"

        It supports fetching from URLs the same way as opening and fetching from files. The new version also has streams. Also it has hooks into CURL for more sophisticated stuff. There is also the excellent snoopy [sourceforge.net] object.

        "Is there really no support simple filebased db persistence? (by which I mean something along the lines of tieing a hash to BerkleyDB)"

        There are hooks into berkley db if you want to sink to that level. If you want to sink even lower then any php variable, array or object can be turned into a string and saved to files or sent to other URLs or what have you.

        "How well does it hook into the other stages of the Apache request handling pipeline?"

        You don't have that much control over the pipeline but you can hook into auth and such. I never needed anything it did not provide.

        "Oh and something I'm curious about (too lazy to look it up, I guess) what sort of exception handling does PHP have (ie it's equivalent of 'try {} catch {} finally {}')?"

        PEAR has a pretty good error handling library. Otherwise you basically just test for errors manually. You call a function with @function which surpresses error messages but sets global error indicators which you can test for. Not great but gets the job done. Version five will have try catch. All in all error handling in php is better then perl and worse then java.

        "What sort of logging modules are available? (log4PHP?)"

        PEAR has a logging class. I know that there are others out there as well. PHP also hooks into syslog if you want that.

        " I'd also be curious to know about how PHP's templating systems measure up, from someone who's had experience with this sort of thing..."

        smarty [php.net] is an outstanding templating engine with caching. I don't see how you could possibly do better. There are numerous others.

        I hope this prevents you from further trolling. Now that you are armed with actual knowledge (which you could have gotten by simple searching) you no longer need to troll here.

        • Thank you, very informative. And why would I want to search for all this myself when I could just ask knowledgeable people and quickly get a summary of all I wanted to know? :)

          All in all error handling in php is better then perl and worse then java.

          This I find hard to believe, the only advantage java has over perl in this regard is checked exceptions (and certainly enough arguing has taken place over whether or not this is actually a good thing). So PHP adds a feature over and above perl's Error.pm which insn't quite as good as checked exceptions but enought to make it better?

          Anyway, thanks for the answers, this was a very useful troll.

          • "So PHP adds a feature over and above perl's Error.pm which insn't quite as good as checked exceptions but enought to make it better?"

            It's not just that. There is a lot to php error handling. You just have to learn about it and use it to your advantage. I personally think try catch is not that great and in some ways would prefer the existing php error system. A stack trace would be cool thought.
  • Is better documentation. Like most CS students I got started with Java. The Javadocs are incredibly easy to read and learn Java from. The PHP docs are anything but easy to read by comparison. Thus far, the only PHP I've learned is from books and source code (it's pretty easy to pick out what most PHP functions do from source examples). Python suffers from a similar problem IMO. I've been trying to get started with a bit of XML parsing and tried Python first. It was a pain in the ass to figure out what classes were being returned by functions among other things.

    I think OSS projects working on languages and libraries should commit to including comments like this to help newbies (especially if the language is dynamically typed) /*
    function name:
    input parameters:
    return type:
    purpose:
    parameter 1: (purpose)
    parameter 2: (purpose)
    */
    • I can't believe you're saying this.
      The PHP docs are brilliant.
      You just type in the function name, and there are enough examples to get you running until you actually start understanding the language.

      I learnt PHP purely from www.uk.php.net, and I have always found the Java and Perl docs to have too much stuff in them.

      The PHP docs are like this:
      mysql_connect ([hostname],[username],[password]) Returns true if successful.
      What more do you need to know? What goes into a function, what comes out.

      I'm genuinely not trolling here, I'm just surprised that anyone could moan about the PHP docs.
    • This is on the TODO but all the information is included on every man page currently. New parameters and changes to parameters are in the form of notes on each given doc page. So all the information you ask for is already available, just not in a consistant form. Yet. This is a big job, would you like to help? :)
    • The docs work pretty well for me.

      Tip: To get the most out of the documentation, you really need to use the online version. You can query it quite easily from your browser simply by typing php.net/ThingYouWantToKnowAbout into your location window. It'll pull up a function name, list of function names that closely match your search term, or a list of pages containing the search term. Try something like php.net/integers (returns a list of 52 documents, most of which relate to integers in one way or another) or php.net/file (returns the manual page for the file() function) and you'll see what I mean. Also check the user-contributed notes. I've found a lot of good tips and hacks in those.
  • This is fine and dandy and all.. but for all of us Ensim users.. we are still stuck on outdated PHP and apache.. Ensim still relies on their own versions oh PHP and Apache.. THIS SUX..

    *now watch the flames from under me* hehe
  • From the announcement:

    GD library is now bundled with the distribution and it is recommended to always use the bundled version

    Why recommend the use of their bundled library? Why is this any different from their MySQL support (IE, a "mini" bundled MySQL library is included, but can (and should be) overridden by the normal MySQL libraries if they exist on the system). I can understand that many machines don't have GD libraries, but why "recommend" that their own code be used as opposed to the system libraries if available?

  • As with all PHP .0 releases, be wary about installing this release on production servers, even though this release has gone through a lot more testing than usual. I know of at least a few annoying bugs which were not fixed before the 4.3.0 release, such as a memory leak in a string handling function, and the fact that all PHP error messages are output to the global Apache error log even if they're only supposed to be displayed on the page itself.
    Also, I noticed that if you have older PHP3 classes lying around which mistakenly redeclare a function, the entire script which uses the class will now fail under 4.3.0, where it would not trigger an error under previous versions. This is not a bug, but beware of it since it could break older applications.
  • is that you need to get the Zend Performance suite, or at least the Code Accellerator, if you want the best performance from your scripts. Spend the bucks, then your code will run 15-20 times faster. [zend.com]


    I'm surprised more people haven't mentioned this.

  • ./configure results in ...

    checking for cURL 7.9.8 or greater... configure: error: cURL version 7.9.8 or later is required to compile php with cURL support

    yet ...

    [root@server php4]# curl -V
    curl 7.10.2 (i686-pc-linux-gnu) libcurl/7.10.2 OpenSSL/0.9.6b zlib/1.1.3

    Anyone else having the same problem?
  • So am I missing something? The early releases of 4.3.0 talked about passing objects by reference, static/private members, etc. Did this get pulled and moved back to 5.0?

    - Scott

Slashdot Top Deals

"The great question... which I have not been able to answer... is, `What does woman want?'" -- Sigmund Freud

Close