PHP by Book

Here’s how PHP developer declare a string, which is something very common in any programming language.

$my_var = 'hello world';
// or
$my_var = "hello world";

PHP Tricks

What if you do the following:

echo hello;

That appears to be correct … Well, it’s not absolutely correct. You’ll be “noticed”.

// Notice: Use of undefined constant hello
echo hello;

However if you disable error reporting, the code will be completely fine.

error_reporting(0);

// no problem now
echo hello;

Variations

What follows from the thing above is that you can use strings without quotes:

// hello
echo hello;

// hello world (concatenated)
echo hello . ' world';

// helloworld
echo hello . world;

However you can’t have spaces and most of the “special” symbols.

// syntax error
echo hello world;

// syntax error
echo hello!;

Final Words

Although you can do this in PHP, that is completely wrong. The code becomes more difficult to read and understand. In the second place you can miss a $ sign in front of a variable declaration and thus the PHP interpreter will assume this is a string. So disable error reporting isn’t so great sometimes.

Typically a PHP programmer will write his SQL query as a string and will execute it via mysql_query.

$sql = "SELECT * FROM my_table";
$resource = mysql_query($sql);

So eventually when you want to dump this “complex” query, or whatever query there is, you can simply “echo” it and see what’s its syntax.

// this query is WRONG because of the where clause
$sql = "SELECT * FROM my_table WHERE id = ";

// dump and debug the wrong query
die($sql);

// this line won't be executed
$resource = mysql_query($sql);

So far so good, but things appear to be a bit different when you start to work with Zend Framework. Higher levels of abstraction come with slightly more difficult ways to dump (debug) your SQL queries.

OK you’ve two options. Using Zend_Db_Select or … not.

Dump Zend_Db_Select Query

Debugging queries generated with Zend_Db_Select is as easy as the following snippet. Let’s say there’s a db table “users” and typically the model is called Users.

class Users extends Zend_Db_Table
{
	protected $_name = 'users';

	public function getSomeUsers()
	{
		$select = $this->select()
				->from(this->_name)
				->where('id > ');

		$rows = $this->fetchAll($select);
	}
}

Obviously this code is wrong, because the “where” clause is wrong and we don’t pass any values to it. So now the question is how can we dump this SQL. Well, since we use Zend_Db_Select, so the simplest way to dump the SQL is by calling __toString(). The code above will become as follows.

class Users extends Zend_Db_Table
{
	protected $_name = ‘users’;

	public function getSomeUsers()
	{
		$select = $this->select()
				->from(this->_name)
				->where('id > ');

		die($select->__toString());

		$rows = $this->fetchAll($select);
	}
}

That’s great, but how can we dump update/insert queries for instance?

Dump with Zend_Db_Profiler

The way you should dump insert or update queries is a bit different. You should use Zend_Db_Profiler, which is a more complex way to debug (profile) your queries. You can not only debug insert or update queries, of course, but any queries generated by the Zend_Db abstraction. Let’s see how.

Now from a controller perspective this model can be just called as:

$users = new Users();
$users->update(array('name' => 'my name'), 'id =');

Obviously this code is wrong, again because of the where clause and now the question is how we can debug the generated SQL. The answer is: using Zend_Db_Profiler. Looking back again to the model, this should look like this.

class Users extends Zend_Db_Table
{
	protected $_name = ‘users’;

	public function updateSomeUsers()
	{
		// first enable the profiler
		$this->getProfiler()->setEnabled(true);

		// try to execute
		$this->update(array('name' => 'my name'), 'id = ');

		// dump the SQL
		Zend_Debug::dump($this->getProfiler()->getLastQueryProfile()->getQuery());

		// don't forget to disable the profiler is
		// you don't need it anymore
		$this->getProfiler()->setEnabled(false);
	}
}

The thing is that since Zend_Db is using prepared statements, the last row (the one with the Zend_Debug::…) will dump something like the following line.

UPDATE `users` SET `name` = ? WHERE (id =)

So as you can see, actually here you don’t see the name’s value, which should be “my name”. To see this you should call getQueryParams().

class Users extends Zend_Db_Table
{
	protected $_name = 'users';

