<?php
	
	$blogPosts = getBlogPosts();
	$postsWithPictures = array();
	
	// The old way...
	foreach($blogPosts AS $key => $post)
	{
		$postsWithPictures[$key] = $post;
		$postsWithPictures[$key]['pictures'] = getPostPictures($post['id']);
	}
	
	// ...the anonymous function...
	$postsWithPictures = array_map(
		function($post) {
			$post['pictures'] = getPostPictures($post['id']);
			return $post;
		},
		$blogPosts
	);
	
	// ...and the lambda:
	
	$addPictures = function($post) { 
		$post['pictures'] = getPostPictures($post['id']); return $post; 
	};
	
	$postsWithPictures = array_map($addPictures, $blogPosts);

The final verdict on performance is still out — in theory the procedural style of foreach loops is slightly quicker than array_map, as the latter adds a function call to every iteration. We’re talking milliseconds here, and in this example getPostPictures() would probably slow down all three examples to an equally slow pace.

Closures as Function Arguments

Imagine you have a HTML helper function that generates anchors from a route…

<?php echo anchor('Blog/archive', 'Archive'); ?>

…using your framework’s Router library the result might look like this:

<a href="http://blog.com/myblog/archive.html">Archive</a>

In one particular case you need to alter the generated link slightly. You could hardcode that specific case into the function itself and add another parameter, or you could add a much more future-proof method of changing the HTML layout with a third, optional Closure argument:

<?php
	$wrapper = function($route, $name) {
		return "<span target=\"$route\">$name</span>";
	}
	echo anchor('blog/archive', 'Archive', $wrapper);
?>

The anchor function definition could look like this:

<?php
function anchor($route, $name, \Closure $wrapper = null) {
	if (is_null($wrapper)) {
		$wrapper = function($route, $name) {
			$href = MyFramework::getRouter()->resolve($route);
			return "<a href=\"\">$name</span>";
		}
	}
	return $wrapper($route, $name);
}
?>

This means you now covered all possible usage scenarios involving the layout of the generated HTML.

The typehint in the 2nd line (\Closure) “hints” at another fantastic new feature in PHP 5.3 — namespaces.

You should check out the latest development in Doctrine 2.0 for some real-world usage of namespaces.

All of it was shot with GoPro helmet cams and one “proper” HD cam. Best served cold, in 1080p and on a big screen:

Time well spent.

Toycamera AnalogColor does cross-processing per drag & drop. Download on the lower left of the website.

This template parser extends the existing Codeigniter Parser with inheritance and blocks, inspired by the excellent Django Python Framework.

Important Features

• Easy to use: See the example to get started,
• DRY: Never, ever repeat yourself in your templates again,
• Tiny footprint: Only one file necessary, drops right in if you were using the CI Parser before,
• Themes & Language: This class does simple theming and language variables.

DRY — Don’t repeat yourself

This simple parser aims to remove 99% of all code redundancy in your Codeigniter templates, without the complications of a much larger templating engine like Smarty. Inherit extends the Codeigniter Parser, is designer-friendly and relies entirely on a proven concept.

Repeating yourself is bad, even and especially in your templates. In PHP we are used to inheriting Classes to replicate certain functionality and have consistent functions and variables we can fall back on — it’s what makes Codeigniter so great. But the same should be true for your templates, shouldn’t it? Instead you write a lot of include("this") and include("that").

Maybe slightly worse, you might load header and footer in your controller and put them in variables for the view to use — making it difficult for the designer to trace back where that header content is coming from and how he can change it. Stick around and read the example to find out about a better solution.

Installation

Download the library, extract the contents to your system folder. Put it in your autoload config or load it in your controller. See the example below for a quick howto.

Example

Instead of needlessly splitting your website into a header, a footer, and everything in between we will now create a base template:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
	<title>{block="title"}My Website!{/block}</title>

	<link rel="stylesheet" href="css/style.css" type="text/css" />
</head>

<body>
<h1>Header!</h1>
<div id="content">
{block="content"}Default content, nobody probably reads this.{/block}
</div>
<p>{block="footer"}Footer, copyright me 2010.{/block}</p>
</body>
</html>

This is our base, all the different controllers simply extend it:

{extends="base"}

{block_prepend="title"}Home - {/title}
{block="content"}Hello World, this is my welcome page.{/content}

Now you simply call $this->parser->parse("welcome"); and the output looks like this:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
	<title>Home - My Website!</title>

	<link rel="stylesheet" href="css/style.css" type="text/css" />
</head>

<body>
<h1>Header!</h1>
<div id="content">
Hello World, this is my welcome page.
</div>
<p>Footer, copyright me 2010.</p>
</body>
</html>

