Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Softpanorama Search

PHP as Visual Basic of the Web

Old News ;-)

Recommended Links

Books

PHP on AIX

 Recommended Papers

Tutorials and Sample Chapters
Reference

FAQs

DB Scripting

MySQL

 ACID

Cooltools

Command line PHP LAMP History and philosophy Debugging Critique Humor

PHP is dominant language for web applications and system administrators need to know a little bit about it although is comparison with Perl it might look like a disappointment.

Linux comes with PHP usually preinstalled as default. While Sun does not directly support PHP as part of Solaris PHP 5 now can be obtained prepackaged in Cooltools  with Apache and MySQL. 

PHP was a real break-through in WEB site scripting. But the type of break-through was different then break-through that Perl made. PHP is a Visual Basic of the WEB. Simpler and in many respects uglier language then Perl (similar to Basic vs. Algol story), it outpaced Perl in WEB pages scripting because it pioneered higher level of integration with web server (Apache) and database (MySQL). Life is too short and it's silly to spend it on solving configuration problems ;-). Higher level tools for Web environment that are more productive than classic Unix scripting languages, were long overdue. Like Basic, PHP does not break any new ground in language design and its success might be more due to allergy to the overcomplexity of Perl that its own merits.

There was always a need for simple, entry-level language for such a popular domain as web scripting. VBscript did a decent job in Windows environment, but was not an answer for Unix.  Java was (and still is despite popularity of JavaServer Pages (JSP))  a low level language, technology that for the Web development is more the part of the problem, then part of the solution :-).

The appeal of PHP is its specialization for Web-server-database environment (typically in Apache+MySQL combination). It is this combination that gave PHP its momentum as its proved to be a very powerful and versatile platform form wide class of applications. 

Like Basic was severely simplified Algol, PHP is severely simplified (or if you wish dampened down)  Perl.  The absence of language design skills was evident in the first versions of the language so the success was not due to design but despite of it.  PHP4 was the most ugliest, brain-dead designs of any popular language I encountered.  For example PHP5 came with exception handling like that found in most mature object oriented languages, but the problem is that most PHP functions do not use exceptions, they simply return false. In my experience the people writing PHP usually don't have a CS background. They don't care (and most don't even know) about namespaces, or 64 integers. They are stick with the subset close to php 4.

In a fundamental, conputer science view, yes PHP is a horrible mess. But as an entry level scripting language it proved to be OK.

PHP's simplicity makes it perfectly suitable for entry-level programmers, such as WEB developers moving up from a pure HTML. But the simplicity is a double edge sword. For more experienced developers it might slow down the development process. I saw many complex applications written in PHP (Acid/Base is one such example) in which the author definitely outgrow the level of the language and PHP4 became more of a liability then help.  It's too verbose, it's too ugly, its too limiting.

In this sense, PHP might be one of the few languages were "familiarity breeds contempt".   PHP has an advantage that you can slowly add in some PHP code to existing html page, and just change the file extension from .html to .PHP. You can do the same with server side includes and Perl but this requires slightly higher qualification. PHP's great advantage is that it does so much out of the box. You want sessions, you've got it. It's built right in. You want to send mail and you have mail function. Most programmers wants to get on with creating the site not with installing modules ;-).

That why PHP proved to be an indispensable part of a very troika of application, essentially a new platform for application development. It is often called LAMP with P standing for Perl Python or PHP, but in reality PHP is the most popular among all three "P" languages mentioned above). This platform proved to be suitable for solving an extremely wide range of tasks in a WEB-enabled environment, far beyond home pages for which PHP was initially designed.  That's why PHP managed to successfully depose already entrenched Perl in this particular area. It is  seamless integration with MySQL database and Apache WEB-server that really made PHP an important pioneer in the scripting language world.

PHP is still evolving and PHP 5.3 looks more satisfactory that previous versions from the programmer point of view.

Implementation also improved. To say the truth in earlier versions (before version 5.3) PHP has pretty much a junk implementation: no support for pipes, no support for exceptions, no standard debugger, bad control of namespace, zillion built-in functions with some that have been defined extremely unprofessionally, in a worst  amateurish semantic possible. They also now replaced old and ugly POSIX regex with Perl regex.

See  Zend in the clowns kuro5hin.org

But nothing succeed like success and  PHP 5 partially overcame those deficiencies, but there is no free lunch and the cost is breaking compatibility wit PHP 4.  The key difference is the semantic of the assignment statement.

Still let's not forget that Wikipedia, WordPress and several other important and complex projects are written ion PHP. To add insult to injury Wikipedia was initially written in Perl ;-).

Dr. Nikolai Bezroukov

Notes:
  • This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected.
  • The site contain some broken links as it develops like a living tree... Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link.
Google Search
Open directory
Research Index

Old News ;-)

Note:  "IBM developerWorks has put together a PHP recommended reading list. It provides resources for developers and admins adopting PHP and tackling advanced topics such as building extensions and writing secure code. There's also a list of books and blogs for keeping up with changes to the language itself."  Oracle PHP page  is also quite useful.

Slashdot PHP 6 and What to Expect

Lack of backwards compatibility (Score:5, Interesting)

by kestasjk (933987) on Tuesday March 14 2006, @04:02AM (#14914278) Homepage

phpBB, vBulletin, mysqladmin, postnuke, phpDiplomacy [kuliukas.com] (shameless self promotion), etc, etc; none will work until they've been ported to the new PHP5 OO model, and once they've been ported they won't work on PHP4.

They should leave in backwards compatibility for the class based OO model which <PHP5 uses. Once they bring out PHP6, PHP5 will be the only version which runs new and legacy PHP scripts, so PHP5 will clearly become the standard for a long time.

I'm a big fan of PHP, but with so many apps (e.g. my university's timetabling app) still in PHP3, all the rest in PHP4, both becoming obsolete, changes to the API, even changes to what's allowed within the same version [phpbb.com]; I'm starting to wonder if I should have focused on a more stable language like python or perl instead.

Namespace (Score:4, Insightful)