	public function updateSomeUsers()
	{
		// first enable the profiler
		$this->getProfiler()->setEnabled(true);

		// try to execute
		$this->update(array('name' => 'my name'), 'id = ');

		// dump the SQL
		Zend_Debug::dump($this->getProfiler()->getLastQueryProfile()->getQuery());
		Zend_Debug::dump($this->getProfiler()->getLastQueryProfile()->getQueryParams());

		// don't forget to disable the profiler is
		// you don't need it anymore
		$this->getProfiler()->setEnabled(false);

Now the debug info will be something like this.

UPDATE `users` SET `name` = ? WHERE (id =)
array
	1 => string 'my name' (length 7)

Calling this from the controller there are some changes. Take a look at the example bellow.

$users = new Users();

// enable the profiler
$users->getAdapter()->getProfiler()->setEnabled(true);

// execute (or at least try to)
$users->update(array('name' => 'my name'), 'id =');

// debugdump the SQL
Zend_Debug::dump($users->getAdapter()->getProfiler()->getLastQueryProfile()->getQuery());
Zend_Debug::dump($users->getAdapter()->getProfiler()->getLastQueryProfile()->getQueryParams());

// don't forget to disable the profiler is
// you don't need it anymore
$users->getAdapter()->getProfiler()->setEnabled(false);

In this case you should use the longer model_name->getAdapter()

Usually Zend_Cache is used to store cache files on the file system, which can be really fast and useful in most of the cases. However there’s a faster cache mechanism and hopefully it’s supported by Zend_Cache as well. This is the Memcached backend.

A Faster Cache

Memcached is a really powerful tool to cache directly into the RAM. First, this tool has nothing to do primary with Zend Framework. It’s a server, usually started on some port, that can be called to store and get things from the memory. This of course is very fast, way faster than the cache in the hard drives.

Zend_Cache and Memcached

Zend_Cache has an interface to work with Memcached which is great as usual. The PHP example of Memcache (note that there are two things Memcache and Memcached, which are slight different) can be found here and as it says:

$memcache = new Memcache;
$memcache->connect('localhost', 11211) or die ("Could not connect");

$version = $memcache->getVersion();
echo "Server's version: ".$version."
\n";

$tmp_object = new stdClass;
$tmp_object->str_attr = 'test';
$tmp_object->int_attr = 123;

$memcache->set('key', $tmp_object, false, 10) or die ("Failed to save data at the server");
echo "Store data in the cache (data will expire in 10 seconds)
\n";

$get_result = $memcache->get('key');
echo "Data from the cache:
\n";

var_dump($get_result);

However this can be coded into a Zend Framework style like that:

$frontend = array('caching' => true, 'lifetime' => 1800, 'automatic_serialization' => true);

$backend = array(
    'servers' =>array(
        array('host' => '127.0.0.1', 'port' => 11211)
    ),
    'compression' => false
);

$cache = Zend_Cache::factory('Core', 'Memcached', $frontend, $backend);

Note that you don’t have the typical “cache_dir”, just because everything’s cached into the memory.

Now you can call the cache as it’s called with the “File” backend interface:

$key = 'mykey';

if (($result = $cache->load($key)) === false) {
	// call the slow database query here ...
	// save in $result
	
	$cache->save($result, $key);	
}

echo $result

However FFMPEG is a converting program and many things depend on what kind of video files come as an input and what do you want to achieve as an output. Here comes the codec question, where various libraries can help. In my case, as I wrote few posts ago, I use MP4 as output encoded with h.264, both encoded with ffmpeg/libx264. So far so good, but there is one main problem that anyone used this pair knows.

Flash Player and MP4

As far as I know Flash Player 9 and beyond plays video files encoded with MP4/h.264 except the typical FLV (flash video files). This can help video sites not only to share their video content via web – within browser based flash players, but also to show them via some mobile device interface where MP4/h.264 is perhaps the only one reasonable solution. In this case the file is accessible in both medias.

By default Flash Player can play such FFMPEG encoded .mp4 files, but fist the whole file must be downloaded by the browser and only than the playback can begin. That’s because the FFMPEG puts meta info at the end of the video file, while the flash player needs it at the beginning and only than to begin playing while the file is still downloading.

qt-faststart

As the name of this software says this program helps you move the important meta info from the end to the beginning of the file. This helps the video to playback as early as possible. In an ideal circumstances everything works just fine, but there is a serious problem in fact.

qt-faststart and Server Crash

qt-faststart is responsible to move the meta info where it must be – at the beginning of the video file, but cannot finish execution when the video file is broken or the meta info doesn’t exists. Actually this is not a problem of qt-faststart, but to the video file. However this was a critical problem in my case, because the video files remains stuck for hours of execution and 99% of CPU usage.

Thankfully there is a solution and it can be found in the qt-faststart wrapper – qtfaststart.py

qtfaststart.py

written on Python this script overcomes the disadvantages of qt-faststart. As described by his author Daniel G. Taylor:

Works everywhere Python can be installed

Handles both 32-bit (stco) and 64-bit (co64) atoms

Handles any file where the mdat atom is before the moov atom

Preserves the order of other atoms

Can replace the original file (if given no output file)

With its help not only qt-faststart doesn’t crash, but also the video files remain progressive as desired. The installation process is as difficult as copy/paste on the server where Python must be installed.

First of all there are several things to know about Zend Framework and caching. Whenever you work on a big web application caching is one of the mostly used mechanisms of speeding up the app and improve user performance. In general the task and the solution are pretty simple and natural.

As the application grows up the visitors become more and more impatient about what they receive. A single page is becoming slower and slower and the result is painful. First of all every time a user hits a page the application server uses the web server, a script interpreter, a database server and potentially the file system. But that’s not all. After all this output is generated on the server, as HTML in the most cases, it is sent to the client where again CSS and JavaScript engines parse and execute them.

In this scenario it’s easy to imagine how many time is spent. While there are several techniques to optimize the client side by optimizing JavaScript, CSS and the static images used for the design of the site, here I’m going to talk more about the backend.

Beside the Optimization

Let’s assume we’ve one of the very used combination between Apache (as a webserver), PHP (as server scripting language) and MySQL (as database server). Here you can choose to optimize all three of them. However beside the optimization of them one of the most simple steps you can do is to cache the output generated by these three branches of your web app.

Caching the Content

In fact you can cache only single parts of the whole process. For instance you can cache only the result returned by some slow database query. Let’s imagine a query takes about 2 seconds to execute. Now you can cache the result into a file and during the cache is active, i.e. it has not expired, the application takes it from a file stored somewhere in the file system.

In a typical Zend Framework scenario you can first setup the frontend and backend options of the cache.

$frontendOptions = array(
	'lifetime'                => 600, // in seconds - this is 10 seconds
	'automatic_serialization' => true,
);
$backendOptions = array('cache_dir' => 'cache/');
$cache = Zend_Cache::factory('Core', 'File', $frontendOptions, $backendOptions);
		
$cacheKey = md5('mykey');

if (!$cache->load($cacheKey)) {
	$slowQueryResult = $article->fetchAll();
	$cache->save($slowQueryResult, $cacheKey);
} else {
	$slowQueryResult = $cache->load($cacheKey);
}

You can setup different options here by setting up the cache directory, lifetime, etc.

Note that the cache directory must exists and with write permissions and Zend Framework doesn’t create it for you and will throw error.

The problem here is that now you cache only part of the generated content and in many cases this is still too slow for most of the users. However all the work (in most of the cases) of the web server, the script interpreter and the database server result in a simple HTML output. What if you have this output generated or cached for you and when the user hit the page the server will return this pre-generated code?

This is indeed very fast, because it’s similar to return a text file, as the HTML is simply formatted text.

Caching the Entire Page

Before I proceed, I’d like to say that I work with Zend Framework 1.9.x. Now in the latest versions of ZF there are new mechanisms of caching the output even Zend_Cache_Frontend_Page works fine on them.

You can simply setup the page cache within few simple lines of code:

$fo = array(
    'lifetime' => 600,
    'regexps' => array(
        '^/' => array(
	'cache' => true,
         'cache_with_cookie_variables' => true,
        ),
    )
);

$bo = array(
    'cache_dir' => 'cache/'
);

$cache = Zend_Cache::factory('Page', 'File', $fo, $bo);
$cache->start();

However my advise is to place this code as high as possible, because this will cache everything generated as output. It’s a good practice if you place this even in the bootstrap before you make the connection with the database. Actually you don’t need a database connection when you’ve to return a simple text(html) file.

This will improve your app’s performance a lot!

However there are few things to know. When you setup the cache to work even with cookie variables, you can see that hitting the page with different browsers Zend Framework will generated different cache pages. This is quite useless because than you don’t have any benefit of caching the content.

First of all let me say that THIS IS NOT A BUG! of ZF. Simply the framework will use the cookie variables to generate the cache key. It’s obvious that different browsers, even more different users, will have different cookie set and the framework will generate different cache keys for them.

Thus you’ve to change the setting to generate the cache key from cookie variable by explicitly set this option to false:

$fo = array(
    'lifetime' => 600,
    'regexps' => array(
        '^/' => array(
		 'cache' => true,
         'cache_with_cookie_variables' => true,
         'make_id_with_cookie_variables' => false,
        ),
    )
);

$bo = array(
    'cache_dir' => 'cache/'
);

$cache = Zend_Cache::factory('Page', 'File', $fo, $bo);
$cache->start();

Note that in this example we cache every single page generated by the framework explained in the regexps. This is not so good especially when the users have the possibility to login and to see customized content for them, so you can be careful what you cache.

A typical problem that this solution solves is when your application uses Google Analytics. As you may know Google Analytics sets up a cookie every time when an user hits the page, so every time the framework will generate a different cache for him and in result he won’t see any benefit and performance improvement from your site.

It’s strange how powerful PHP can be. There’s a legend that cURL is the only way to perform a HTTP POST with PHP, but that isn’t the truth. An extremely useful script is by using stream_context_create:

$optional_headers = null;
$params = array('http' => array(
                'method' => 'POST',
                'content' => http_build_query(array('name' => 'my-name'))));

if ($optional_headers !== null) {
    $params['http']['header'] = $optional_headers;
}

$ctx = stream_context_create($params);
$fp = @fopen('http://example.com/post.php', 'rb', false, $ctx);

Well this is only a snippet. You can change a lot this code and perform any request, but here’s a small start up. However note that this will do the same as while posting to example.com/post.php via web form!

Typically you’ve one module in your Zend App – the default one. In the basic installation of the framework, you put all the controllers, models and views directly in the application folder, as described below.

/application
	- /controllers
		- /IndexController.php
	- /models
		- /MyModel.php
	- /views
		- /scripts
			- /index/index.phtml
/library
	- /Zend
/public_html
	- /images
	- /scripts

Bigger Apps – More Code

When the application becomes bigger and bigger the controller, models and views/scripts directories contain more and more files. That’s a bit odd, because it becomes difficult to maintain, and than the modules come in hand.

Modules in a Zend App

When it comes to setting up modular Zend App there are tons of articles in the web, but let me show you a simple directory layout and … sample code that sets up the framework.

/application
	- /modules
		+ /admin
			- /controllers
				- /IndexController.php
			- /views
				- /scripts
					- /index/index.phtml
		+ /default
			- /controllers
				- /IndexController.php
			- /views
				- /scripts
					- /index/index.phtml
	- /models
/library
	- /Zend
/public_html
	- /images
	- /scripts

Source

Simply add this into the bootstrap:

$frontController->addModuleDirectory(APPLICATION_PATH . '/modules');

$mailTransport = new Zend_Mail_Transport_Smtp('smtp.gmail.com', array(
    'auth'     => 'login',
    'username' => 'xxxxxx@gmail.com',
    'password' => 'passxxxxx',
    'port'     => '587',
    'ssl'      => 'tls',
));
Zend_Mail::setDefaultTransport($mailTransport);

Simply by putting some JavaScript code into the view script wont do the job, because the .phtml file is grabbed and parsed by the Zend Framework and thus the code there wont be parsed as JavaScript and it wont be executed as well by the browser.

The Most Simple Way …

is to put some place holder into the layout .phtml file and than from the controller’s action you can assign some JS code:

// layout.phtml
layout()->scriptTags;
...

view->layout()->scriptTags = '';	
	}	
}