Notice how it prepended the HTML title, left the footer alone and completely overwrote the content? It’s all thanks to inheritance, and it works just like it does in PHP5.

For a more “real-world” example, you could extend base.php with templates called one_column and two_column, then extend those with your pages. Now, if you ever wanted to add a second column to your welcome screen, just point the {extends} block to two_column, instead of one_column. It couldn’t be easier, and there is zero code overhead.

Performance Caveat

This is the first public release of Inherit. There’s gonna be bugs and there definitely are huge performance improvements waiting to happen. Neither stopped me from successfully using this library on several production websites. If you’re experiencing a high volume of visitors, wait until I put in Caching in the next major release. For your personal blog or portfolio it will probably hold up, performance-wise.

More Functions

Inherit includes a language file simply called “views”. In it you will find a multi-dimensional array of this format:

<?php

    $lang['welcome'] = array(
		'title' => 'My welcome title'
	);
	
	$lang['blog/index'] = array(
		'title' => 'My blog title',
		'archive' => 'View the blog archives'
	);

?>

The array associated with each view URI is available within that view as $lang. In this example, calling $lang['title'] on your welcome page will return a different value than calling it on your blog index.

Themes

Basically, calling $this->parser->theme('blue'); $this->parser->parse('welcome'); will attempt to parse the file views/blue/welcome.php. If it doesn’t exist, the default view is used instead (views/welcome.php). So even your themes inherit a parent, if you want them to.

Similarly, if views/blue/welcome.php extends a template, it will first look for that parent in views/blue/, then in the default theme folder (usually views/).

You can tell Inherit to look for the default views somewhere else, if you set the appropriate variable in MY_Parser.php. Watch this section for more comprehensive documentation in the future.

On the technical side of things, these were taken with a Nikon F4S and a Nikkor f5.6 50-300m zoom lens. Largely unaltered, the colors came out of the camera like that. Gotta ♥ analog.

“Sticky Footers” are containers that stick to the bottom of every page, no matter how much whitespace is between the footer and the preceding content. A popular method involves fixed height, negative margins & paddings as well as a number of hacks to ensure cross-browser compatibility.

Here’s how you adapt CSS Sticky Footer to the 960.gs Grid CSS Framework:

Quick Steps

1. Add the footer CSS to your 960.css
2. Search & Replace 150px in the CSS with the real height of your footer
3. You need the elements #wrapper and #content in your HTML above the footer (see example)

Before

This might be how part of your website looks now:

<body>
	<div id="content" class="container_16">
		<!-- Content -->
	</div>
	<div id="footer">
		<!-- Footer -->
	</div>
</body>

After

This sticky footer needs two surrounding wrappers above it, so go ahead and add another around #content. I’ve called it #wrapper in this example:

<body>
	<div id="wrapper">
		<div id="content" class="container_16">
			<!-- Content -->
		</div>
	</div>
	<div id="footer">
		<!-- Footer -->
	</div>
</body>

Here’s how the CSS should look, this example assumes your footer is 150px high.

/*  
Sticky Footer Solution
by Steve Hatcher
http://stever.ca http://www.cssstickyfooter.com
*/

html, body, #wrapper {height: 100%;}

body > #wrapper { height: auto; min-height: 100%; }

/* must be same height as the footer */
#content { overflow: auto; padding-bottom: 150px; } 

#footer {
	position: relative;
	margin-top: -150px; /* negative value of footer height */
	height: 150px;
	clear: both;
} 

/*Opera Fix*/
body:before { /* thanks to Maleika (Kohoutec)*/
	content: "";
	height:100%;
	float: left;
	width: 0;
	margin-top: -32767px; /* thank you Erik J */
}

Netbeans’ end-all feature and subject of this write-up is code completion. It truely shines when you hit Ctrl + Space. It neatly marks up, indents and auto-completes any combination of PHP, HTML, CSS & JS you throw at it — even if they’re all in the same PHP file.

There’s just one issue I’ve run into: Completion doesn’t work for built-in functions of most MVC Frameworks, for instance CakePHP & Codeigniter, and between any models and controllers you created. The connection of all these classes within the instance of the framework just isn’t apparent to the editor.

Auto-Completion in MVC Frameworks

The remedy here is to add @property PHPDoc meta data for all functions. Normally, this would mean changing all core Classes as well as your own. Fortunately Rakibul Hasan has shown us the light: By adding a prototype of your Model() and Controller() functions in the nbproject folder you can give Netbeans the additional meta data without touching your existing application.

Although it’s advertised for Codeigniter, it works just as well for other frameworks where all your code sits in classes extending a controller or a model parent — such as CakePHP.

