One of the consequences of the huge popularity of Zend Framework is that everyone who is using PHP in one way or another has at least thought about using it (because it all sounds so good and, possibly, easy).

But different people need different approaches to start developing with Zend Framework. And the publishing companies that published the first books about Zend Framework (and apparently also the second wave of books) tend to forget about some groups of users. A little summary (in no way meant to offend):

Developers with a different background (another programming language)

Depending on the background, migration will not be that hard. I can imagine a .NET or Java developer easily gets the principles of a framework (and hopefully also understands OO programming). Ruby or Python will be even easier (but why on earth would they migrate?).

The average PHP developer (not already using Zend Framework of course)

If the Zend Framework manual is not sufficient for this group, there certainly are a lot of books available that eliminate all barriers. Of course look for the most recent books, since a lot of versions have been announced the last 2 years and, to be honest, some of the early books were published in a hurry to benefit from being among the first.

Dreamweaver users (often called “webdesigners“)

Yes, this group is also (willingly or unwillingly) pushed to, at least, have a look at Zend Framework. And to be honest, at the moment, I wouldn’t know how they can prevent themselves from creating something that isn’t maintainable in the years to come.
Zend Framework (or any other framework in this case) promises a lot of good things (which may lack in the current PHP snippets, Smarty templates, open source CMS,… now being used). Starting with the manual certainly is tricky. Getting a thorough grip of PHP/OO concepts may sound boring, but you need it.
As a suggestion: don’t set too high expectations and take your time. It may be useful to force yourself to get a PHP certification. Not because you need it, but because it forces you to learn/refresh the PHP basics.

Also: be honest to yourself. If you notice OO concepts don’t interest you, think about it and maybe try something else. Another lightweight framework like CodeIgniter (there is no such thing as “the best framework”) or no PHP development at all may better suit you. No one has ever been happy forcing themselves in a position doing something they don’t like to do!

Dummies

Belonging to this group is no disadvantage. Ok, you don’t have the experience of someone who has been using PHP since before the dot-com bubble burst, but at least you acknowledge this. Starting from scratch (and knowing it) can eliminate a lot of barriers.
Start by learning PHP and fairly early start with a decent PHP OO book and, again, take your time. In my opinion you don’t have to finish 5 courses and 3 books to start with Zend Framework. When learning Zend Framework (e.g. from the manual) you’ll also learn OO principles and best practices, but you need a basic knowledge first.
Also don’t expect that you can add new Zend Framework components on day 2, it will take time.

Did I forget about someone? I certainly hope this post can help as a starting point for new Zend Framework developers (or people thinking about becoming one).

Working with gettext as your translation engine your project? In need of a rough translation of your application for a mockup/preview/…?

Paul Dixon offeres a free service that automatically translates a gettext PO file with Google Translate. I personally use gettext a lot because of its speed and ease of use (with poEdit) and this will certainly be of use.

Of course the results should not be used in a production application.

Although I must admit I didn’t notice it, less than 2 months after it was decided to create a new version for Propel, it was actually released.

Last week, on the 8th of November, the new 1.4.0 version has been released for production use. Additionally they also set up a blog to prove Propel is still very much alive.

Propel 1.4 is a backwards compatible evolution of Propel 1.3. It offers lots of bug fixes, some very interesting new features, speed enhancements, and a very simple upgrade path: rebuild your model after updating Propel, and your application works as always. Except it works better…

It all sounds to good to be true!

A first migration of a project to this new version went smoothly: remember to remove the *-classmap.php file that was generated by 1.3.0 because it has been integrated in the main config file. It’s also recommendable to delete the /map sub-folder in your models folder because 1.4.0 generates newly named *TableMap.php files.

Also good to have: full query logging (Propel 1.3 switched to PDO and lost this feature but it’s back!).

I must also admit I have never actually implemented Doctrine, but that’s also because I haven’t found a reason while using Propel.

Another project: last week I finalized a Google Maps integration with an overview of my client’s members and the status of their membership.

VSK (or the Vlaamse Scholieren Koepel) manage their member schools through a web interface and because they had addresses of each school, it was a logical step to show them on a Google Maps overview:

While the result will definitely come in handy for them, implementation is not spectacularly difficult. The fact that the hosting was fixed on PHP 4.x caused a bit more “fun” though!

This can save some time searching: to center a map on a set of markers (like with the county selection above) your must first center it on a set of fixed coordinates.

I finally tried Zend Server Community Edition as a replacement of WampServer (or XAMPP) for local development.

While Zend Server proposes to be the perfect solution for any environment, I specifically tried it as a development stack on Windows machines. The use and usefulness of course completely differ in any other scenario.

First of all (and of great importance if you ask me): it is clean, simple and easy to use from A to Z. The installer provides the right options but not too many, the dashboard (control panel) is slick and provides quick access to settings you don’t often find in any other “server packages” and last but not least it performs much better due to the use of FastCGI on Windows.

2 less-frequently used features I missed though:

• A way to set up VirtualHosts in the dashboard.
• A WampServer-like way to switch between PHP (and in a lesser extend Apache) versions.

In total, the fine packaging almost got me convinced to replace WampServer.

Almost… because the choice for FastCGI on Windows also has one major disadvantage: you cannot use php_value settings inside your Apache/VirtualHost configuration. I especially like this since it avoids setting include_path, display_errors, upload_max_filesize and the like inside your scripts or .htaccess (which in some setups causes it to be parsed at every request).
Doing this in Zend Server on another platform isn’t a problem, since they use the PHP Apache module instead of CGI but that means you do not have similar environments and that is the complete opposite of what we want.