Solution No. 2

Although the first solution is correct it’s not the most clearest way, because you put the JavaScript code into the PHP, and this sooner or later becomes a mess.

view->layout()->scriptTags = '';
						  . '';
	}	
}

The IDE is not highlighting the code, and you’ve to deal with too many quotes, which is bad! There is a better solution however – the inline script:

// script tags
/* @var $scripts Zend_View_Helper_InlineScript */
$scripts = $this->view->inlineScript();
$scripts->appendFile('my.js');

Simply the Best

Yeah, the best solution is something even better than the second one. Although the solution I’ve just mentioned is fine for including JS files, when you’ve to add some JS code you’ll have to put it again into the PHP.

$msg = 'some dynamically generated message';

// script tags
/* @var $scripts Zend_View_Helper_InlineScript */
$scripts = $this->view->inlineScript();
$scripts->appendFile('my.js');
$scripts->appendScript('alert("' . $msg . '")');

If there’s no relation between JavaScript and PHP you can simply put all this code into a separate .js file and load it from there. This is by the way the best solution because the file is cached by the browser, if the cache is enabled. But most of the time you perhaps have to send some variables from PHP to the JavaScript code.

It would be perfect if you had some kind of a variable placeholders – exactly as you have it in the Zend Framework’s view scripts!

Another View

This is completely possible – just forget about the default view – it renders the view script and it’s bind to the /views/scripts folder. You can make another, completely new, view instead! Here’s some source:

$view = new Zend_View();
$view->setBasePath('path_to_the_js_folder');

$view->msg = 'Some dynamically generated message';

// script tags
/* @var $scripts Zend_View_Helper_InlineScript */
$scripts = $this->view->inlineScript();
$scripts->appendFile('my.js');
$scripts->appendScript($view->render('inline.js'));

Thus now in the JS file you can have some placeholders!

// inline.js

// some js code
// ...
alert('msg ?>');

if ($condition1 && $condition2 && $string1 == $string2 . $string3 && $string4 != $string5 . $string6) {
   // write some code here!?
}

It is ugly, isn’t it?

I’d prefer to make it clearer! What about that?

if ($condition1 
   && $condition2
   && $string1 == $string2
                . $string3
   && $string4 != $string5
                . $string6
) {
   // write some code here
}