zend cache

zend cache overview

Site moved

I've decided to move my blog to another my domain (hosted by dreamhost), mainly because of the time wasted to format the text in my posts (very poor editor) and impossibility of uploading files.

Ufortunately it's not been possible to move the "google followers" to the new site (google limitation), so I've had to make another widget. If you keep following this blog, please join the new site (box on the right).
Also the feed is changed to http://feeds.feedburner.com/phpntips

The new address is:
http://www.phpntips.com/

Thanks !

Custom rules for zend standard rewrite router

In this post, an overview of Zend routing [official doc] and how set custom rule for routing (tested on Zend v1.10).

Routing is basically how zend associate URLs tothe controllers, actions and parameters of the application (similar to apache mod_rewrite but PHP based therefore much more powerful).

Default routing

As it is known, the default Zend routing uses the following schema:

[controller]/[action]/[var1name]/[var1value]/ [var2name]/[var3value]/ ... /[varNname]/[varNvalue]

If the controller or action are not specified, the ones with name “index” are used for routing.

How to set rules

First of all, all the rules have to be attached to the router, that can be returned by using getRouter() on the frontController object (obtainable with singleton: Zend_Controller_Front::getInstance()).

The router is an object of type Zend_Controller_Router_Rewrite, and contains the method addRoute($name, Zend_Controller_Router_Route_Interface $route)

So, we need to attach object of classes that implements Zend_Controller_Router_Route_Interface.

Static routing [zend manual]

The simplest is used for static for rules without variables inside:

$route = new Zend_Controller_Router_Route_Static('login', array('controller'  => 'auth', 'action' => 'login') );

After this rule is attached, the URL /login will be the same as /auth/login

Standard routing (with optional default and requirements on parameters) [official doc]

$route = new Zend_Controller_Router_Route('archivenews/:year',
        array('controller' => 'news', 'action' => 'archive', 'year' => ‘2010’ /*default value*/ ),
        array('year'=>'\w{4}')  /*requirement on parameter*/
);

• The string 'archivenews/:year' is the route. The placeholders starting with semicolon (just “:year” in this example) are variables ( that will replaced with the real values in the URL).
• The URL /archivenews/2008 will call the controller news, action archive, and will set the parameter ‘year’ to 2008 (obtainable with $this->_getParam('year') inside the controller).
• The URL /archivenews will call the same controller and action, with ‘year’ to 2010 (default).
• Validation: The URL /archivenews/20008 will not match any rule, as the validation fails. If the validation (third argument) is removed, the same URL will call the same controller and action with year set to ‘20008’
• Default value: If the default value is not set (item ‘year’ not present in the second argument), the rule /archivenews will not match

RegEx routing [main]

It supports regular expression inside the route instead of passing as a third argument (slightly faster than the previous one).

$route = new Zend_Controller_Router_Route_Regex('archive-news/(\d{4})',
 array('controller' => 'news', 'action' => 'archive')
);

With this rule we’ve defined the same rule as before, with no default values.

As you probably have noticed, the rule does not contain the name of the variable (:year). To get it, use $this->_getParam(1) as “1” is the ordinal number of the placeholder (regular expression) in the route.

Attaching rules to the router

As already said, the rules has to be attached to the router

$ctrl  = Zend_Controller_Front::getInstance();
$router = $ctrl->getRouter();
// use $route set above
$router->addRoute('routeName', $route); /*note: do not use the same route name for different rules or they will be overwritten and ignored*/

Post moved here:
Custom rules zend standard rewrite router

Inside wordpress: notes about common variables and functions to add extra features

I've recently used wordpress to make some simple web sites. Wordpress is a very fast solution when creating a blog or a site of which the requirements are just a subset of the wordpress features.

What we can do with wordpress: fixed pages, site news (that are blog posts), simple search, multi-level page and news content management, WYSIWYG editor, changeable themes, lots of free themes already available, url rewriting etc...).

Sometimes we need to extra customize the frontend aspect of the site/blog, and we have to modify the standard behaviour of wordpress. It needs to know a little how its atchitecture, how it works and some of its functions.

Obsolete architecture
Since the first wordpress was released on 2003, its architecture is still using a non OOP style and it has nothing to do with a modern framework, nor a MVC application. Lots of informations are kept in global variables and there are thousand of functions.

Folllowing, some my notes about its architeecture, in order to speed up any type of structural change or extra customization.