So it ended with a deinstallation. On the other hand: I can really see the benefit of this package for live/production environments. With it’s included optimization tools it takes a lot of configuration hassle away.

Popular and widespread in Japan, QR codes (a variant of the well-known bar-codes) certainly provide many opportunities.

The QR code was invented by Denso Wave, Inc of Japan in 1994. They appear on many product packaging in addition to “normal” bar-codes for shipment tracking and other purposes. When scanned, these codes can return numbers and text (e.g. the URL to this blogpost in the example image). The camera on your mobile phone and dedicated scanning software do the rest of the magic.

While their ability to be a link between the “online” and “offline” world can provide many opportunities, it hasn’t really become the hype it could be outside of Japan. Practical implementations are rare. Most likely because of the lack of knowledge by the broad public. Although QR reader software is freely available and a July ‘09 research by the University of Essex stated that 68% of UK phone owners can install such an application, most have not.

The biggest difference between the numerous free QR readers (for about any phone brand/model) may be the image quality needed to recognize a code. I’m happy with the  speed of NeoReader but there are also Kaywa Reader and QuickMark barcode reader (among others).

Besides Wordpress plug-ins and support in the Google Charts API, there is a PHP library but support in the Zend Framework could stimulate its use even more (Zend_Gdata_Chart anyone)?

Some more implementations:

• Facebook Add to Friends.
• Viral advertising campaigns.
• Share contact information.
• TV to website link (Dutch).
• … any other examples? Please share them in the comments.

One useful tip is to shorten URLs through one of the many URL shortening services there are. This generates a smaller, less prominent QR code.

With every new Zend Studio release (still beta) comes a new PDT version: this time based on Eclipse 3.5 Galileo.

While Eclipse Galileo brings some nice new features and bug-fixes (of which many are not important to PHP developers, but nonetheless) PDT actually impresses the most with PHP 5.3 support: syntax coloring and validation with namespaces awareness. More about this in the release notes.

The best news in my opinion: since the software/plugin/update manager of Eclipse underwent some major refactoring, it’s biggest disadvantage may as well disappear! The only sane way to upgrade from 3.4 (or older) to 3.5 is still: delete your old version and unpack the new one, but lets hope this was the last time…

And last but not least: Mylyn integration got even better (I really need to dedicate a post to this).

Be sure to try the new PDT version!

After upgrading your WampServer with the latest phpMyAdmin of the 3 branch, you may not be able to sign in and instead get an “Access denied” message while everything was running smooth with phpMyAdmin 2.

This is caused by a new security feature in phpMyAdmin 3 which by default does not allow access as root without a password for the ‘config’ authentication type.

I do not have to explain why this was introduced and noone will state it isn’t a good addition. However, if you are developing on localhost and using the default WampServer set-up, you will not have a MySQL root password set. It has the advantage each of you local projects only require a database name.

If you want to circumvent this while not setting a root password, instead set the ‘AllowNoPasswordRoot‘ setting to true in your config.inc.php:

$cfg['Servers'][$i]['AllowNoPasswordRoot'] = true;

Update: since version 3.2.0 (?) a second setting is required:

$cfg['Servers'][$i]['AllowNoPassword'] = true;

Yesterday I gave a PHP enterprise development introduction to the nice people at zap all people about the various tools available to be more productive, produce better results and have more PHP fun.

While I don’t like to call it “enterprise” development because anyone can work this way (In most projects for my clients I am the only developer), enterprises are of course obliged to work in a more structured way.

The topics we discussed were:

• Local development (with WAMPSERVER, on Windows in this case)
• Debugging with Xdebug
• Eclipse IDE (PDT and others)
• Subversion
• mod_rewrite
• Zend Framework (& OO best practices)
• Unicode (UTF-8)
• ORM (although we were out of time by then)

There are probably numerous other tools and standards that could improve PHP projects, so I of course don’t state this is the perfect list. In my humble opinion, working with an environment similar to this one could give awesome results (especially in a team, but again, also as a single developer).

Something I didn’t mention was a useful bugtracker. Although, for my own projects, I prefer a simple todo-list. Maybe that’s something for a future session.

Any other suggestions to the list are highly appreciated.

Since every developer has probably struggled with data encoding once in their career, a short summary “how to get your data in and out of a MySQL database with PHP”:

• When you create your MySQL database, set the collation to one of the UTF-8 options (e.g.: utf8_general_ci). If you have no rights to create or change your database, do this on the table level.
  Note: if you use phpMyAdmin, it’s good to set your “session” encoding to UTF-8 before you sign in (although I believe this is now the default). Otherwise perfectly good data could look weird.
  
• Secondly, when you create a database connection in PHP, be sure to set the character set of your connection to UTF-8 by executing
  

  SET NAMES 'utf8'

  (notice the missing dash). Some extensions/adapters may have a method to do this (e.g. PDO) or allow you to pass it as an option.

• Third, save your PHP script/file as UTF-8 no-BOM (no byte-order mark since UTF-8 does not have byte order issues).
• Last, but most important & applicable to many more projects: set the charset of your page through the HTTP header. e.g.:
  

  header('Content-Type: text/html;charset=utf-8');

  Note: do not use the <meta> tag (solely) for this.  Only using the meta tag causes most browsers to start re-parsing your content once they notice it’s UTF-8 instead of their default assumption. This only slows down page loading.

This post is certainly not meant to be a Unicode manual but it can be a quick reference when you every wonder why you see those strange characters in your database.