Today I decided to provide a brief introduction into using SQLite compared to mySQL for PHP and webserver environments.

Traditionally mySQL is first choice when developing a dynamic website with PHP. Recently SQLite is another database system (I intentionally don't call it a database server, see below for reasons why) getting very popular. SQLite has two main usage areas: Webservers (mainly with little performance requirements) and applications.

Today I eventually started optimizing the performance (thereby reducing server load a bit). It appeared some pages of my larger websites have grown to round about 300 kb causing some latency for lower bandwidth visitor. Having a quite good connection myself, I didn't care about that much in the past. But that's ab pity, because it is very simple to add compression to pure PHP-generated content.

Handling date and time in PHP makes most coders nervous. There are a bunch of functions playing arround with system time and timezone features, using UNIX timestamps and therefore are very limitted in application. At least I know a lot of guys born before 1970. Native Unix timestamps may be of great use for system level stuff like logging information or handling object lifetime, but not for real world scenarios: handling user age or historical events is impossible with 32 bit UNIX timestamps.

Goto or not to go?

Goto is a very controversial programming statement. When discussing goto, some programmers talk about "spaghetti code" and think of BASIC, others answer with "performance" and think of C.

I'm one of the latter guys. My attitude to coding is, the coder should be able to decide what's the best way (in any means) to achieve the development goals.

Okay, there are only few good reasons to use the goto statement. Actually I can think of only one good reason: leaving a function at its end and place a generic cleanup there ("single point of exit").

Example:

PHP 5 introduces the E_STRICT error reporting constant. The PHP manual states "Enable to have PHP suggest changes to your code which will ensure the best interoperability and forward compatibility of your code.". Thus it's recommendable to enable strict PHP errors.

About strict mode (E_STRICT)

Enabling the strict mode is done via the INI file (php.ini) or via code during runtime:

  ini_set('error_reporting', E_ALL | E_STRICT);

The above code sets error_reporting to E_ALL and E_STRICT, because E_STRICT is not part of the E_ALL constant.

Smarty templates are a very useful tool and I'm addicted to Smarty for a couple of years now. All projects I did use Smarty templates. Now it's 2009 and PHP 5.2 is stable and has a good performance. Therefore I decided to use any of PHP 5's features when they come along my way.

Recently, Iterators came to close and I had to implement one. It's usefull for proxying and also for dynamically presenting views of lists. Therefore my implementation looks like:

class Foo {
  var $childs;
 

PHP from version 5 on provides reasonable object support. Well the language is not really object-oriented, but hey, it's a scripting language!

Recently I had the chance to implement the proxy pattern (one of my favourite design patterns) in PHP. My goal was to make object relations more dynamical. Lets start from a simple assumption of two kinds of objects:

class Parent {
 var $ID;
 var $Child;
}
 
class Child {
 var $ID;
 var $Parent;
}

As you'll notice, both classes reference each other. Parent points at Child and Child points to Parent.

This is a very short and quick solution for web designers. The situation of today is an style link becomes trashed when having any kind of white spaces just before the closing

Imagine a link like:

<a title="example">
 example
</a>

will result in a display like:
example 

This is a bug of all browsers I know, but there is a quick PHP fix for it:

$html_source = preg_replace( "/\s+<\/a>/i", "</a>", $html_source );

PHP might be the most often used Internet programming language. One reason might be it's so simple and docile even a beginner without much experience can use it.

When a website becomes older and mature, and starts to attract more people a day, many webmasters face a new competition: keep the scripts running, performing good enough to be usable to their visitors. This is the time where one has to think about performance-tuning PHP. One way to achieve better performance is, to plug in better hardware. Another way (the one we choose for this article) is to fine-tune the software side at PHP level.

Saying Joomla development is a trivial task would be a lie. You'll agree to that as soon as you recognize Joomla as a huge PHP Application Framework. And it of course always takes some time to get used to a framework like that. Incidentally that's the situation for all frameworks of this kind, whether it's Drupal, the Zend Framework or whatever software you like. So it's not just a Joomla property and no reason to choose another framework at all.