Loading chain and main global variables

Wordpress (v.2.9.2, the latest at the time of writing) loads the content in the following order/hierachy:

• index.php includes wp-blog-header.php that
  
  • includes wp-load.php
    
    • defines ABSPATH (root directory)
    • sets error_reporting
      
    • includes wp-config.php
      
      • defines db parameters, lang, prefix
        
      • includes wp-settings.php
        • unregister globals, fix ISS, check PHP versions and mysql extension
          
        • defines WP_CONTENT_DIR, WPINC ,WP_LANG_DIR
          
        • requires compat.php (defines function not existing in some PHP versions), functions.php, classes.php
          
        • includes wp-includes/wp-db.php that istantiates the global variable $wpdb (object of the class wpdb) with methods: get_row, insert, prepare, query,insert, update, etc...
          
        • includes wp-includes/cache.php that defines the functions wp_cache_add, wp_cache_get, wp_cache_init (initially called), etc...
          
        • includes all the other files in wp-includes
          
        • instantiates some global variables (often used)
          

          
          $wp_the_query = $wp_query = & new WP_Query();
          $wp_rewrite = new WP_Rewrite();
          $wp = new WP(); #defined in wp-include/classes.php
          $wp_widget_factory = new WP_Widget_Factory();
          $wp_locale = new WP_Locale();

          
          
        • init wordpress
          $wp->init();
          
    
    
  • launch wp() that launches $wp->main() (class WP)
    
    the method main() calls the other (quite self-explanatory) methods: parse_request (parsing of the URL and ), send_headers, query_posts (), handle_404 (), register_globals ()
    
  
  
  • includes wp-includes/template-loader.php, that depending on the content and user agent, includes the templates for homepage, or single page, or category etc...
    
    Functions used to switch the content and include the template:
    
    if ( is_home() ) { include( get_home_template() ); }
    
    if (is_page() ){ include( get_page_template() ); }
    
    [... the same with 404, search, single, category, date,archive,paged..]
    
    if ( is_feed() ) {
    do_feed(); }
    
    

How to customize the Homepage template:
In case the homepage is loaded (and the default template is enabled), the theme templates are loaded. For the homepage and default template, the file included is

/wp-content/themes/default/index.php.

These functions call the homonym methods of the global object $wp_query of class WP_Query (wp-includes/query.php). This object contains most of the variables needed for displaying the blog (posts, counting of posts and comments, type of page :single/archive/list/search/home/ query string, request, etc...

Some functions used inside the main template:
have_posts() #returns true if there still are posts to display in the current page
the_post() #get next post (iterator)
the_ID() #prints the ID of the post
the_content() #prints the content of the post


Other common and useful functions:
get_option($name) gets the options (using cache) from the DB table wp_options.
is_paged(), is_search(), is_category() and others: they return the correspondent boolean values in the $wp_query global object if the current page is respectively paged, a search page, a category page etc.. See other function (and methods) in the file wp-includes/query.php

To make queries:
use the object $wpdb (wpdb class), and execute the method query() on it. This variable is visible inside templates (as well as $posts, $post,$wp,$user_ID etc...)

$wpdb->query("delete from ...");

Post moved here: Inside wordpress variables functions extra features

sessions vs cookies with load balancer

It's a well known fact that HTTP is a stateless protocol and cookies are needed to keep the communication session.

When dealing with sessions with PHP, we have two main solutions:

- set manual cookies
One approach is using directly the PHP functions to set the cookies. When possible I don't use manual cookies(except than keeping an hash string for the user identity or keep the session after the browser is closed) as there are lots of issues (datas kept in the user browser so they have to be validated at each request, difficulty to store complex datas, browser compatibility or partial cookie blocking etc...).

- session functions
A much easier approach is using the session functions. The session is automatically managed by PHP and the superglobal array $_SESSION is available with persistent user datas, thanks to the session cookie automatically managed.
Advantages: data stored in the server, easy to save arrays and custom objects, superglobal array immediately available and semplicity in writing the code.
Disadvantages: not possible to keep it after the browser closes (except a custom save handler on disk or db) , not possible to specify URL path and domain for the session.

- server balancer issues -> cookies !
Today we had some issue with our server load balancer. We realize that it didn't support sticky sessions, so at every redirect (also to the same page because of some rules) the session datas (kept through session functions) were deleted. In order to meet a deadline, we set a manual cookie to keep the data needed.