Phlogger3 dev plan

Announcement: Active development of PowerPhlogger has been stopped as of August 2006.

PowerPhlogger has not had any active development for more than 2 years. The announced successor Phlogger3 will not be released. Also, I am not able to provide you with support for any previous version.
I am sorry about the bad news.
PowerPhlogger was a great project and it grew to a huge community of users and supporters. I really appreciate all the help and enthusiasm you brought towards this project.
During the last years I had to move on and focus on other projects. Sometimes it just seems that life's a bit too short for all the things I'd like to do...
All PowerPhlogger sites will stay online and the board on is still there. As long as you keep it running, PowerPhlogger will not die. Maybe, some day somebody will write a fork of PowerPhlogger and move on. I am looking forward to it.

take care, Philip Iezzi

Phlogger version 3 is going to be a near total rewrite of the current PPhlogger code base. We want version 3 to include at least the following:

The following is a tentative plan on how we can accomplish these steps and related notes.


PPhlogger2 was completely written in a procedural way. Code got pretty difficult to understand and variables were all mixed up. In Phlogger3 we're going to make use of OOP advantages such as encapsulation and class inheritance. The code will be more structured all over.

New filesystem layout

Because we are rewriting most of the code and introducing lots of new features we'll need a new directory structure. Here is the first draft of the new layout:

|-- images
|   |-- colorpages
|   `-- flags
|-- private
|   |-- inctxt
|   |-- lang
|   |-- log                <-- error/SQL logging
|   |-- messages
|   |-- settings           <-- general settings, db table definitions
|   |-- sql
|   |-- src
|   |   `-- lib            <-- class libraries
|   |       |-- db         <-- db abstraction layer
|   |       |-- dblang     <-- db specific SQL statements
|   |       |-- jpgraph
|   |       `-- js
|   |-- templates
|   |   |-- aq
|   |   |   `-- images
|   |   |-- black
|   |   |   `-- images
|   |   |-- classic
|   |   |   `-- images
|   |   `-- metal
|   |       `-- images
|   `-- ttf
|-- upgrade
|-- pphlogger.php          <-- logging script
|-- showhits.php
`-- index.php              <-- page front

Template system

The template system we have decided on is a simple but efficient class written by Ralf Geschke called Apolda Simple Template class. Out of several different systems which were tested, it was the fastest. It is easy to understand and just does as much as we need for PPhlogger. There is no overloaded class libraries like in other scripts.
Here is a draft of the new Phlogger3 layout with the corresponding template files:

Phlogger3 template layout

Sample code to parse a template:

$TPL = new Template('test.tpl');
$TPL->assign('page_title', PPHL_TITLE);
$TPL->assign('css_path'  , PPHL_CSS_PATH);
$TPL->assign('copyright' , 'copyright 2000-2004 PHPEE.COM');

New, faster Database Structure

A lot of preparation has been already done in the last 2.x versions of PPhlogger with the intention to optimize the DB structure.
All browser agent strings have been moved to a global table to avoid redundancy in the logs tables. Additionally, since v. 2.2.3, ipcheck-tables have been completely eliminated. A couple of other optimization has been done to avoid unnecessary redundancy. Changes concerning data-types have been done due to the integration of PPhlogger into various other DBS. See the "DB abstraction layer" section for further information.

DB abstraction layer

At the same time we are centralizing the code and getting it more organized we are also adding the DB abstraction code. We have tested a whole bunch of DB class libraries like PHPLIB, AdoDB, MetaBase, and the PEAR library. Finally we ended up writing our own class. None of those libraries satisfied our need and all of them were kind of oversized. Besides, performance was really bad with MetaBase.
Our DB abstraction code is located in /private/src/lib/db/.
Here are the basic methods to run a query:

$DB->execute("SELECT * FROM test_table")
while ($DB->moveNext()) {
	echo $DB->record['field1'];
	echo $DB->record['field2'];

If you need various different recordsets, we're going to use the getRecordset() clause:

$DB->execute("SELECT * FROM test_table");
$rs = $DB->getRecordset();
while ($rs->moveNext()) {
	echo $rs->fields['field1'];
	echo $rs->fields['field2'];

One nice thing at our library is the sqlhelper class. You're able to automatically create SQL queries with it. Just an example:

while ($SQL->db->moveNext()) {
	echo $SQL->db->record['field1'];
	echo $SQL->db->record['field2'];

All three statements above return the same result. There are various ways to access the DB library. Our goal is to create all queries using the "smart" sqlhelper class.
Currently Phlogger3's DB abstraction works with the following database systems:

We will be starting on Oracle soon.

Own Session Management

In previous PPhlogger versions we were using PHP4's built-in session management in combination with a simple cookie-workaround for those who were still running PHP3. Session management in PHP4 is simple and one of the best added features in PHP4. Though, a lot of people had problems with the built-in session management. There are people running PPhlogger on badly configured servers where the administrator doesn't even care about an essential thing like session management. It is up to the server administrator, where session data gets stored. This configuration can only be done in PHP's configuration file php.ini. On some servers it was working, but on the other side garbage-collection of old session data was badly configured. Another negative part in PHP4's session management is, that on some machines (mostly Win32 PHP builds), session_start did not work correctly, if the register_globals switch was set to Off (and it should be Off due to security reasons).
An own implementation gives us the chance to leave it up to the PPhlogger administrator to control garbage-collection. We have implemented session management on the DB side. Authentication values are also stored in the session.
example of PPhlogger's session handling:

// create new session object and start session
$SESS = new Session();

// get a session variable
// set a session variable including its value
$SESS->set('auth', 'value');

// store session (write back to DB) - call this at the end of the page

XHTML/CSS compliance

All Phlogger3 output should be 100% XHTML & CSS compliant. Standards are getting more important than ever on the web and we are trying to get a clean XHTML output. As we started to work with a template system, this is getting much easier to realize than as it was before, when PHP and HTML/XHTML was all mixed up.
All Phlogger3 code will be validated by W3C's original validator on To validate this page, you might as well click on the bottom-right button.
Here's the doctype tag we are going to use in Phlogger3:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
<html xmlns="">

PHPdoc comments

As everyone knows from the JAVA world, there is a cute standardized documentation method called JAVAdoc. PHPdoc is an adoption of JAVAdoc to the PHP world. It offers a way to generate an API documentation of object oriented and procedural code with certain markup in your source. PHPdoc is an Open Source Project and gets distributed under the PHP Licence.
All PHPdoc comments start with a /** and contain specific tags like @param, @return. Look at the following example:

* first Line: short description as overview
* multi-line optional part.
* order: overview sentence - comment - tags.
* @param  string   description of parameter.
* @param  string   another parameter...
* @param  integer  a parameter with type integer
* @return boolean  return value
* @see    blockIP(), $ipFormat
function isValidIP ($ip, $blockedIPs = '', $test = 0) { ... }

You find an overview of most documentation tags on (in German).
PHPdoc's keywords are class, function, var, include (include_once, require, require_once), and define.

::: home | development plan | dev team | roadmap | CVS | about :::

Phlogger3 Development Team | ©2002-2004 - design by Philip Iezzi | Top
Valid XHTML 1.0! Valid CSS!