This library for the popular PHP framework CodeIgniter generates XML sitemaps and informs search engines and other webservices of new content for them to crawl.

With live search around the corner and a relatively new, yet widely adopted and open standard for Sitemaps, now is the time to create a Sitemap for your CodeIgniter application!

Important Features

• Easy to use: See the example to get started,
• Tiny footprint: Only library and config are necessary,
• Scalability: Split work load and update only when necessary (see a word about performance),
• Open standard: Follows the Sitemaps XML protocol 0.9, compatible with any modern search engine,
• Google, Yahoo, Bing & Ask.com: By default this library uses Sitemap Writer to spread your sitemap (this can be changed in the config),
• Sitemap Indexes: Build an index of all your sitemaps (see Sitemap Index),
• Autodiscovery: Web services will find your sitemap through robots.txt (see Autodiscovery).

This library is based on work of Svetoslav Marinov but performs quicker (objects were tossed in favor of arrays), supports a newer, non-proprietary standard and in my opinion fits the CodeIgniter philosophy much better (library versus plugin).

Installation

Download the library, extract the contents to your system/application folder. Modify the config file to suit your particular application then load and use the library as you would with any other. See the example below for a sample controller.

Example

In this example we will assume you have a blog you wish to create a sitemap for. Your blog has a model “posts_model” that contains all the articles you have written.

<?php

class Sitemap extends Controller
{
	function Sitemap()
	{
		parent::Controller();
	}
	
	function index()
	{
		$this->load->model('posts_model');
		$this->load->library('sitemaps');
		
		$posts = $this->posts_model->get_posts();
		
		foreach($posts AS $post)
		{
			$item = array(
				"loc" => site_url("blog/" . $post->slug),
				// ISO 8601 format - date("c") requires PHP5
				"lastmod" => date("c", strtotime($post->last_modified)),
				"changefreq" => "hourly",
				"priority" => "0.8"
			);
			
			$this->sitemaps->add_item($item);
		}
		
		// file name may change due to compression
		$file_name = $this->sitemaps->build("sitemap_blog.xml");

		$reponses = $this->sitemaps->ping(site_url($file_name));
		
		// Debug by printing out the requests and status code responses
		// print_r($reponses);

		redirect(site_url($file_name));
	}
}

Call the controller and you should be redirected to your freshly built sitemap.

If you want to see HTTP response codes and the requests that were sent by the ping function, uncomment the print_r line in the example.

Of course you will want to update your sitemap frequently — on *nix operating systems a cronjob stands to reason. To update every ten minutes, use crontab -e and add this line:

# m h  dom mon dow   command
*/10  *  *  *  *  /usr/bin/wget -q -O /dev/null http://www.example.com/sitemap

With large sites and frequent changes, consider generating only when creating, updating or deleting. In this case arranging your data into several sitemaps can further reduce work load. For example a sitemap with all your blog posts can be updated seperately from a sitemap containing your infrequently modified static pages.

To stitch all those sitemaps together into something the search engines can handle you will need another type of file, the sitemap index:

Sitemap Index

Sitemap indexes are technically only needed if your sitemap exceeds 50,000 URLs or 10MB uncompressed file size — whichever comes first. In this case you need to build several smaller sitemaps and index their location in a seperate file, the sitemap index. This file is then treated as a normal sitemap:

$sitemaps = array(
	array("loc" => site_url("sitemap_posts.xml.gz"), "lastmod" => date("c")),
	array("loc" => site_url("sitemap_pages.xml.gz"))
);

$index_file_name = $this->sitemaps->build_index($sitemaps, "sitemap_index.xml");
$reponses = $this->sitemaps->ping(site_url($index_file_name));

redirect(site_url($index_file_name));

For the sake of completeness I should mention that your sitemap index musn’t exceed 50,000 sitemaps or 10MB uncompressed file size. If you manage to hit this 2.5 * 10⁹ URL limitation on CodeIgniter you should probably pause for a minute and contemplate just what got you into this position and how you may avoid it in the future.

Autodiscovery

Autodiscovery is a neat feature by which other web services can find your sitemap. You just need to create a robots.txt file in the root directory of your website (http://www.example.com/robots.txt) containing the following line:

Sitemap: http://www.example.com/sitemap.xml

If you already have a robots.txt, put this directive anywhere; it is independent of user-agent.

For further information visit the Sitemaps XML Protocol website or look at the source code of this library. All functions and parameters are documented.

Changelog

• Version 0.7:
  • Fixed a bug in add_item_array()
  • Improved documentation
• Version 0.6:
  • Added sitemap_index function
• Version 0.5:
  • First public release