by CHaN_316 (696929) on Tuesday March 14 2006, @03:28AM (#14914192)

It'd be great if variables, functions, classes, and constants could be defined in their own namespaces. For really big projects, it's too easy for names to collide in the global namespace. An annoying workaround has always been to make names unique by prepending them with something.

 

What's new in PHP V5.3, Part 5 Upgrading from PHP V5.2

24 Feb 2009

Syntax changes

Additions to the language, with namespaces and closures (discussed in Part 2 and Part 3), have added more reserved words. Starting in PHP V5.3, namespace can no longer be used as an identifier. The closure class is now a reserved class, but it is still a valid identifier. Listing 1 shows examples of statements that no longer work in PHP V5.3 because of the additional reserved words.


Listing 1. Invalid PHP statements
 
// the function definition below will throw a fatal error in PHP 5.3, but is perfectly 
// valid in 5.2
function namespace() 
{
....
}

// same with this class definition
class Closure
{
....
}

Support for the goto statement was also added in PHP V5.3. Now goto is a reserved word. goto statements are not common in modern languages (you might remember using them in BASIC), but there are occasionally use cases where they are handy. Listing 2 has an example of how they work.

Listing 2. goto statements in PHP
 

echo "This text will get outputted";
goto a;

echo "This text will get skipped";

a:
echo "This text will get outputted";

One possible use case for gotos is for breaking out of deeply nested loops and if statements. This will make the code much clearer to read.
 

Changes to functions and methods

Though there are no major changes to functions and methods in PHP V5.3, there are a few enhancements to help with outstanding issues in PHP and to improve performance. This section discusses a few of the more notable changes.

In previous versions of PHP, the array functions atsort, natcasesort, usort, uasort, uksort, array_flip, and array_unique let you pass objects instead of arrays as parameters. The functions then treat the properties of the objects as the array keys and values. This is no longer available in PHP V5.3, so you need to cast the objects to arrays first. Listing 3 shows how to change your code.

Listing 3. Changing code to cast objects to arrays for certain functions
 
$obj = new stdClass;
$obj->a = '1';
$obj->b = '2';
$obj->c = '3';

print_r(array_flip($obj)); // will NOT work in PHP 5.3, but will in PHP 5.2

print_r(array_flip((array) $obj)); // will work in PHP 5.3 and 5.2

The magic class methods are now much more strictly enforced. The following methods must have public visibility:

You can use the new __callStatic() magic method in cases where __call was used in a static context as a workaround for this change. The required arguments for these methods are enforced and must be present with the exception of the __isString() magic method, which accepts no parameters. Listing 4 shows how to use these methods and the required parameters for them.

Listing 4. Using the magic methods
 
class Foo
{
    public function __get($key) {} // must be public and have one parameter
    public function __set($key,$val) {} // must be public and have two parameters

    public function __toString() {} must be public and have no parameters
}

Several functions that previously were not supported on PHP with Windows are now supported in PHP V5.3. For example, the getopt() function is designed to parse the options for calling a PHP script from the command line. inet_ntop() and inet_pton(), the functions for encoding and decoding Internet addresses, now work under Windows® as well. There are several math functions, such as asinh(), acosh(), atanh(), log1p(), and expm1(), which now have Windows support.
 

Extension changes

The PHP Extension C Library (PECL), has been the breeding ground for new extensions in PHP. Once an extension is mature and stable and is viewed as a useful function for part of the core distribution, it is often added during major version changes. In this spirit, starting in PHP V5.3, the following extensions are part of the core PHP distribution.

FileInfo
Provides functions that help detect the content type and encoding of a file by looking at certain magic byte character sequences in the file.
intl
A wrapper for the International Components for Unicode (ICU) library, providing functions for unicode and globalization support.
Phar
A PHP archiving tool discussed in Part 4.
mysqlnd
A native PHP driver for MySQL database access that's a replacement for the earlier MySQL and MySQLi extension which leveraged the libmysql library.
SQLite3
A library for using SQLite V3 databases.

When an extension is no longer actively maintained, or is deemed unworthy of distribution with the core PHP distribution, it is often moved to PECL. As part of the shuffling in PHP V5.3, the following extensions have been removed from the core PHP distribution and are maintained as part of PECL.

ncurses
An emulation of curses, which is used to display graphical output on the command line.
fpdf
Handles building and using forms and form data within PDF documents.
dbase
Provides support for reading and writing dbase compatible files.
fbsql
Supports database access for Frontbase database servers.
ming
An open source library that allows you to create Flash 4 animations.

The Sybase extension has been removed entirely and is superseded by the sybase_ct extension. The sybase_ct extension is fully compatible with the former and should be a drop-in replacement. The newer function will use the Sybase client libraries you need to install on your Web server.

Build changes

With the strong focus on refining the build process in PHP V5.3, it's easier to build PHP on all platforms. To maintain consistency between PHP builds and to provide a guaranteed set of components in PHP, the PCRE, Reflection, and SPL extensions can no longer be disabled in the build. You can build distributable PHP applications that use these extensions and are guaranteed that they will be available for use.

A new team took over the PHP Windows build in the last year. Starting in PHP V5.3, the team will provide several improvements for users on Windows. The new builds will target the 586 architecture (Intel® Pentium® or later) and will require Windows 2000/XP or later, removing support for Windows 98/NT and earlier. PHP builds built with Microsoft® Visual Studio® 2008 and builds targeting the x86-64 architecture will be built. They offer improved performance when working with FastCGI on the Microsoft IIS Web server or with Apache built with the same compiler and architecture. The Windows installer is also being improved to better configure PHP with the Microsoft IIS Web server. The team launched a Web site specific to PHP on Windows (see Resources).

.ini changes

An important feature of PHP is that its behavior can be configured using an .ini file. In PHP V5.3, several problematic directives for this file have been removed, such as the zend.ze1_compatibility_mode setting. You now have tremendously improved flexibility when using this file.

There are two major improvements to the php.ini file:

You can also have these .ini directives created in user-specified .ini files, located in the file system itself, in the same way that .htaccess files work under the Apache HTTP Web server. The default name for this file is specified by the user_ini.filename directive. The feature can be disabled by setting this directive to an empty value. Any per-site and per-directory directives cannot be overridden in a user-specified .ini file.

Deprecated items

PHP V5.3 starts officially deprecating older functions that will no longer be available in future versions of PHP. When you use these functions, an E_DEPRECATED error will be emitted. The following functions are deprecated for PHP V5.3:

It is recommended that you migrate away from these features with PHP V5.3. Future major PHP releases will drop support for the above items.

Summary

PHP V5.3 has numerous new features and has "cleaned up" several items. There are some backward-compatibility issues. This article provides some guidance for migrating your Web application to work with PHP V5.3. For the latest details regarding PHP V5.3 see the PHP wiki, which has notes on any other changes that might affect your applications.
 

Resources

Learn
 

Get products and technologies
 

[Jul 3, 2008] Debugging PHP using Eclipse and PDT

The PHP Development Tools (PDT) plug-in, when installed with Eclipse Europa, gives you that ability to quickly write and debug PHP scripts and pages. PDT supports two debugging tools: XDebug and the Zend Debugger. Learn how to configure PDT for debugging PHP scripts and discover which perspectives you use when taking closer looks at your scripts.

In this tutorial

This tutorial demonstrates how to configure the PHP Development Tools (PDT) plug-in for Eclipse to debug your PHP scripts. It also introduces the perspectives you'll use (namely, PHP Debug) when taking closer looks at your PHP scripts.

After completing this tutorial, you'll be able to set up either XDebug — an open source project that allows you to debug executable scripts and scripts running on a Web server — or the Zend Debugger in Eclipse using the PDT project to develop PHP applications. You'll understand the various parts of the PDT project's PHP Debug perspective and learn how to set up, view, and work with breakpoints. You also learn how to inspect the values of variables as you are stepping through the code, as well as how to debug PHP Web applications on your local server so you can run through your PHP Web application with the debugger.

Prerequisites

To get the most out of this tutorial, you should have done a bit of PHP development. But what matters more is that you've done software development in general. You'll understand the debugging concepts better if you're familiar with debugging any other language. I wrote this to be helpful to those who are fairly new to Eclipse, rather than to those who have been using Eclipse for a while.

System requirements

To complete this tutorial, you need:

Computer running Microsoft® Windows®, Mac OS X, or Linux®
The examples of the php.ini file shown in this tutorial are for Mac OS X and Linux. Because both debuggers require a configuration that tells PHP where the debugger extensions are located, the only noticeable difference — if you're looking for Windows examples — is the path to the debugger extension. Library names end in .so. for Mac OS X and Linux and .dll for Windows; also, paths use a forward slash (/) instead of a backslash (\) as a directory-separator character.
PHP V5.x
Linux users can install PHP using the software package system included in their distribution. OS X, and Windows users can find PHP V5.x at PHP.net.

Note: The examples in this tutorial were written using PHP V5.2.5.

Eclipse V3.3
Again, Linux users have it easy: Eclipse is usually available through the package system included in their distribution. Everyone else can find the Eclipse integrated development environment (IDE) at the Eclipse downloads.
Apache or Microsoft Internet Information Services (IIS) for serving Web applications
You need a Web server installed to run the examples that demonstrate how to debug PHP Web pages on the server. However, if you're interested only in debugging PHP scripts that aren't Web pages, you won't need a Web server. For this tutorial, we have Apache V2 set up as the Web server. If you're using Windows and would rather use IIS, that works, too. This tutorial assumes you have the proper access to write to directories inside the document root of the Web server.
Eclipse PHP Development Tools framework
If you don't already have PHP Development Tools (PDT) installed, you may want to read ahead to the "Overview of the PDT project" section so you can decide whether you want to download and install PDT already bundled with the Zend Debugger. The Eclipse Foundation PDT/Installation wiki is brief, but helpful.
Zend Studio Web Debugger
Download a 30-day trial version of the Zend Studio Web Debugger.

[Jun 20, 2008] BitRock Download Web Stacks

BitRock Web Stacks provide you with the easiest way to install and run the LAMP platform in a variety of Linux distributions. BitRock Web Stacks are free to download and use under the terms of the Apache License 2.0. To learn more about our licensing policies, click here.

You can find up-to-date WAMP, LAMP and MAMP stacks at the BitNami open source website. In addition to those, you will find freely available application stacks for popular open source software such as Joomla!, Drupal, Mediawiki and Roller. Just like BitRock Web Stacks, they include everything you need to run the software and come packaged in a fast, easy to use installer.

BitRock Web Stacks contain several open source tools and libraries. Please be sure that you read and comply with all of the applicable licenses. If you are a MySQL Network subscriber (or would like to purchase a subscription) and want to use a version of LAMPStack that contains the MySQL Certified binaries, please send an email to sales@bitrock.com.

For further information, including supported platforms, component versions, documentation, and support, please visit our solutions section.

[May 6, 2008] Ortro 1.3.0  by Luca Corbo

PHP based

About: Ortro is a framework for enterprise scheduling and monitoring. It allows you to easily assemble jobs to perform workflows and run existing scripts on remote hosts in a secure way using ssh. It also tests your Web applications, creates simple reports using queries from databases (in HTML, text, CSV, or XLS), emails them, and sends notifications of job results using email, SMS, Tibco Rvd, Tivoli postemsg, or Jabber.

Changes: Key features such as auto-discovery of hosts and import/export tools are now available. The telnet plugin was improved and the mail plugin was updated. The PEAR libraries were updated.

Oracle PHP Developer Center

Installation Guides

Installing Oracle Database 10g Express Edition and Zend Core for Oracle

Installing Apache, PHP, JDeveloper, and the PHP Extension on Linux

Installing PHP and the Oracle 10g Instant Client for Linux and Windows

Installing Oracle, PHP, and Apache on Linux

Installing Oracle, PHP, and Apache on Windows 2000/XP

Set Up Oracle Database 10g and PHP on Mac OS X OTN Installfest Scripts (.txt format):
  ·Zend Core for Oracle, Apache, PHP5, Oracle JDeveloper 10.1.2, and JDeveloper PHP Extension on RHEL4
  · Oracle 10g Release 2, Apache, and PHP5 on RHEL4
  · Oracle 10g, Apache, PHP4, and Oracle JDeveloper/PHP Extension on RHEL4
  · Oracle 10g, Apache, PHP5, and Oracle JDeveloper/PHP Extension on RHEL4
  · Oracle 10g, Apache, PHP4, and Oracle JDeveloper/PHP Extension on SLES9
  · Oracle 10g, Apache, PHP5, and Oracle JDeveloper/PHP Extension on SLES9
 

Oracle Develop 2007 - PHP Presentations
  Scale Your PHP Application to Tens of Thousands of Connections
  The Way to the Web with PHP and Oracle Database

 
Recent Oracle+PHP Cookbook Recipes
  Creating an Ajax Process Using PHP
  Building a Locator with ZIP Data
  Creating Oracle-Powered SOAP Services in PHP
  Online PayPal Payments with PHP
  Adding Google-like Search Operators to Simple Search Boxes
  Read More Recipes... | Read other Tech Articles...
 

 
Sample Book Chapters
  Oracle Database 10g Express Edition PHP Web Programming from Oracle Press
  Learning PHP5 from O'Reilly & Associates
  PHP Cookbook from O'Reilly & Associates
  PHP Programming from O'Reilly & Associates

IBM Redbooks Bringing PHP to Your IBM eServer iSeries Server

29 January 2003 | IBM

Programming with PHP on the iSeries server
Prerequisites
Installation instructions
Compiling (make)
Testing PHP
Configuring HTTP Server (powered by Apache) to use PHP
Creating a sample database
Limitations
PHP 4.2.2 errata

[Apr 18, 2008] IBM Redbooks Developing PHP Applications for IBM Data Servers

Chapter 1. Technology overview
Chapter 2. Sample scenario description
Chapter 3. Zend installation and configuration
Chapter 4. PHP application development with DB2
Chapter 5. PHP applications with Informix database servers
Chapter 6. Port PHP applications from MySQL V5 to DB2 UDB V8.2
Appendix A. An introduction to Service Data Objects for PHP

[Mar 12, 2008] Tiny Eclipse 3.3.2  by Eric Suen

About: Tiny Eclipse is distribution of Eclipse for development with dynamic languages for the Web, such as JSP, PHP, Ruby, TCL, and Web Services. It features a small download size, the ability to choose the features you want to install, and GUI installers for Win32 and Linux GTK x86.

[Dec 1, 2007] freshmeat.net Project details for PHD Help Desk

PHD Help Desk is software conceived for the registry and follow-up of help desks incidents. Registry of incidents allows classification in two levels (type and subtype), the state of the incident, a description, ticket assignment and priority, historical registry, and an audit. Information can be reported in consultation format, to give reports or export the information for later processing in a database or spreadsheet.

Release focus: Minor feature enhancements

Changes:
Now it's possible attach a file in the users support request web form. Minors changes were made. In the code for modifying a ticket, an SQL statement that was incompatible with MySQL 3.23 was fixed. When you had one ticket opened for modification in one window and then you modified another ticket in another window, the change would incorrectly modify the first ticket although it would show information about the second ticket. PHD now warns you about this situation and prevents the change. All scripts now correctly start with "<?PHP".

[Jul 16, 2007] Zend Developer Zone PHP 101 PHP For the Absolute Beginner

PHP 101 (part 1): Down the Rabbit Hole [July 17, 2004]
An introduction to PHP’s variables and operators.

PHP 101 (part 2): Calling All Operators [July 18, 2004]
The rest of the PHP operators (there are many), and simple form processing.

PHP 101 (PART 3): Looping the Loop [July 19, 2004]
Basic control structures explained.

PHP 101 (PART 4): The Food Factor [July 20, 2004]
Arrays, PHP array functions, and what it all means.

PHP 101 (PART 5): Rank and File [July 21, 2004]
Everything you’re ever likely to need to know about dealing with external files from a PHP script.

PHP 101 (PART 6): Functionally Yours [July 28, 2004]
All about functions, arguments, passing by reference, globals and scope.

PHP 101 (PART 7): The Bear Necessities [August 07, 2004]
A gentle introduction to object oriented programming in PHP 4 and PHP 5.

PHP 101 (PART 8): Databases and Other Animals [August 31, 2004]
All about connecting to a MySQL database from PHP, using the mysql or mysqli extensions.

PHP 101 (PART 9): SQLite My Fire! [September 16, 2004]
Introducing another database: SQLite.

PHP 101 (part 10): A Session In The Cookie Jar [October 3, 2004]
Sessions and cookies – how to keep track of visitors to your site.

Creating a Code Search Engine with PHP and MySQL

I'm just a few days away from launching a comprehensive support website for my book, "Beginning PHP and MySQL 5, Second Edition", and among other features, have built a search engine for sifting through the more than 500 code snippets found throughout the book. This was an interesting exercise because it involves a number of storing a fairly significant amount of text within a MySQL database, using MySQL's full-text search facility, and devising an effective way to extract and display the code in the browser.

In this article I'll offer a simplified version of this search engine, introducing you to some compelling PHP and MySQL features along the way. You might adopt what you learn towards building your own search engine, or towards other applications.

The Database Schema

Just a single table is required for the engine's operation. The table, code, serves as the code repository. Each example is stored along with a suitable title and the chapter number in which it appears. Because the search engine should retrieve examples based on keywords found in the example title or in the code itself, a FULLTEXT index has been added for these columns. Because the table contents will rarely change beyond the occasional bug fix, its backed by the read-optimized MyISAM storage engine. The table follows: 

CREATE TABLE code (
 id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
 title VARCHAR(50) NOT NULL,
 chapter TINYINT UNSIGNED NOT NULL,
 code TEXT NOT NULL,
 FULLTEXT (title,code)
) TYPE = MYISAM;

[Nov 14, 2006] Fantastico -- LAMP application setup for idiots by Steven J. Vaughan-Nichols

Feb. 22, 2006 (Linux-watch.com). Do you want to use PHP-based programs on a hosted Web server, but you don't want to go through the hassle of setting up MySQL, PHP, and Apache so that they're in perfect alignment to run your blog, CMS (content management system), or photo gallery? If that's you, you need to find a Web host that uses Netenberg's Fantastico De Luxe.

This Linux-based program enables Web host companies to offer you a menu of popular PHP-based programs for near-instant installation.

For example, with CMSs alone, Fantastico will let you install the latest editions of: If it's a PHP-based, open-source Web application, chances are Fantastico can install it for you. It's not just for PHP programs, though. Fantastico can also install such programs as PerlDesk, the Web-based commercial help desk program.

Many Web host companies offer Fantastico as a service. I haven't had enough time or experience with them to recommend one over the other. Hosting Review, however, does a decent job of evaluating Web hosting companies and its list of the top eight, because they couldn't find ten, Web hosting businesses that deploy Fantastico is a useful place to start.

When choosing a Fantastico-enabled host, you should make sure the company is using a current version of Fantastico. Older versions abound, and they do not install the latest PHP programs.

You should also keep in mind that Fantastico is not going to get you any kind of fine control over your installation. What it will do, though, is set up the basic LAMP (Linux, Apache, MySQL, PHP) framework for your particular application to work.

This, as any of you who've followed my adventures in setting up Drupal by hand, is not insignificant.

Now, some might say, "Real men do it all by hand." To which, I can only say, "Real men don't have time to do it all by hand sometimes."

That's the situation I faced once I finally got Drupal and my test Web site up and running on my local SUSE 10 system. I decided that I shouldn't tempt BellSouth into shutting down my consumer DSL connection by running a Web site off it. So, my next step was to look for a Web hosting site where I could clone over my test site without having to go through the hassle of reintegrating yet another LAMP stack to work with Drupal.

It was during that search that I ran into Fantastico. And, it was fantastic.

Instead of spending hours working out how to get Drupal running with Red Hat Enterprise Linux 4, as opposed to SUSE Linux 10, MySQL 4.0.25 instead of MySQL 4.1.13, Apache 1.3.34 in place of Apache 2.0.54, and never least, PHP 4.4.1 in place of PHP 4.4.0-6, my system was set up in less than a minute.

Now, you may think that all those slightly different versions really wouldn't have made much of a difference, but you'd be wrong. Those seemingly subtle differences can make your development life miserable.

If I can have a script do all the pain-in-the-rump tweaking work for me, that's just fine in my book.

After all, even after Fantastico does its work, I still have to face such amusements as restoring a MySQL 4.1.13-based database schema to a MySQL 4.0.25 DBMS. They are not, in case you didn't know, automatically compatible.

Make no mistake about it, though. Although Fantastico makes setting up a LAMP application a lot easier, it doesn't completely spare you from all the hard work of getting your LAMP program working properly.

Still, in a hosted environment where your access to system resources are far more limited than they are on your own system, anything that makes the initial setup easier is likely to save you many hours of work. For that reason alone, whenever I set up a Web site on a hosted system in the future, the first thing I'm going to look for is a hosting company that includes Fantastico in its offerings. It's that important.

[Oct 29, 2006] A PHP V5 migration guide by Jack D. Herrington

With the new language features of PHP V5, you can significantly improve your code's maintainability and stability. Learn how to migrate code developed in PHP V4 to V5 while taking advantage of these new features.

PHP V5 is a quantum step up from V4. The new language features make building reliable and maintaining class libraries much easier. In addition, the reworking of the standard libraries helped bring PHP more in line with its cousin Web languages, such as the Java™ programming language. Take a tour through some of PHP's new object-oriented features and learn how to migrate existing PHP V4 code into V5.

First, a bit about the new language features and how PHP's creators have changed the approach to objects from PHP V4. The idea with V5 was to create an industrial-strength language for Web application development. That meant understanding the limitations of PHP V4, then pulling known good language constructs from other languages (such as the Java, C#, C++, Ruby, and Perl languages) and incorporating them into PHP.

The first and most important addition was access protection for methods and instance variables on classes -- the public, protected, and private keywords. This addition allows class designers to retain control over the internals of their classes while expressing to the client of the class what he should or should not touch.

In PHP V4, everything was public. In PHP V5, class designers can say what is externally visible (public) and what is visible only internally to the class (private) or to descendants of the class (protected). Without these access controls, working on code in large groups or distributing code as libraries was hindered because consumers of those classes could easily use the wrong methods or access what should have been private member variables.

Another big addition were the keywords interface and abstract, which allow for contract programming. Contract programming means that one class provides a contract to another -- in other words: "Here is what I will do, and you don't need to know how it's done." Any class that implements that interface agrees to the contract. Any consumer of the interface agrees to use only the methods specified in the interface. The abstract keyword makes using interfaces a lot easier, as I show later.

These primary two features -- access control and contract programming -- allow for much larger teams of coders to work on much larger code bases more smoothly. They also allow IDEs to provide a much richer set of language intelligence features. Although this article covers several migration issues, I also spend a lot of time showing how to use these new key language features.

[Oct 29, 2006] freshmeat.net Project details for doxygen

doxygen 1.5.1
 by Dimitri van Heesch - Sun, Oct 29th 2006 11:00 PDT  

About: Doxygen is a cross-platform, JavaDoc-like documentation system for C++, C, Objective-C, C#, Java, IDL, Python, and PHP. Doxygen can be used to generate an on-line class browser (in HTML) and/or an off-line reference manual (in LaTeX or RTF) from a set of source files. Doxygen can also be configured to extract the code-structure from undocumented source files. This includes dependency graphs, class diagrams and hyperlinked source code. This type of information can be very useful to quickly find your way in large source distributions.

Changes: This release fixes a number of bugs that could cause it to crash under certain conditions or produce invalid output.

[Oct 24, 2006]  Microsoft Hosts Project to Run PHP on .Net

PHP is slow unless you buy an accelerator. Microsoft might change that
Extending its support for scripting and dynamic languages, Microsoft is hosting a project on its CodePlex site to deliver a PHP language compiler for the .Net Framework.

Known as Phalanger, the project reached Version 2.0 Beta 2 on July 30.

The primary goal of the project, released under Microsoft Shared Source Permissive License, is to enable full functionality of existing PHP scripts on .Net without any modification, Microsoft said.

Unlike the original PHP interpreter, Phalanger compiles scripts into MSIL (Microsoft Intermediate Language).

Phalanger offers Web application developers the ability to leverage both the ease-of-use and effectiveness of the PHP language and the power and richness of the .Net platform, the company said.

And the compiler developers can deploy and run existing PHP code on an ASP.Net Web server and develop cross-platform extensions to that code.

Meanwhile, the object model in Phalanger is compatible with PHP 5.0, and it lets developers combine PHP objects with .Net ones.

[Oct 24, 2006] Microsoft's IIS 7 will aid PHP developers' Windows deployments

At the Microsoft Web Developer's Summit, held in Redmond, Wash., last week, Microsoft announced their efforts to improve PHP's stability and performance on the Windows platform.

During a session wherein key Microsoft developers met with a group of PHP-minded Web developers, IIS product unit manager Bill Staples and program manager Mike Volodarsky discussed IIS 7 and their efforts to improve PHP's performance on the Windows platform.

Staples recapped the numerous security-related enhancements poured into IIS 6 in light of the server's notorious track record of high-profile security gaffes, including the likes of Nimda and Code Red. Then, he underscored the effort's success, noting that there has been no need for any critical IIS security patches in more than three years.

The discussion soon moved on to PHP's relationship with the Windows platform. Staples and Volodarsky acknowledged that many PHP developers build applications on Windows -- generally running Apache's Windows port -- but deploy on Linux. They said new features will support developers who wish to take this path. This means inclusion of features long available to Apache, such as URL rewriting, and an open extensibility model to encourage community-driven development.

Staples and Volodarsky also addressed the historical stability issues surrounding running PHP on IIS, due to incompability issues pertinent to IIS' multithreaded environment. Using CGI improves stability, but comes at a cost of significant performance degradation. Volodarsky noted the team's interest in improving on both fronts, mentioning they were exploring a FastCGI-based solution, but nothing concrete has yet come of it.

While it's clear much work remains before IIS and PHP will work efficiently in a production environment, those wishing to simply experiment with running PHP on IIS will be pleased to know the ISAPI configuration process has been greatly simplified. Staples recently published a blog entry highlighting the required steps.

[Oct 24, 2006] The ionCube PHP Accelerator Home

Yahoo! have been testing PHPA for some months whilst exploring PHP caching solutions, and have selected PHPA as a caching solution for PHP projects.

[Sep 25, 2006] Microsoft's IIS 7 will aid PHP developers' Linux deployments

At the Microsoft Web Developer's Summit, held in Redmond, Wash., last week, Microsoft announced their efforts to improve PHP's stability and performance on the Windows platform.

During a session wherein key Microsoft developers met with a group of PHP-minded Web developers, IIS product unit manager Bill Staples and program manager Mike Volodarsky discussed IIS 7 and their efforts to improve PHP's performance on the Windows platform.

Staples recapped the numerous security-related enhancements poured into IIS 6 in light of the server's notorious track record of high-profile security gaffes, including the likes of Nimda and Code Red. Then, he underscored the effort's success, noting that there has been no need for any critical IIS security patches in more than three years.

The discussion soon moved on to PHP's relationship with the Windows platform. Staples and Volodarsky acknowledged that many PHP developers build applications on Windows -- generally running Apache's Windows port -- but deploy on Linux. They said new features will support developers who wish to take this path. This means inclusion of features long available to Apache, such as URL rewriting, and an open extensibility model to encourage community-driven development.

Staples and Volodarsky also addressed the historical stability issues surrounding running PHP on IIS, due to incompability issues pertinent to IIS' multithreaded environment. Using CGI improves stability, but comes at a cost of significant performance degradation. Volodarsky noted the team's interest in improving on both fronts, mentioning they were exploring a FastCGI-based solution, but nothing concrete has yet come of it.

While it's clear much work remains before IIS and PHP will work efficiently in a production environment, those wishing to simply experiment with running PHP on IIS will be pleased to know the ISAPI configuration process has been greatly simplified. Staples recently published a blog entry highlighting the required steps.

[May 17, 2006]  The Idea Basket » Blog Archive » Winning the PHP 5 Framework Wars

The latest stats for PHP market share are in from Nexen.net, and (assuming they’re reasonably accurate) this does not bode well for PHP 5. After nearly two years since PHP 5.0 was released (back in July of 2004), the PHP 5.x series commands a whopping…7.2% of the PHP market. That means that PHP 4.x is still at 92.8% marketshare! Furthermore, according to the Nexen.net survey, only 34.5% of PHP 5 servers are running PHP 5.1.x which contains crucial new features and is a far more solid platform than any of the 5.0.x builds.

[Apr 13, 2006] 2006 April Chovy’s Blog

Interview Question:

If PHP could PHP a PHP page, how much PHP would a PHP page take to PHP a PHP page?

Related Posts

[Feb 1, 2006] AMPS for Solaris 10 AMPS (Apache MySQL PHP SSL) for Solaris 10 by Mel Lester Jr. (meljr@meljr.com) Version: 1.01 January 25, 2006

The strategy is to utilize as much of the Open Source and other free software bundled with Solaris 10 as possible and integrate Apache2, MySQL, PHP and SSL in a environment that can take full advantage of Solaris 10 zones, resource management and highly scaleable, secure System Administration.

[Jan 22, 2006] Slashdot Taking the Sting Out of PHP 5 Programming

bfioca writes "Where are the all-in-one PHP frameworks that make building well-factored and maintainable applications as easy as building simple sites? O'Reilly ONLamp's recent article Simplify PHP Development with WASP shows how to make a simple database-backed site with WASP in just a few lines of code. Other PHP 5 frameworks such as symfony and PRADO have been getting a lot of recent attention as well."

Using a Framework for YOUR applications!?

by Archi87 (946032) on Sunday January 22, @06:42PM (#14534794)
 

If you simply want a site with some 0815 stuff (like a Guestbook, News, Articles, Photogallerie) use PHP-Nuke [phpnuke.org] and try to create you're own template (or ask a friend to do it for free).

If you want to create anything else (like a corporate site with support system [ticketbased], shop [enduser and reseller], productinfo,... or a browserbased) do it yourself or have a company done it ;-)

And if you really want to stick to a framework - create your own framework :D

Anonymous Coward on Sunday January 22, @05:59PM (#14534612)

Give me a break, depending on such things is terribly bad for maintainable code. Exactly the opposite of the billing given above. Will code written with it be compatible with PHP 6? How long after PHP 6's release will such tools be made compatible? If you need tools to simplify php coding, you might as well just forget it.

If you want a quality product, there are no shortcuts. There is no such thing as a free lunch.

A big thumbsdown on this kind of crap. "Sting" to PHP 5 programming? Get real.
 

Re:Bogus

(Score:4, Insightful)

by afd8856 (700296) on Sunday January 22, @06:20PM (#14534702)

You are either ignorant to what a real open source framework would represent (limit code reinvention, benefit from community effort, etc) or are not in the target group of such a framework (maybe you work for a big company that has a large programming team, who knows).
Either way, I can tell you that, from my personal experience, learning and adopting a framework in your work can have a lot of benefits, for me, as a small custom business solutions provider.
 

Missing the point!

(Score:1, Insightful)

by Anonymous Coward on Sunday January 22, @07:12PM (#14534936)

By demonstrating that it is possible to create and use complicated, "enterprise-class" frameworks effectively in PHP 5, WASP will help more developers make the switch.

Complicated? I didn't realize that complicated frameworks were the pinnacle of modern software development. Here's a newsflash: PHP is popular not because of its rigid structure, nor the availability of misguided "frameworks", but because it allows people to solve problems in a flexible way with little overhead. Yes, a lot of people take it too far in this direction and turn their code into a disaster area, but others manage to build maintainable, useful apps without obsessing over whether or not their program fits into a particular "model". In addition, future maintainers of these apps won't have to read manuals about how to use the framework of the day to make changes. Strict interpretations of pseudo-standards or the use of mind-bending frameworks do not help to develop applications faster, or even better.

I wonder how many "enterprise-class" applications fall flat on their faces because the frameworks on which they are built are not flexible enough to support what their users really need. I know it's happened where I work, and the answer "oh, the framework doesn't support that" led to the success of other projects that came out of nowhere and took hold because they met the demands of users as opposed to the technical demands of project managers. In the real world, a simple PHP app may very well push an "enterprise-class" and "three-tier" monolith out of its way if it does what the users want.

I also rolled my own farmework and...

by AnthongRedbeard (948052) on Sunday January 22, @08:05PM (#14535166)

I have my own framework I've used for several years now and slowly upgraded. I enjoyed writing it because it forced me to learn the principles of what all the other frameworks were doing. I couldn't understand why people wrote frameworks the way they did until I ran into the same situation. However, I made some significant apps with my framework that companies are using and I found myself writing lots of documentation on them and brushing up the comments... It would have been great if I used published and documented framework just so I wouldn't have to do the tedious stuff for other people to ever maintain it.
 

a framework is NOT a shortcut (or a CMS!)

(Score:4, Insightful)

by webwright (910240) on Sunday January 22, @08:17PM (#14535222)

I tear my eyes out everytime someone calls a framework a "shortcut". Usually they follow it by "There's no substitute for good coders writing good code." The business reality is that most coders are not exceptional, and some are pretty lousy. You can spend all of your budget on human resources finding epic-quality coders (and then scratch some more to come up with their epic-salaries) or you can do what the rest of the world does-- get the best programmers they can find and afford. A framework helps un-exceptional coders write better (and more consistent/maintainable) code. This arguments seems akin to saying "forget word processors! Just get someone who can make Vi or Emacs dance and turn 'em loose." It seems to me that the evolution of software is pretty much the act of layering increasingly-smart frameworks on top of machine language to allow high quality results more accessible to more people.
 

Stupid article, obfuscated and biased examples.

(Score:1, Interesting)

by Anonymous Coward on Sunday January 22, @08:31PM (#14535288)

This article appears to be written for fools. One of the author's examples of WASP's superiority is that this:

<li flexy:foreach="arTasks,key,task">{task[Name]} - <i>{task[Due]}</i></li>

is better than this:

  <?php
        $arTasks = array();
        foreach ($arTasks as $key => $task)
        {
  ?>
                <li><?php echo $task['Name']; ?> - <i><?php echo $task['Due']; ?></i></li>
  <?php
        }
  ?>

Because "Already you can see one of the biggest benefits of working with WASP: no need for embedded PHP code."

Well, it might look that way, because he deliberately coded the PHP version in the messiest way possible. He could have simply done this:

<? foreach ($arTasks as $key=>$task) { echo '<li>' . $task['Name'] . '-<i>' . $task['Due'] . '</i></li>'; } ?>

The WASP sample doesn't look so much better now, does it? Not so much so that it's worth downloading some unknown framework and inheriting someone else's bugs and execution overhead and security holes?
 

What's problem?

(Score:1, Flamebait)

by hotfireball (948064) on Sunday January 22, @09:40PM (#14535583)

PHP coders really needs some framework. Because I don't realize how else they can work with the "technology"-like thingy which has bad recursion, lots of not-thread-safe stuff, poor OO, hell slow interpreter, no namespaces, non-standard date format, 4x more built-in functions than Perl (however the functionality of them just same), inconsequent function naming convention and no unicode so far. For those who dislikes Python and likes PHP, I would like to offer one experiment. Please do the simple task: make array of arrays of dict of dict of array of dicts structure (you may feel free to make it slightly other) and then try to change/replace/remove/add and compare each element of any place. Afterall compare perfomance and readability of the code.
 

Re:Just use Ruby or Python

(Score:3, Insightful)

by onion2k (203094) on Sunday January 22, @06:25PM (#14534714)
(http://www.phpgd.com/)
 

Currently I'd discount Ruby from any sizable web development as it's still very much a minority language and it'd be practically impossible, or outragously expensive, to hire a Ruby developer. If your development team or company vanish (run over by a bus, move to Australia, whatever) you need to be able to get someone else who can come in and maintain the code quickly. That just wouldn't happen for a site written in Ruby. Of course, it'd be fine for any small development like a homepage or a blog .. but PHP would be equally fine for such an unimportant venture despite it's shortcomings. To a lesser extent the same can be said for Python. There's a lot fewer Python developers about than PHP, but there are some.

Caveat: IAAPD (I Am A PHP Developer), so perhaps I'm horribly biased.

[Apr 4, 2005] SlashdotPHP5 Could PHP Soon Be Owned by Sun

At first glance, the obvious changes to PHP are a result of the success of the Java platform and the weaknesses of PHP revealed in comparison. With the release of PHP 5, it's apparent that the developers of PHP and the Zend Engine (essentially a single group) felt compelled to make PHP much more like Java with respect to object-oriented programming. Zend, the Israeli company backing the development of PHP, promises on their web site that "full integration with Java will be closer than ever before." Hmmm, full integration with Java, huh?

On November 4th, 2003, Zend announced a strategic partnership with Sun. This deal also included advisors from Borland, Macromedia, MySQL and others. The purported purpose of this deal was to make PHP part of Sun's web server and bring it to the corporate world of development that previously had been dominated by ASP and ColdFusion. Now with the release of PHP 5, it's far more apparent which path PHP is taking.

PHP's object model was re-written from the ground up and mimics the abstract properties of Java's object method. There are private and protected members and methods, abstract classes and interfaces, in practice, identical to Java's object model. The extent of the influence that Sun has on PHP today is clear. If you have experience with Java and PHP, reading the details of the object model reveals the absolute cloning of the Java object model within PHP 5. From throwing exceptions to static variables, PHP 5's object model mimics Java in concept all the way to the syntactical level.

This is great for enterprise developers using Sun products, but with the release of PHP 5, what does this mean for the half-million PHP developers worldwide who have depended on PHP for open-source development, or for the developers whose ideas and efforts have brought PHP up through the ranks from its inception in 1995? When PHP goodies were bundled with Sun's web server on November 4th, 2003, with a $775 price tag, PHP began down the path of corporate ownership. For years developers have eagerly contributed their ideas and efforts to be a part of the success of PHP. Now that all the hard work and volunteering has paid off and PHP is a worldwide success, it appears that PHP could soon be another corporate shill owned by Sun, MySQL, Borland and Macromedia, if not on paper, then by direct influence on the people at Zend. Of course it will remain open source so that those half-million developers can continue to contribute their time and genius to its success, but if those thousands of contributions lead to direct financial gain for companies whose coffers are already overflowing and are simultaneously using those contributions to manufacture software with price tags out of reach to anyone but corporations, is PHP still the language developers should be focusing on for use in the open-source community?

On the positive side, this edition of PHP does bring improved performance and a new suite of MySQL functions. Backward incompatibility is limited to a list of ten issues. Additionally, there are only minor configuration file changes that need to be made to the web server. Several directives have been introduced for configuring php.ini files, mainly dealing with hashes for encryption.

Some very useful functions have been added to PHP5. It's been nine years in the making, but PHP5 now includes two functions to uuencode and uudecode. Combining those functions with the new socket and stream functions, developers can create a lots of "kewl" applications. An application to automatically encode and decode files to and from news servers comes to mind as an example of how to incorporate these new functions. At that point of course, a developer could use any of PHP's existing functions to continue to manipulate the files, store the contents in databases, and so on.

An addition to error reporting aids developers in keeping their code up-to-date. The E_STRICT message tells developers when their code is using deprecated functions or is in danger of not being forward compatible. However, don't assume that E_STRICT will be output if using E_ALL, because it won't. E_STRICT must be explicitly declared to output its suggestions to PHP 5 code.

While the rewriting of PHP's object model to essentially that of the Java object model does raise flags about the direction of PHP, it is still a powerful addition to the PHP5 release. Java became successful for a reason: it's intelligently designed and facilitates code reuse. By borrowing the best features of Java's object model, PHP has leveraged itself with far more credibility as a programming language that can stand on its own two feet (even if Sun, Borland and Macromedia are holding it by its arms).

Some vital re-workings in the PHP object model lie in how objects are treated in low-level fashion. Instead of passing the actual object itself, PHP's object model passes by reference. Now when operating on objects, developers can pass around multiple handles to the actual object allowing for more powerful and efficient applications. Existing PHP objects do not need to be re-written to take advantage of this change in PHP 5.

In general, developers who have experience with Java will easily adapt to PHP 5's object model. On the downside, if PHP is a developer's primary language and he or she hasn't been introduced to the world of static variables, public and private methods and the host of aspects included with this new model, they may have a bit of a learning curve adopting the higher-level format of object-oriented programming in this release. Overall, though, this change will be a plus for creating large-scale, object-oriented applications with PHP.

Keeping pace with the developments in MySQL and PHP's tight relationship, PHP5 has added a new suite of MySQL functions relating to the new features added since MySQL 4.1. Denoted as Improved MySQL Extension, its purpose is to allow developers to take advantage of prepared statements and the other additions to MySQL 4.1 and above.

Something very interesting to note with the addition on the Improved MySQL Extension is the absence of bundled MySQL client libraries with PHP5. There are numerous reasons given for this, including the different licenses that PHP and MySQL are under (PHP is under a BSD/Apache type license and MySQL is under a GPL license). The PHP5 documentation also assures developers that "there will always be MySQL support in PHP of one kind or another," but doesn't go into details as to the future of MySQL support. This perhaps is further evidence that the long-lasting popularity of LAMP environments (Linux, Apache, MySQL, PHP) will soon be replaced by SLOP environments (Sun, Linux, Oracle, PHP). If Zend continues to shy away from MySQL and completely joins forces with Sun, MySQL may soon no longer be part of the picture, and cheap, fast development may no longer be possible for PHP developers in the same capacity as it is today.

Zend clearly has underplayed the extent of the shift that has taken place concerning the future of PHP. While this version of PHP does provide a much better object model and added features, is this the beginning of the end of PHP as the choice of web scripting language for the open-source community and developers not under the employ of corporations? Will the average developer still be using PHP five years from now, or will the usefulness of PHP be limited to companies who can afford to shell out thousands of dollars for all of the necessary software that may be required to make PHP a viable option for development (along with the purchase of products from Sun, Macromedia, Oracle, Borland and others)?

While today this is still speculation, the evidence and tone lends credence to the thought that with the success of PHP, built on the backs of developers worldwide, the near future of it may include an alienation of it from those who energized it at its genesis, propelling it to the corporate enterprise status that those in control of PHP are seeking today. No matter what actually happens, developers should be aware of the major developments with PHP beyond the surface level function additions and new object model. Companies and developers who are employing PHP 5 for large-scale applications today at a reasonably low price may be in for a surprise in the next few years, if operating PHP at full capacity involves the purchase of additional, expensive software.

[Jun 19, 2006] Enterprise Systems IBM’s Embarks on SOA Blitz

Touts SOA-friendly PHP Integration Kit

Also last week, IBM announced a new PHP integration kit for its WebSphere Application Server (WAS) Community Edition (CE). IBM officials say the new kit—which is available as a free download on its AlphaWorks Web site—will help customers build PHP-based application front-ends using Big Blue’s Apache-based application server, WAS CE.

IBM representatives took pains to spin the PHP kit as an SOA-friendly offering, but the reality, officials acknowledge, is that customers can and will tap the kit in a huge variety of different scenarios.

“What it’ll allow a developer to do is basically build a J2EE application that includes PHP, so that introduces the opportunity to use PHP for what it’s good for, for building Web front ends and simple logic. By making the integration kit available, we’re presenting that as an alternative for people building J2EE applications with WAS CE,” says Paul Buck, director of gluecode development with IBM.

Buck says PHP is an open-source scripting language that’s ideal for building lightweight applications, particularly as front-ends for J2EE app servers. The new kit helps improve the interoperability between the open source PHP runtime and the WAS CE app server: “The PHP run-time that’s generally used is what’s picked up at php.net—it’s all open-source technology, but with the integration into WebSphere, you can actually use WebSphere to serve up the PHP requests, so with the integration kit, as the requests come in to WebSphere, it will know exactly what to do with it and will dispatch it off to the PHP runtime.”

As far as service-enablement is concerned, Buck alludes to skyrocketing PHP usage—some estimates put the number of PHP-enabled Web sites at 20 million—and suggests the technology provides a fast and extensible way to expose data sources. “PHP is really good for Web front-ends. That’s really where it cut its teeth on the Web, with building Web front-ends to access data, to collect data, to present user interfaces to update back end systems.”

It’s likely IBM will provide PHP integration for the pay-for-use version of WebSphere, too, Buck says.

WAS CE is a lightweight J2EE application server that’s based on the Apache Software Foundation’s Geronimo technology. “You can download it, it’s free, [and] the license you get allows you to use it as a commercial application server, but there’s no support. If you want support, then we sell three levels of service agreements,” he notes. “The service agreements are per-server, and for server that’s a system that includes up to four CPUs.”

[Nov 29,  2005] Debugging techniques for PHP programmers

Explore various methods for debugging PHP applications, including turning on error reporting in Apache and PHP, and by placing strategic print statements to locate the source of more difficult bugs through a simple example PHP script. The PHPeclipse plug-in for Eclipse, a slick development environment with real-time syntax parsing abilities, will also be covered, as well as the DBG debugger extension for PHPeclipse.

[Aug 26, 2006] Cooltools Cool Tools at OpenSPARC T1 Better late then never: Sun started to provides  precompiled (with Sun Studio) OSS packages:

[Aug 12,  2004]  PHP Debugging Basics by David Sklar

Whether you're a PHP newbie or a wizard, your programs are going to have bugs in them. Nobody's perfect. This article gives you some techniques for finding and fixing the problems in your programs. It covers three topics:

Configuring Error Reporting

First of all, you need to configure the PHP interpreter so that when an error happens, you can see information about it. The error info can be sent along with program output to the web browser. It can also be included in the web server error log. A common way to set things up is to have error output go to the web browser when you're debugging your program, and then to the web server error log once the program is finished and (supposedly) working properly. That way, web site users can't see any potentially sensitive data included with error output.

To make error messages display in the browser, set the display_errors configuration directive to On. To send errors to the web server error log, set log_errors to On. You can set them both to On if you want error messages in both places.

An error message that the PHP interpreter generates falls into one of five different categories:

You don't have to be notified about all of the different error categories. The error_reporting configuration directive controls which kinds of errors the PHP interpreter reports. The default value for error_reporting is E_ALL & ~E_NOTICE & ~E_STRICT, which tells the interpreter to report all errors except notices and strict notices.

PHP defines some constants you can use to set the value of error_reporting so that only errors of certain types get reported: E_ALL (for all errors except strict notices), E_PARSE (parse errors), E_ERROR (fatal errors), E_WARNING (warnings), E_NOTICE (notices), and E_STRICT (strict notices).

Because strict notices are rare (and new to PHP 5), they are not included in E_ALL. To tell the PHP interpreter that you want to hear about everything that could possibly be an error, set error_reporting to E_ALL | E_STRICT.

LinuxPlanet - Interviews - Interview--Core Web Application Development with PHP and MySQL - Getting to the Core

LinuxPlanet: Why did you set out to write this book?

Marc Wandschneider: Over the years, I've put together a number of small web applications or web sites for various small businesses and charities. Despite being a very accomplished programmer with over a decade's worth of experience, I always found myself floundering and making a lot of mistakes as I adapted to a completely new way of writing "programs." At the same time, I was shocked at how unbelievably productive PHP was as a language. I was able to crank out large amounts of code in short order.

I would periodically look for books or other resources, but find they weren't answering the questions I was asking: how do I design a web application for security? What is the best way to address globalization issues in my application? How do i design a database for efficient access? I also found that, coming from a background mostly in C/C++, Java, and .NET, there were a number of mistakes I was making time and time again when learning the new environment that were tricky and time consuming to figure out.

After writing a number of web applications and slowly learning the answers to the questions I had been asking, I decided to sit down and write a book about my experiences. Instead of just being a tutorial into a number of topics like such as PHP, MySQL, and relevant technologies such as sessions and cookies, I decided to write a book that worked the developer through the questions and processes required to write robust web applications.

LP: There are a good two-dozen or more other books on the same subject matter. Why is yours special?

Wandschneider: There are a number of good PHP books available today for purchase, but the one thing I found lacking in most of them is a systematic approach to some of the more fundamental concerns in writing a web application. Many will merely present security as a single chapter with a list of things to "check" to make sure your site is properly protected. Others will have a chapter covering strings, but not really address how you deal with people writing in foreign languages.

Core Web Application Development with PHP and MySQL doesn't just tell you how to use a particular technology such as sessions, XML, or file uploading--it discusses how they fit into the rest of your application, how they interact with other features, and how you use them in a safe and effective manner.

The other big problem I had were samples that seemed kind of contrived--e-commerce applications that left out key portions of the process or samples that were simply not something you're going to buy a book to help write at all. To solve this, I developed three full samples--an appointment/calendaring system, a blogging engine, and a poster store e-commerce system. With the full code included on a CD ROM (and updates available from the author's web site), you can actually play with completely working and usable web applications, debugging through them and fiddling with various features.

LP: What would you say sets this book apart from others?

Wandschneider: In addition to the samples and systematic approaches to topics critical to writing effective web applications, this book also shows programmers a lot of the tricks and traps hiding in the PHP language. I'm the kind of person who makes every single mistake possible, so I had a lot of experience in doing stupid things and was able to put a lot of that into this book, to hopefully help the reader avoid making those same mistakes.

I am also the kind of person who likes to understand how things work and why things are done. Without bogging down in pedantic details, I tried to justify and explain topics and technologies as I worked through them. Later on, you might not remember the exact details of the PHP function call or SQL Statement, but you might recall that this was something important enough to worry about and look it up again.

LP: Why do other books neglect these topics, do you think?

Wandschneider: I actually think that most other books do address these topics, but often in a disorganized way that gives them the feel of being tutorials crammed together into one big binding. A chapter on security that merely offers a simple list of things to check in your web server or php.ini don't adequately address the problem, nor does discussing programming without discussing all the ways in which things can (and inevitably do) go wrong.

LP: Why MySQL?

Wandschneider: I actually didn't want to write this book for only MySQL. While it is the database I use most frequently (strictly because it's the first I picked up and learned), the concepts in this book are not unique to that package. I had originally hoped to keep the book database server agnostic, but as I wrote more and more, I came to discover this was not possible, so I decided to focus on MySQL, and provide hints and tips to users of other DBMSes whenever possible (such as Appendix II: "Database Function Equivalents").

There is nothing in this book that should prevent the user from being able to develop web applications with other servers.

LP: Marc, what is your background?

Wandschneider: I got my degree in Computer Science from McGill University in Canada and moved to the United States to work for Microsoft in the mid-1990s. I spent most of my time there working on Visual Basic and various component technologies associated with it. In the end, I was the manager of the WinForms team for the .NET platform. I left in 1998 after increasing dissatisfaction with my job and the direction the company was going led to me to explore other opportunities.

Amusingly enough, in my early days at Microsoft, I found databases quite frustrating and aggravating to work with, and it wasn't until I began working with MySQL that I began to truly enjoy working with them again.

I have spent the last six years traveling the world, helping companies with various software development problems, and writing open source software in my spare time. I have lived in various countries such as Italy, Germany, and Japan, and have seen how mono-lingual web applications can be problematic for users.

LP: Microsoft? Aren't you worried that will reduce your credibility in the open source community?

Wandschneider: I've met some people who figure that since I worked for Microsoft, I must eat babies or something in my spare time. And yet, I maintain that my years at Microsoft were very valuable and rewarding. The company was still very much a fun place to work in the mid 1990s and I learned innumerable things about robust programming and truly testing and shipping effective software.

It is these good habits that I have tried to carry forward with me in my web application development. Everybody benefits when software is written well, and I hope to contribute more written open source.

LP: How long did it take to write the book?

Wandschneider: I went to a local café and started writing this book. Six months and many, many, many double espressos later, I had written the first draft of it, and it was off to editing (which took a few more months). I wasn't working at the time, so I was basically spending 40-50 hours a week writing it. I would spend a few days writing code and samples for a particular chapter or group of chapters, plan strategy for what I was going to write, and then I would actually begin typing it all up.

LP: Did you enjoy writing this book?

Wandschneider: There is nothing like trying to explain a particular concept or technology others to make sure you really understand how it works. I spent a lot of time writing little scripts and samples, and would sometimes sit there scratching my head, while at other times I would learn something completely new and interesting I had never known before. After a while you start dreaming in SQL and PHP. That's probably not the best thing to admit!

LP: What experience will readers of this book be expected to have?

Wandschneider: I wrote this book for people who have "programmed" before. I make no stronger requirement than that. If they have written a number of VB scripts or programs, written Perl for a while, or indeed written large applications in Java or C/C++, this book was designed to be accessible to the reader.

Since I knew next to nothing about databases before beginning to write web applications, I likewise assumed the reader would know little about those as well. With that in mind, the book sets out to teach the reader not only the syntax of PHP and SQL, but also the problems they will encounter, and how to use them most effectively in their applications.

LP: What platform do you think readers of this book should be using?

Wandschneider: There are absolutely no requirements on what the reader uses. I myself, to make sure that there was nothing too restrictive in what I was writing, developed, tested, and ran all samples on Windows, Linux, FreeBSD, and Mac OS X. I used PHP versions from PHP 5.0 to 5.0.4, as well as MySQL Versions from 4.1.7 and on (including the newest 5.0 releases).

I have recently worked on commercial PHP/MySQL web applications where development has occurred on Windows, Mac OS X, and servers running multiple flavors of Linux. In only the most extreme cases did we ever even notice that the versions were running on different platforms.

LP: What are the major features of PHP5 about which you're excited? What about MySQL?

Wandschneider: The object oriented features in PHP 5 are a very welcome addition to the language. I've found that it massively helps design of application and encourages clean organization of your code. The strict syntax checking has also proved helpful to avoid undefined variable errors, as well as numerous other little coding issues that have been hiding in my code. Add to that the new MySQLi (Improved MySQL) extension, and I've found programming PHP 5 to be a true joy.

MySQL has grown to be a truly interesting and robust database system. Versions greater than 4.1.7 have massively improved Unicode support, which has allowed me to develop applications that are completely ignorant of what language the user sends us data in. The database just stores them all as UTF-8 strings, and the application shuttles these data to the client. With a robust set of data types and the choice between MyISAM and InnoDB tables, there is a real sense of control when using this server.

LP: Where can users go for more help with this book?

Wandschneider: I maintain a blog at http://www.chipmunkninja.com, where I post not only updates and notes on this book, but also other tutorials and other things that developers might find useful.

Conclusion

Core Web Application Development with PHP and MySQL is organized into five core parts:

With this progression through the topics, and systematic approach to design and security, the reader, whether they be inexperienced or advanced, will find this a valuable tool to have around as they explore the world of writing web applications. With a remarkable attention to detail, a light and easy writing style, and a complete explanation for how things work, you will absolutely love working through this text.

Book Information

Title: Core Web Application Development with PHP and MySQL (Core) (Paperback)
Author: Marc Wandschneider
Publisher: Prentice Hall PTR; Bk&CD-Rom edition (September 26, 2005)
ISBN: 0131867164
Price: $49.99

Software Engineering for Internet Applications

Slashdot Recommended Reading List for PHP

freshmeat.net Project details for Conary by Michael K. Johnson, the author of Linux Application Development. see his homepage

Conary is a distributed software management system for Linux distributions. It replaces traditional package management solutions (such as RPM and dpkg) with one designed to enable loose collaboration across the Internet. It enables sets of distributed and loosely connected repositories to define the components which are installed on a Linux system. Rather than having a full distribution come from a single vendor, it allows administrators and developers to branch a distribution, keeping the pieces which fit their environment while grabbing components from other repositories across the Internet.

freshmeat.net Project details for Andy's PHP Knowledgebase

Andy's PHP Knowledgebase is a database-driven knowledge base management system. It features bookmark friendly URLs, easy search with browsing by category, article submission, and a professional and attractive interface. It is intended to be used to store, manage, and update article content for a knowledge base, but is very customizable and enables any number of creative uses.

SQLiteManager by Frédéric HENNINOT

SQLiteManager is a multilingual Web-based tool to manage SQLite databases. It features multiple database management, creation, and connectivity, property and options management, table, data, and index manipulation, the ability to import data from a file, conversion from MySQL queries, view, trigger, and custom function management, and exporting of database structure and data.

Archive of old news...

Recommended Links

In case of broken links please try to use Google search. If you find the page please notify us about new location
Google     

The future of PHP 06 May 2008

 

AMPS for Solaris 10 AMPS (Apache MySQL PHP SSL) for Solaris 10 by Mel Lester Jr. (meljr@meljr.com) Version: 1.01 January 25, 2006

The strategy is to utilize as much of the Open Source and other free software bundled with Solaris 10 as possible and integrate Apache2, MySQL, PHP and SSL in a environment that can take full advantage of Solaris 10 zones, resource management and highly scaleable, secure System Administration.

 Cooltools Cool Tools at OpenSPARC T1 Better late then never: Sun started to provides  precompiled (with Sun Studio) OSS packages:

 

 

"IBM developerWorks has put together a PHP recommended reading list. It provides resources for developers and admins adopting PHP and tackling advanced topics such as building extensions and writing secure code. There's also a list of books and blogs for keeping up with changes to the language itself."

Tutorials and Sample Chapters

Web Database Applications with PHP and MySQL Chapter 11: Authentication and Security (PDF Format)

Programming PHP (First edition) Chapter 5: Arrays (HTML Format)

Programming PHP (2-d edition) Chapter 8: Databases (PDF Format)

Learning PHP 5 Chapter 8: Remembering Users with Cookies and Sessions (PDF Format)

PHP Cookbook Chapter 8: Web Basics (PDF Format)

Web Database Applications with PHP, and MySQL Chapter 8: Sessions (HTML Format) See also Chapter 8: PHP Session Management With Cookies

Learning PHP and MySQL Chapter 9: Getting PHP to Talk to MySQL (PDF Format)

Upgrading to PHP 5 Chapter 4:  SQLite (PDF Format)

PHP in a Nutshell Chapter 16: Manipulating Images (PDF Format)

Essential PHP Security Chapter 4: Sessions and Cookies (PDF Format)

MySQL Cookbook

PHP Hacks

 

PHP Pocket Reference Introduction

Webmonkey databases PHP-MySQL Tutorial

http://ca.php.net/manual/ -- annotated PHP manual.

PHP Tutorial - Part 1

Recommended Papers and Interviews

Interview with with Rasmus Lerdorf

FAQs

Scripts Archives

Computers and Internet: Software: Internet: World Wide Web: Servers: Server Side Scripting

PHP vs Perl

Perl versus PHP 5 - O'Reilly ONLamp Blog

Critique

[Apr 20, 2006.] What I don't like about PHP by Edwin Martin <edwin@bitstorm.org>.

August 6, 2004; Last update: April 20, 2006.

I have been developing in PHP for six years now. PHP is very easy to program in. But PHP also has some serious flaws.

Below I give some reasons why you have to do some serious thinking before implementing a large scale web application in PHP.

1. Bad recursion

Recursion is the mechanism in which a function calls itself. This is a powerful feature which can make something complex something simple. An example of a function using recursion is quicksort. Unfortunately, PHP is not good at recursion. Zeev, one or the developers of PHP, says this: "PHP 4.0 (Zend) uses the stack for intensive data, rather than using the heap. That means that its tolerance recursive functions is significantly lower than that of other languages." See bug 1901. This is a poor excuse. Every programming language should provide good recursion support.

2. Many PHP-modules are not thread safe

A couple of years ago, Apache released version 2.0 of its web server. This version supports multithreaded mode, in which one piece of software can run multiple times simultaneously. The makers of PHP say that the core of PHP is thread safe, only the non-core modules often aren't. But nine out of ten times, you do want to use such a module in your PHP-script, making your script unsuitable for Apache's multithreaded mode. That's why The PHP Group doesn't recommend running PHP on Apache 2 in multithreaded mode. The bad multithreaded mode support of PHP is often seen as the reason Apache 2 still didn't catch on.

Read the discussion about this on Slashdot: Sites Rejecting Apache 2?.

3. PHP is crippled for commercial reasons

The performance of PHP can be increased to 500% by using caching [benchmarks]. So why is caching not build into PHP? Because Zend, the maker of PHP is selling its own Zend Accelerator and of course, they don't want to cannibalize on there own commercial products.

But there is an alternative: APC.

4. No namespaces

Suppose someone creates a PHP-module that can read files. One of the functions in this module is called read. And someone else's module can read web pages and also contains a function read. Then it is impossible to use these modules together because PHP will not know which read function you want.

An easy solution to this is namespaces. It was a suggested feature for PHP 5, but unfortunately it didn't make it. Now, without namespaces, every function has to be prefixed with the module name, to prevent name collisions. This leads to terrible long function names like xsl_xsltprocessor_transform_to_xml which makes code harder to write and read.

5. Non-standard date format characters

Many programmers are familiar with the date format characters known from UNIX and the C programming language. Other programming languages adopted this standard, but strangely enough, PHP has its own, completely incompatible date format characters. While in C, "%j" stands for the day of the year, in PHP this stands for the day of the month. To make things even more confusing: the function strftime and the date_format of Smarty, a PHP templating engine, do use the C/UNIX format characters.

6. Confusing licenses

You might think PHP is free and all PHP-modules in the manual are free too. Wrong. For example, if you want to generate a PDF-file from PHP you will find two modules in the manual: PDF or ClibPDF. But both come with commercial licenses. So for every module you use, you have to make sure you agree with its license.

7. Inconsequent function naming convention

Some function names consist of more than one word. There are three conventions for combining these words:

  1. Glued together: getnumberoffiles
  2. Separated with underscores: get_number_of_files
  3. Camel case: getNumberOfFiles

Most Languages choose one of these variants. PHP uses all of them.

For example, it you want to convert special characters to HTML entities, you use the function htmlentities (Words glued together). If you want to do the opposite, you use its little brother function html_entity_decode. For some reason the words are now separated by underscores. Why is this bad? You know there is a function named strpad. Or was it str_pad? Every time you have to look up what the notation is or wait for an error to occur. Functions are case insensitive, so for PHP there is no difference between rawurldecode and RawUrlDecode. This is bad too, because both are used and because they look different, they will confuse the reader.

8. Magic quotes hell

Magic quotes prevents PHP-scripts from SQL injection attacks. That's okay. But for some reason, you can turn this off in the php.ini configuration file. So if you want to write a portable script, you always have to check whether magic quotes is turned on or off. So a "feature" to make programming easier, actually makes it more complex.

9. No standard framework

A website wihout a framework which grows will eventually become a maintanance nightmare. A framework can make a lot of work easier. The most popular model for a framework is the MVC-model, in which layout, business logic and interaction with the database are seperated.

Many PHP web sites don't use the MVC-model. They don't even use a framework. Although some PHP frameworks do exist and you can also write your own, articles or manuals about PHP don't say a word about frameworks. While JSP-developers use frameworks like Struts and ASP-developers use .Net, it looks like the concept of a framework is largely unknown by PHP developers. This says something about how professional PHP really is.

Update: Zend, the developer of PHP, is working on a framework: Zend PHP Framework.

10. No Unicode

With Unicode it is possible to use every language in the world, for example Chinese, Arabic and Hebrew. While every other serious programming language supports Unicode for many years, PHP still has a very hard time dealing with this. Unicode is planned for PHP 6, so we still have to wait a long time before PHP supports this trivial feature.

11. Slow

You think Java is slow? PHP is much slower! See this Computer Language Shootout. Normally that's not a big issue, because most PHP-scripts only pull data from the database and render it in HTML, a very simple job and fast enough for page views. So how can PHP be used on all these popular websites with lots of visitors? Because of caching. These sites use MCache and APC to get performance. It doesn't proof anything about PHP, only that it's cachable.

Conclusion

For very small projects, it can be a nice programming language. But for larger and more complex projects, PHP can show its weakness. When you search long enough, you'll find solutions to some of the mentioned problems. So when a solution is known, why isn't it fixed? And why are the fixes not mentioned in the manual?

It's good that an open source language is very populair. Unfortunately, it's not a great language. I hope all problems will be solved once (in PHP 6?) and we will have an open source language that's open source and good.

Until then, when you start a project larger than five scripted pages, you might also consider C#/ASP.Net or Java/JSP as a better solution.

After I wrote this page, some people informed me about other, similar pages:

Spyced Why PHP sucks Jonathan's Python Blog

(July 8 2005)

Apparently I got linked by some PHP sites, and while there were a few well-reasoned comments here I mostly just got people who only knew PHP reacting like I told them their firstborn was ugly. These people tended to give variants on one or more themes:

As to the first, it is true that PHP is not alone in having warts. However, the lack of qualitative difference does not mean that the quantitative difference is insignificant.

Similarly, problems can be worked around, but languages/environments designed by people with more foresight and, to put it bluntly, clue, simply don't make the kind of really boneheaded architecture mistakes that you can't help but run into on a daily baisis in PHP.

Finally, as I noted in my original introduction, with PHP, familiarity breeds contempt. You don't need years of experience with PHP before an urge to get the hell out and into a more productive environment becomes almost overwhelming -- provided that you have enough experience to realize what that nagging lack of productivity is telling you when you go to consult the documentation for the fifth time in one morning.

Basically these all boil down to, "I don't have enough experience to recognize PHP's flaws because I haven't used anything better." Many years ago, I had this same attitude about Turbo Pascal: it was the only language I knew at the time, so anyone who pointed out its flaws was in for a heated argument.

There's nothing wrong with being inexperienced, as long as you have an open mind. If you do, try Spyce. Try RoR, if you must. Better toolkits are out there, for those who aren't satisfied with mediocrity.

I've done a fair bit of web development. I've written HTML-generating code in C CGI scripts, Cold Fusion, TCL (with OpenACS), ASP.NET, and, of course, Python with Spyce.

Two technologies I've steered clear of are any J2EE stack and PHP. I've seen enough of each to know that I'd be immensely frustrated with either. Briefly, although they are quite different, neither is elegant, and elegance counts.

Recently, though, I had to spend a few days extending a small amount of PHP code. (I'm just glad for two of those qualifiers: "few" and "small.") The more I used it, the less impressed I was, which is why I don't think a longer experience would make this post any more favorable to PHP.

This is far from an exhaustive list. It may have some reasoning in common with other voices of reason, but I'm writing this primarily from a Python developer's perspective. So, I won't waste time bashing PHP for being dynamic, which some Java zealots do; nor will I fault it for mixing code and markup, which also has its uses (and Spyce recognizes this). PHP's problems are much, much deeper.

First, let's try to be a bit more specific. Does PHP the language suck, or does PHP the environment suck?

They both suck.

In fact, they suck for the same reason: PHP-the-language and PHP-the-environment both grew by accretion of random features, not by any purposeful design for orthogonality. So you have idiot "features" like magic quotes ("Assuming it to be on, or off, affects portability. Use get_magic_quotes_gpc() to check for this, and code accordingly) and register globals (same disclaimer applies, only more so).

Trying to write "portable" php code is such a disaster that it's no wonder almost nobody tries; you can't even code for a least-common-denominator version because (a) so much is subject to change on the whim of the site's config file and (b) even if it weren't, the PHP designers change the defaults almost as often, even within minor version releases. (E.g., the registerglobals change for 4.2.)

The PHP community realizes this to a degree, even if the fanboys won't admit it. PHP5 uptake is almost as glacial as MySQL4 was/is because it breaks so much code. One of the biggest ways is, "all your copy-on-assign code, isn't anymore."

That bears explaining if you haven't coded in PHP4: any time you make an assignment in PHP4, what other languages would call a "deep copy" is performed. So you might naiively expect this code to add a new key/value pair to the associative array at $a[0]: 

<?
$a = array(array('foo' => 'bar'));
foreach ($a as $item) {
   $item['new key'] = 'new value';
}
print_r($a);
?>

This, of course, changes $a not at all, because the assignment to $item is a deep copy. (It's also slow as hell if the items you're deep-copying are substantial.) The workarounds for this are truly ugly.

This changes completely in PHP5, which is a good thing, unless you're trying to upgrade an existing body of code. That's not a small "unless;" if you weren't using PHP4, there's really no excuse to start out in PHP5 instead of Spyce or CherryPy or Rails.

Even with a willingness to break backwards compatibility, a lot of broken behavior persists in PHP5. For instance, since I brought up PHP arrays: an array in PHP is really a map. When you're using it as a linear array, it's really mapping keys 0, 1, etc. to your values. (I don't want to know what it does when you're using it as a 2D array.) This might seem like a good idea, until you spend about two seconds thinking about it, at which point those of you who have had a basic introduction to data structures will be thinking, "What the hell? The performance will SUCK!" And you are entirely correct. The only other language I can think of that does this is AWK, and it was a bad idea there, too, but less of a problem since, well, when was the last time you wrote an AWK script longer than 10 lines?

PHP-the-language also shares with Perl the unfortunate tendency to guess what the programmer "really meant" instead of raising errors. (String where an integer makes more sense? No problem, we'll just throw in zero!) Unlike perl, there's no "use strict" option to mitigate this.

I could keep going, on how, for instance, the PHP environment doesn't give you any way to have a single, multithreaded long-running process, which is probably why you see so much PHP code that sticks everything into the session object. Or how PHP's string processing library adopted the C stdlib functions without improving on them. Or a dozen things, but a comprehensive enumeration of PHP design flaws would be a daunting task indeed.

In short, PHP sucks because, PHP's authors are prone to confuse "pragmatism" (a fine design goal, if done well) with "adding random features without considering how they impact the language as a whole." Thus, its authors have found it necessary to correct obvious flaws in both minor and major releases, with the result that the recent PHP5 breaks with the past to an unprecedented degree while still leaving many fundamental flaws un-addressed. I don't know if this is because they didn't recognize those flaws, or more likely, because they were willing to impose "requires a lot of pain to upgrade" but not "requires a complete re-write."

Ian Bicking wrote that "Python could have been PHP" (in popularity for web development). If I were a PHP developer, I'd be pretty disenchanted with how the language has evolved; I don't think it's impossible that Python could have a second chance.


- posted by Jonathan Ellis @ 10:52 AM  

Comments:

I'm a PHP developer, and have been for three years, but I have to agree with some of your comments.

magic quotes, and register globals should have never been added as a "feature" and is just a pain to have to code work around today, to get the script's to work with it on and off.

I also agree with PHP5 breaking most PHP4 script's, that's what, in my opinion, will hold back PHP5 becoming main stream, we won't have much luck with it until popular script's are updated to work with PHP5, and server's by popular demand will need to upgrade. Until then we won't see much changes to these problems.

I love how python works, but really haven't taken the time how actually learn it, only downside is that mod_python isn't installed on many server's.
 

# posted by Justin Shreve : 3:40 PM

 

Spyce will run as a CGI/FastCGI script, Justin. :)
 

# posted by Justin Shreve : 5:05 PM

 

Magic quotes and register globals were features designed to lower the bar more, for newbie developers who didn't understand databases, or HTTP as well as for seasoned professionals to write code quicker by making certain assumptions. You can write secure code with both of those settings if you're careful and know what you're doing. These two extremes: easy for newbies, and short cut for seasoned developers don't mix.

Unfortunately, delivering web apps for use by others cannot make those assumptions.

You really don't have to worry if a user has register globals on or off. After all, you the app developer should be using the global arrays anyway. So, it's really just magic quotes which can be a pain. And is it a pain to detect it and do an ini_set? That's just a couple lines in a global include.

Ok, next subject: arrays. There is no pretense on what arrays are, see here:

http://us2.php.net/manual/en/language.types.array.php

And the manual notes that they are maps, and are optimized so that they can be treated as lists, hash tables, queues, stacks, etc.

I would venture so far to say that PHP arrays are extremely powerful, flexible, and straight forward. Moreover, I trust that the many PHP engine developers - many of which hold degrees in comp sci and know of The Big O and data structures, have in fact optimized the arrays for the best speed possible. As far as I can tell, using arrays heavily in PEAR::SOAP is that the performance is great.

Last but not least, PHP5. There are incompatibilities everywhere in software development. There is a compatible mode for PHP5, and going through your code and fixing reference changes is a do-it-once and your done exercise. You bit the bullet for the day / week, and then you're good to go and ready to take full advantage of all the new features. It's a small price to pay, and gradually people are making that change.

I have no qualms against Python, but flaming another language wihout due course, now that just sucks.
 

# posted by Anonymous : 9:03 PM

 

Been working with PHP recently (sadly version 4) and couldn't agree more with your observations.
 

# posted by matt : 11:21 AM

Couldn't agree more, Jonathan. I have really tried to like PHP several times now, but the features have been adopted so haphazard that I go crazy with it. Many are duplicated and the API is nonstandard to itself. The database layer(s!) are one of the best examples of this type of evolution.
 

# posted by Anonymous : 6:50 PM

I have to use PHP at work, and it does indeed suck. I could lengthen your list of gripes by a factor of 100!

But as my friend is fond of arguing, my main beef with PHP is that (like MySQL) it does exactly what it's supposed to do, it just shouldn't be used for a lot of stuff it's used for. It's a fast and easy-to-use web scripting language, not a strictly typed scalable enterprise language. :-)

Too many people choose PHP for the wrong projects!
 

# posted by Anonymous : 1:02 PM

Another anonymous commentator said, "I trust that the many PHP engine developers - many of which hold degrees in comp sci and know of The Big O and data structures, have in fact optimized the arrays for the best speed possible."

Holding a degree in computer science does not make you magically able to alter the fundamental properties of fundamental data structures.

If PHP's "arrays" are implemented as balanced trees, their performance will be O(lg n) for all operations, compared to O(1) accesses on real arrays, or O(1) prepends on real lists. If they're implemented as hash tables, then however good the hashing function, there will inevitably be many degenerate cases where insertion and lookup complexity rises to O(n). This is called "not scaling well".

However they're implemented, memory usage on simple arrays will ALWAYS be considerably higher than it would have been for a specialised array type. You've got great performance on your code? Then either you have incredible resources at your disposal, or you only have half a dozen unique visitors in a year.

PHP simply doesn't scale as well as other alternatives. That's not bashing PHP; the world needs a simplistic language that newbies can put together a homepage in, and PHP handles hobbyist sites beautifully. But claiming it's ideal for every kind of programming is stupid. Let's just say there's a reason Doom 3 and Longhorn are not written in PHP...
 

# posted by Anonymous : 3:37 AM

All this bashing from someone with little experience in php. Funny you dont mention your experience with coldfusion.

Coldfusion is a notoriously bad framework that allows you to do stupid easy things quickly and then takes forever to do anything real. Talk about arrays not being implemented properly, coldfusion doesnt know what arrays are. A sort on two dimensional arrays sorts a single dimension only. It was obviously written by and for folks that have no programming experience or knowledge.

The reason I bring this up is you bash php, which you admit to steering clear of and yet you dont bash the much horribly worse language that you admit to using. So your argument boils down to "I dont know this very well, so it sucks."

Php is head and tails above most scripting languages. Yes, it has quirks, but they are logical and easy to work around, unlike most baby languages, where you spend all your time fighting the language/framework.
 

# posted by Anonymous : 11:34 AM

I developed in coldfusion for about a year because I was paid to do so. What's your excuse for using PHP so long that you've apparently become allergic to the obvious?
 

# posted by Jonathan Ellis : 12:35 PM

Is that your way of agreeing with me without saying it? You only used cf because you were paid to?

The obvious here is that you have limited experience with php and the flaws in php you put forth are trivial to work around.

CF sucks 10 times worse than php in exactly the things you bashed php for. That to me makes php a MUCH better choice over atleast cf.

The fact that you cant understand that obvious point makes your whole post suspect.
 

# posted by Anonymous : 6:23 PM

Grasping at "coldfusion sucks" as a straw man because I mentioned it along with 4 other web technologies is pretty weak. Nowhere did I say that CF was good technology; neither would I be writing CGI in C these days.

But PHP is a real train wreck, the sort, as I mentioned, that doesn't require long experience to recognize if you have a broader experience by which to judge it.
 

# posted by Jonathan Ellis : 8:11 PM

"Grasping at "coldfusion sucks" as a straw man because I mentioned it along with 4 other web technologies is pretty weak. Nowhere did I say that CF was good technology; neither would I be writing CGI in C these days."

That is why PHP is so popular. It is better (and cheaper) the CF -- and not as ancient as CGI.....No other technologies or web based scripting languages have really stepped in and claimed the ground that PHP covers. I.E. -- easy enough for the beginner to get their arms around and start using, but powerful enough to grow.

Granted, I agree with most of what you said -- but I fail to see any real alternatives in this arena.
 

# posted by sog : 2:29 PM

I use PHP quite extensively in my (day) job as a programmer at a radio station, and find the arrays to be immensely useful compared to other languages, even other web-based scripting languages. The fact that exceeding array indices is virtually impossible in PHP is immensely helpful, since it greatly simplifies the logic of the program, delegating bounds-checking to the preprocessor. Indexed iteration through an array is the only time I've accidentally overstepped the bounds, to my memory. I must also point out that large datasets rarely occur in PHP scripts; I cannot recall ever requiring an array of a size where the big-O efficiency was an issue; that sort of computation I generally leave to the backend data storage engines, which are already optimized for large datasets anyway. I do agree that the function libraries are designed in a vastly unstructured way, but this hardly bothers me; perhaps this is only because I have a good memory for function names.

Software engineers who point out superficial problems with a given language (like inconsistent function names) always seemed like pansies to me. The loose-typing of variables has never caused me too much grief (I just have a small library of type-validation code I've written for PHP as an include file--it works miracles), but the ability to dynamically create variables ex nihilo is a large source of subtle bugs arising from typos, and this is one of my major gripes about the language.

Magic quotes doesn't seem too horrible either; if you control your server, they are a nice shortcut. If you do not, simply encapsulate query string variables in a set of functions to properly escape or unescape them; you'd have to do it anyway every time you stored them in the database, so it's not any extra work at all, really. It is odd that your article complains of the time wasted on these things, which all have very quick remedies, when it ignores the time which would be wasted debugging array index problems, creating customized datastructures of great complexity where nested PHP associative arrays are much simpler, and other such things.

Granted, if you actually MUST use large amounts of data in arrays, I can see the problem of inefficiency . . . but why would you be using PHP for such things anyway?

No language is meant for all purposes. In the end, I find your arguments against PHP (the language) to be valid, but misdirected and, in some cases, trivially worked around. Your arguments about the management of the PHP project, however (regarding changes in APIs, initialization files, and other things), all have great merit; these sorts of problems are generally part-and-parcel to most open source / free software projects.
 

# posted by Anonymous : 2:39 PM

 

Once I was complaining about PHP to a colleague who then informed me that he had the unfortunate position of writing a lot of VB Script and I should be thankful for how lucky I was to be able to use PHP.

As for the PHP environment inconsistencies, this is a non-issue. 1) you can detect and correct the problems at runtime, and/or 2) you can change php.ini or modify php flags in apache when setting up a domain. It only takes 5 minutes. Compared to the hundreds of hours of programming I do, complaining about flags in php.ini is petty. Every other environment I have ever encountered has similar configuration issues -- be it flags to a C compiler, classpaths, or whatever.

As for the incompatibilties between PHP4 and PHP5, I have never seen this actually be a significant problem with any project. I have never seen code that actually depended on copy-on-set. All I have ever seen is &= statements to prevent it from happening, which are now just redundant code.

What is the internal structure of an array() ? I don't care -- it may as well be a linked list, because for any data set large enough to matter, I use a database.

The fact that PHP is an accretion of random features has two sides -- one its bad because everything is in a huge shared namespace and sometimes the argument style is inconsistent. but its also good because it means that PHP has a lot of features! Instead of worrying about how things are organized, a lot of work has been put into cramming PHP to the brim with every possible feature. That makes it easy to use -- no hunting for some module to import, its all just there.

Let me add that I *love* python, C, perl, mathematica and a bunch of other languages. Each of them have their moments -- just don't misuse them. I don't write web pages in C, and I don't write real-time interactive programs in PHP.

Finally, there are some really deep problems with PHP that also fall in its scope of pratical use (i.e. for web pages), but those problems are bigger than just PHP -- things related transaction processing on large scale and complex websites going from the browser all the way into the database. AFAIK the various "enterprise" Java products (JSP et al) come the closest to dealing with them properly.
 

# posted by Anonymous : 3:14 PM

 

I write lots of PHP code and I find annoyances:
* messy standard library. inconsistent arguments require often manual lookups.
* classes require use of $this-> for every method/var.

but some of your points are not valid or exagerrated:
* register_globals doesn't matter in well-designed code and it takes one line to remove magic_quotes.
* My PHP4 code just works on PHP5. Switch can be painful, but doesn't have to be. It depends on coding style.
* PHP, and its arrays, are fast. Fast enough for their purpose. PHP arrays flexible and easy to use. Programming speed is often more important (and expensive) than server speed.
 

# posted by kL : 4:08 PM

 

Writing portable code is not that hard if you know what you are doing. I assume that if you had problems with register_globals is because you were not using the superglobals in the first place, or HTTP_SERVER_VARS, or well...you kept the default install. I've been using superglobal arrays even back in the days when the default was ON.

I don't see how the magic_quotes represents an obstacle to writing portable code. There's plenty of functions to help you out: stripslashes(), ereg_replace(), set_magic_quotes_runtime(), etc
Just write a globally included script that deals with all submitted vars accordingly by processing the superglobals according to whatever the setting is. Not impossible, really.

Also, if you RTFM you'd know right away that foreach operates on a copy. And if all your complaints are because you want to use foreach() and you can't because it makes a copy first, then use a for() and stop whining. Babies are NOT dying.

don't get me wrong: I am not saying PHP is great. I am just saying that if you had the magic_quotes and the register_globals problem, is because you kept the default install. Ever since that setting was there, everybody I know set it to off when the default was on back in the 4.1 days or whatever.

If an user bothered learning how to properly install PHP instead of keeping the defaults like a moron, he'd have developed 10 lines of code and include them globally and never have the register_globals or magic_quotes problem again.
 

# posted by Anonymous : 4:58 PM

 

sorry, forgot one thing: I didn't mean to flame the post nor anything, I am just saying those reasons are not valid enough to say that PHP sucks.

Yes, I think it sucks, but those are not the reasons.
 

# posted by Anonymous : 5:00 PM

 

I've developed in PHP for about 5 years, on a number of hobbyist sites and several commercial sites. I tend to agree that the issues brought up in the post, but disagree with the apparent conclusion -- that PHP should be consigned to "teh suck" bin and used only by newbies. It has its advantages: huge libraries / open modules, the flip side of the poor orthogonality is a veritable everything-and-the-kitchen-sink feature set, the syntax hits a right point between the familiarity of C-derived stuff and flexibility of Perl (and avoiding, for the most part, the WTF? moments of Perl), large support community, choice of development styles. It's comfortable. Though I also see the appeal of Python, or Ruby.

The better title would have been "What Sucks About PHP." See Mark-Jason Dominus' "Why I Hate Advocacy" for hints.
 

# posted by Anonymous : 5:24 PM

 

The magic quotes and register globals issue is old, old, old.. And if your going to be naive about the particulars of a language then things are going to break aren't they..?

Im really fed up with peoples problems with PHP. Ive been programming for 20 years (C/C++) on Windows (flame, yawn), I have used Perl, which I quite like but it has its problems, elitism being a big one, ASP and PHP. I dont get on with Java, my preference.

PHP is good for web sites, thats what it is for. Yes, a lot of new programmers start off with it, it is easy to pick up. yes it is still maturing, and yes it will evolve and change.

Don't get me wrong, i DONT use it for everything, i use it when it suits the the job in hand.

How long are people going to bring up old issues? Is it that people are scared of the ease of use of this language and the influx of programmers it is bringing in? if it sucks so much you have nothing to worry about.

paul dot simmonds at gmail dot com
 

# posted by Anonymous : 1:36 AM

 

before this all becomes another flamed egos-war, I just want to tell you that you should have spent a little more time developing php before start complaining about it. There's so many things you can easily do with php that these pure beginner problems mean nothing
 

# posted by calin : 1:40 AM

 

php is absolutely fine. the choice of making it good and solid, or leaving it to feel like you're hacking in stuff rather than coding nice and clean, is entirely up to you. you can grab all of your programming concepts knowledge and apply it successfully in php to a good extent. it's practical, rapid to develop, and if you do it right, you can just leave it there and it will run without stopping. you can slag off just about any platform out there.
 

# posted by george : 2:49 AM

 

The problem I have with PHP that I can't work out how to fix is typos in variable names. If I type $choice one time, and $chioce the second time, but I wanted them to be the same variable, how can I get PHP to tell me about this?
 

# posted by Anonymous : 3:04 AM

 

I agree with much of what you've said, although I must take issue with one thing. You complain (justifiably) about cruft-by-accretion. How do you deal with that? You drop it in a major version hop. Which is what they did with the jump to PHP5 - threw out their brain-dead object model and brought in a better one. So I don't agree with your complaints against that move. -- Jon Dowland
 

# posted by Anonymous : 7:28 AM

 

My point was that with only a little thought in the early days, major breakage in PHP5 wouldn't have been necessary. (And even so they left some of the fundamental flaws alone.)
 

# posted by Jonathan Ellis : 7:57 AM

 

With regards to your comment of "I don't have any problems working around PHP's limitations so you must be wrong," Mr. Ellis, I must respectfully disagree. At least as regards the workarounds (not the fundamental design decisions of PHP's implementation itself, such as the argument over arrays versus hash tables), I would never consider something like avoiding register_globals or magic quotes or references to $this to be "flaws" in the language. I would consider them quirks. Indeed, some of these are pure syntactical issues, and nothing more than a matter of taste! While it may be tempting to initially respond that this is merely a matter of semantics, I find it not to be the case. A flaw is a fundamental problem with a language; other arguments in this thread may count as flaws, but none of those for which workarounds have been presented are flaws to my mind at all. They are features of the language that must be taken into account, when worrying about portability, just like C++'s nonstandard data types must be taken into account. In C++, you can never know the size of an integer or a long when writing (portable) code; it always must be discovered at runtime, since C++ sets no standard data sizes, only required minimum storage sizes. Yet C++ is a highly portable language, within its purview; if set data type sizes had been built in from the beginning, we'd never have pointers of 64 bits, after all; they'd be sixteen or smaller! Nonetheless, assuming that an "unsigned char" is one byte makes for hypothetically unportable code, though in reality this will always be fine, since it is such an established convention that no compiler writer would ever alter the size of the char data type nowadays. Bah, my mind wanders again. Anyway, the quirks mentioned are akin to, say, Visual Basic's automatic 1-based array indexing feature; it could be forced to index arrays at 0 with the "Option Base 0" directive, but this provided portability problems. Regardless, Visual Basic 6 was virtually the best language out there for what it was meant to do: rapidly develop business applications, whether simple or complex, where efficiency of execution time was not a major consideration; only morons would try to build applications in VB 6 which were computationally intensive, but to build a simple program for your secretary to track appointments or the like, no other language could compete.
I think what you have here is a similar idea of PHP as many had about VB 6; the superficial design quirks and flaws are blinding you to the power of the language, when applied in the right arena. When people tried to write huge, complicated, data-intensive systems in VB 6, they found it to be woefully inadequate; this should have been obvious at the outset! A language for which a function to add two numbers equates to 42 machine instructions is not designed for that, whereas C++ (with about six to twelve machine instructions, depending on architecture) most certainly is, as long as you know what you're doing. Similarly, array efficiency is only important if my PHP site is geting millions of hits a day, and if that were the case I would either stick with PHP but design a multi-tiered and distributed web-serving and data-management system, or write a C-based CGI application using some off-the-shelf CGI libraries to simplify my life. (The former is, incidentally, not as hard as you'd suspect, really; many large web businesses are somehow married to the fact that a $500,000 server will solve their latency problems, when a trivial array of a dozen or so older web servers would do the trick for less than three thousand dollars in hardware costs and setup; a distributed network of antiquated Sun Microsystems SPARC Ultra 1s, with clock speeds of 350 MHz (keep in mind they are RISC) will do amazing things, let me tell you, and they run about $50 apiece on eBay these days.) Well, I guess the point of all this rambling is this: end results are all that matter; I would rather have an efficient system in terms of time and money than an elegant one, and PHP is very fast to develop in (saving development and code maintenance costs) and is not significantly less efficient than other languages in time or space, when deployed in a reasonable manner and with a backend data architecture designed well. What irks me about the astonishing desire to make everything elegant, as opposed to quick to write or powerful, is the end result; you get encapsulation of data objects like in the .NET architecture. If I create some highly abstract "data connection" between half a dozen foreign key relationship fields in a database, and then the system gives me my dataset, I can guarantee that the SQL it generates will be hortribly unoptimized for any nontrivial query. If, instead, I use the simple DataReader class .NET provides, and supply my own SQL, I have an application whose SQL is harder to port, but which will run hundreds of times faster, making hardware costs minimal and latency very short. Encapsulation and other clean degisn principles are usually good, but I detest them when they make their way into the cores of complicated systems, since they are rarely ever efficient when applied to their logical conclusions. Considering the powerful refactoring tools available today, there is no excuse for writing methods to get and set variables inside classes that are private to other classes anyway, but are used in time-criticalm subsystems . . . if you REALLY must have encapsulated methods, refactor them in later. A good IDE can do it in a quarter second. I suppose, though, that refactoring applies less to PHP, since its object-oriented model is not very full-fledged in the first place, and since I am not aware of any good refactoring systems for the language. Nonetheless, the basic point remains valid; when you are worried about efficiency, use efficient language constructs (and to Hell with fluffy software engineering practices when time is really critical; the rest of the program can be software-engineered to your heart's content) and languages, or compensate in good hardware design (which is NOT the same as expensive hardware).
I do apologize for my rambling, but yesterday was my six-month anniversary, and so it was a late night out celebrating. Also, I should get an account here; these anonymous posts are confusing to follow clearly. Adieu!
 

# posted by Anonymous : 10:50 AM

 

One other thing, though; the idea that changing the php.ini settings is a valid way to overcome the portability problems of magic_quotes and register_globals and the like is astonishingly wrong. The original poster had the right idea about these as portability issues of some consequence, since not everyone hosts their own servers, and therefore not everyone has access to the initialization files and directive. It is best, if you are truly mindful of portability, to encapsulate these features out by simple functions (see? I'm not a total anti-encapsulation Nazi :-) ), or to presume they are always off in some cases where being on provides extra functionality, not different functionality from when they are off. While I maintain that these checks are not a fundamental problem, or even anything a programmer should be overly concerned about since a function call takes three seconds to type (and would be necessary anyway when dealing with escaping database field data; see my first (long) post about PHP in the radio station), the fact that you can "edit the options yourself" is not a valid solution to portability. On this, myself and the original poster certainly agree.
 

# posted by Anonymous : 10:57 AM

 

I've posted a response to your rant elsewhere:
http://www.daholygoat.com/jaws/html/index.php?gadget=Blog&action=SingleView&id=8
 

# posted by daholygoat : 5:21 AM

 

I find your entire article rather ignorant and somewhat school-girlish. How can you possibly be even remotely qualified to give any kind of adequate opinion on something you piddled with for a few days.

I've been developing using PHP as my primary language for over 6 years. I would totally agree that there are some annoying issues with it (as with all languages) and that the majority of the code I see out there makes me sick. However, like all languages, you need to use it for some time, get used to it's little nuances and expectations. And of course you need to adapt to new ways of doing things that you used to do in other languages. Some thing are easier, some are more difficult.

PHP, more that the other languages I've used, has been extremely flexible and has allowed me to be creative while allowing me to create very robust and complex systems.

Bottom line: An idiot is going to write idiot code regardless of what language he's using.
 

# posted by Brian Grayless : 12:48 PM

 

I'm a young developer (17, soon to be 18), and I have been working with PHP for close to 5 years. It was the first language I learned outside of HTML (granted, neither are programming, they're scripting). I agree with a lot you have said. I hate how features are just thrown in. I also hate how PHP5 breaks a lot of PHP4 apps. However, many work fine. I run a server with PHP5 and rarely have trouble running anything on it. And if it doesn't work, no big deal. Most of the stuff I look at is to poke around in anyway. I've been looking around at Rails and I like what I see. Sadly, PHP is a lot more common on web servers than Ruby/Rails.
# posted by James Logsdon : 7:17 PM

 

Hey Ellis, it could also mean that you are inexperienced and see a problem where there isn't one, or that you are overrating a design annoyance.


All languages have design flaws/annoyances somewhere along the road. Some people can see more contingencies ahead and do a system design that contemplates them, and others just complain about magic quotes in their pajamas while having chocolate icecream.

To me, when someone says "language X sucks" is a sign that they are language Y advocates, and discussions like that often lead nowhere.
# posted by Anonymous : 6:19 AM

 

Humor

BBspot - Student Suspended Over Suspected Use of PHP By Brian Briggs

Topeka, KS - High school sophomore Brett Tyson was suspended today after teachers learned he may be using PHP.

"A teacher overheard him say that he was using PHP, and as part of our Zero-Tolerance policy against drug use, he was immediately suspended. No questions asked," said Principal Clyde Thurlow.   "We're not quite sure what PHP is, but we suspect it may be a derivative of PCP, or maybe a new designer drug like GHB." 

Parents are frightened by the discovery of this new menace in their children's school, and are demanding the school do something.  "We heard that he found out about PHP at school on the internet.  There may even be a PHP web ring operating on school grounds," said irate parent Carol Blessing.  "School is supposed to be teaching our kids how to read and write.  Not about dangerous drugs like PHP."

In response to parental demands the school has reconfigured its internet WatchDog software to block access to all internet sites mentioning PHP.  Officials say this should prevent any other students from falling prey like Brett Tyson did.  They have also stepped up locker searches and brought in drug sniffing dogs.

Interviews with students suggested that PHP use is wide spread around the school, but is particularly concentrated in the geeky nerd population.  When contacted by BBspot.com, Brett Tyson said, "I don't know what the hell is going on dude, but this suspension gives me more time for fraggin'.  Yee haw!"

PHP is a hypertext preprocessor, which sounds very dangerous.  It is believed that many users started by using Perl and moved on to the more powerful PHP.  For more information on how to recognize if your child may be using PHP please visit http://www.php.net.

Copyright © 1996-2009 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Disclaimer:

Last updated: August 15, 2009