1. The first thing, I believe, is managing your websites structure and hierarchy of pages. I don’t consider this to be the same thing as content, but it is certainly fundamental to a website. Even if your site contains some applications (a blog, a wiki, etc.), there should be a way of shoving them under this rubric, as well.
2. The next thing, of course, is managing content. Its not called a content managment system for naught, after all. Unfortunately, content is a very overloaded term. Most CMS’s seem to connect that to your site’s page structure. Create a page, throw up a WYSIWYG editor, and viola! Some CMS’s take a more fine grained approach, and consider content in a more abstract light. Content would be comparable to a data structure in a programming language. I believe ezPublish even goes as far as calling content “classes”.
3. Lastly, a CMS should be capable of creating pages which don’t fall under the rubric of your page structure directly, for example, an article section. You probably don’t want an entry in your navigation for every single article, but you definitely want a clean url like http://mydomain/articles/this-is-an-article

With that in mind, let’s talk about the “theory” of apostrophe, and how it approaches these scenarios. As far as content, apostrophe seems to have found a ground between the above mentioned approaches. On the one hand, content does not directly equal a page in your site, but can be closely associated with it. On the other hand, content is not relegated to the abstract world of boring data entry forms, but actually real live snippets of html, which can be controlled through boring data entry forms, or an rss feed, or a youtube video, or anything you want if you have some creative ideas.
With apostrophe, the we start out with the concept of a page. A page represents (almost all the time, but we’ll get to that), a public facing url on your site. Each page is backed by a slug. A page is rendered using standard php + symfony helpers. There is one layout, and each page has a template associated with it. There is no easy way, at the moment, to switch this layout, but there really shouldn’t be much of a reason why you would have to.
On the layout that comes with apostrophe, are a number of symfony slots, which are filled in at various points by apostrophe. These are generally things like menus or breadcrumbs.
Each page, has more than one “area” in it. An area is like a content holder. It can hold various types of content, stacked vertically. Each area has a name and is associated to a page. A template helper is provided to render these areas in your template.
When an area is rendered, and you are logged in with sufficient privileges, you have the ability to add content to this area. These are called slots (not to be confused with symfony slots). There are enough built in slots to put together any run-of-the-mill website fairly easily, and creating custom slots is not terribly difficult. Some of these include, plain text, rich text, video, slideshow, pdf. Each slot comes with a displayable interface (normal mode), and an editing interface (edit mode). The edit mode can be a simple form, or it can be a complex multistep, workflow-engine powered web application (see the image slot). The edit mode is powered by a component called editView. The content for the slots is, wisely, stored as a serialized php array, instead of physical columns in a database table, although the latter is certainly possible if not discouraged. This is somewhat similar to the current trend of NoSQL databases, and somewhat similar to the approach that friendfeed used when scaling their database. It would have been better, in my opinion, to store the information in JSON instead of serialized PHP, or to use an actual NoSQL database, but there is nothing stopping you from implementing your own content slots this way. When the content is not in editing mode, the display is governed by a component called normalView, where you can, of course, massage all your data as you see fit before displaying it in the components template. Each content slot is essentially a module, with two components (editView and normalView), a model class and usually a form as well. This makes it fairly trivial to create custom content slots, especially if you have prior symfony experience.
You also have the option of what is called, under the hood, a singleton area. An area which contains one and only one content slot. There is a special view helper for this as well called a_slot (as opposed to a_area).
By default, each content area is associated with the slug, and therefore the page that its on. In that respect, content and pages are somewhat analogous. For a basic site, this may well give you enough mileage to go. However, the developers realized that there is room for content which is not owned by any particular page, for example, global content. This could be an editable footer or logo which makes its way into the layout. They also recognized that not every page in a website is physically there. They call this concept “virtual pages”, and it allows for some very interesting things. Every content area, both infinite and singleton, can be assigned to a “virtual page”, and thereby pulled out in any physical page, no matter what slug it has. Virtual pages are distinguished by virtue of not have a leading “/” in their slug name, thereby removing them from the realm of the navigation. One use case I came up with, was having a sidebar in the layout, but having the content of the sidebar different for each page. In order to do this, I had to specify a slug that was guaranteed to be unique for each page, so I called it something like “sidebar-$page->id”. I will discuss another use case later.
As I mentioned earlier also, a CMS should also be able to handle pages which shouldn’t exist in your navigation, such as articles. For this, they came up with the concept of engines. Basically, instead of having your page rendered via apostrophe, it gets sent to a regular symfony module, written to certain conventions. You could have an module which renders an article page, based on an id in the url, but this page will still be under the rubric of your site. As an additional bonus, since its a regular symfony module, rendered by a regular symfony template, you can use the apostrophe helpers, and put content areas in a virtual page with a slug derived from the article’s id. This was the other use case I was referring to earlier.
This cms follows the principle of less is more, and because of that, it is a clean, elegant system, with almost no learning curve.
That is not say it does not have some problems. The admin view requires that the content areas be surrounded by a swath of DIVs. Unfortunately, these DIVs make it into the end user mode. My designer was not so happy to hear that the recommendation was to “embrace the DIVs”.
Also, the page gets loaded with a lot of incoherent, redundant, inline javascript. Both inline in the page, and sometimes inlined on the element itself. There is no Javascript framework such as what comes with diem. For example, when you click “add slot” in an area, you are greeting with a very eye-appealing dropdown box. Unfortunately, to mimic that behavior seems to require a lot of copy and pasting.
Certain areas of the code also look suspect and “hackish” to me. Any class named “aTools” with only static methods is certainly a red flag. Of course, symfony 1.x also has code like this as well, but that doesn’t mean that bad habits should be copied. Virtual pages are implemented, by temporarily switching a global variable (disguised a static variable), which holds the current page’s slug, for the duration of the rendering, until when the global variable is swapped back to its original state. This feels like hacky code to me.
Over all, I have to certainly commend the developers of apostrophe. They managed to come up with good solutions for some classic problems in web development. They managed to create a tool which is good for end users *and* developers at the same time. Certainly not an easy task.

The basic idea is that creating templates in Expression Engine, especially if you don’t plan to edit them from the CP, can sometimes be a little repetitive and annoying.
Normally with EE, the templates are stored in the database, and you have the option of also storing them on the filesystem. But in order for them to be recognized by EE, they must reside in the database at least.

Using this extension, you can start your template off as a physical file, and the first time you view it in the browser, it will automatically be recognized by EE and inserted into the database!

I would like to argue that the proper use for the Zend ACL is actually impossible, since there is a reported bug in the code which, to my knowledge, has not been fixed.

The use case I will discuss is where you want to only authors to edit articles and only to articles authored by themselves. I think this is a fairly common case.

How does the ACL help us? The ACL allows the developer to setup access rules for arbitrary resources and arbitrary roles. The key word here is “arbitrary”, and I’ll get back to that in a moment.

My feeling is that when most people start out with the ACL, they assume that resources are controllers (or some combination of module and controller), and permissions are actions. So, for example, let’s say you had a controller called “Article” with an action called “edit”.

class ArticleController extends Zend_Controller_Action {
  public function editAction() {
     //do stuff
  }
}

So an ACL would be set up with something like this:

$acl = new Zend_Acl();
 
$acl->add(new Zend_Acl_Resource('article'));
 
$acl->addRole(new Zend_Acl_Role('author'));
 
$acl->deny();
 
$acl->allow('author', 'article', array('edit'));

This looks farely straight forward. Some place before the action is dispatched, like in a plugin, action helper or whatever you want, you would do a check against this acl.

$acl->isAllowed($role, $resource, $permission);

There are two problems with this approach, one obvious and one not so obvious.

The obvious one is that, while this may be successful in blocking regular users from editing the articles, it doesn’t block another author from editing the article.

In order to do that, we need to add in an additional assertion:

$acl->allow('author', 'article', array('edit'), new AssertionIsArticleAuthor());

The problem then becomes: in this assertion, how do you know which article it is? How do you know who the current author is? These can be very tricky questions. You might have to somehow stick the request object in there, and access the Zend_Auth singleton. While these certaintly are viable solutions, they just “smell” bad.

The other not so obvious problem is seen by taking a few steps back and looking at the whole problem from the beginning. The first question to ask is, what exactly are we trying to solve here? We want to restrict access to an article. So what did we do instead? We restricted access to a controller? What kind of sense does that make? Additionally, we are now tying in our ACL implementation to the url structure of the site. That is primarily a function presentation. If we would want to change that, it would require changing our ACL implentation. While Zend_Acl is certainly a “Zend” component, it has nothing directly to do with Zend MVC, but this approach ties us down to Zend MVC. What if we decided one day that we did not like the MVC components of ZF and wanted to move to Symfony or MVCnPHP?

Zend Framework is primarily a presentation framework. It helps in providing a clear and organized way to bring the presentation layer to the user. And that’s what it excels at. That, I believe, is the number one reason why they don’t ship with a “model” component. The model layer must be provided by yourself, and this part is probably the hardest part of the whole game. But if you keep some simple principles in mind, and keep focused, you can reapproach this whole problem in a new light.

We’ll start with our model layer. This should be fully functional without ZF. Pretend you’re writing a desktop app. Or a shell script. Whether or not the model layer should be tied to the database or separated from that as well, is a different question.

My personal approach, one which is fairly common in the Java world, is to work with Business objects, which are just “POPOs”…Plain Old PHP Classes. These business objects represent all the entities in my application…but this is a post for later. Let’s not digress too much.

In our model layer, we have two objects, an Article and an Author.

class Article {
    public $id;
    public $title;
    public $body;
 
   /**
   * @var Author
   */
   public $author;
}
 
class Author {
    public $id;
    public $name;
}

Any business logic in your app should either take place within these objects, or within other objects that act as a service layer. Your controllers should either talk to these service layer objects or to the business objects themselves.

When you retrieve data from the database, instead of keeping it around as array, put it in one of these objects. You can also use a custom Zend_Db_Row object for this to if you want to make things really simple.

Now that we’re dealing with objects, we can see that we want to restrict access to an Article object to the Author object contained within it. So our resource becomes the Article and the role is the Author. How do you define these as resources and roles? All we have to do is have our objects implement the Zend_Acl_Resource and Zend_Acl_Role interfaces! So we will modify the previous code to something like this:

class Article implements Zend_Acl_Resource_Interface {
    public $id;
    public $title;
    public $body;
 
   /**
   * @var Author
   */
 
   public $author;
 
   public function getResourceId() {
       return 'article';
  }
}
 
class Author implements Zend_Acl_Role_Interface {
    public $id;
    public $name;
 
    public function getRoleId() {
        return 'user';
   }
}

Now we write our custom assertion:

class Chintion_Acl_Assert_AssertIsArticleAuthor implements Zend_Acl_Assert_Interface
{
    public function assert(Zend_Acl $acl, Zend_Acl_Role_Interface  $author = null,
    Zend_Acl_Resource_Interface $article = null, $privilege = null)
    {
          return $this->article->author == $author;
    }
}

Now when you have your Article object, you can take your Author object (which you can either store in Zend_Auth or construct it from the data in Zend_Auth), and do a check like this:

$acl->isAllowed($author, $article);

Very nice, clean and simple.

Except…..

It won’t work. By the time the assertion gets a hold of the instance of Zend_Acl_Role_Interface, its been demoted to plain old Zend_Acl_Role. Ditto for Zend_Acl_Resource_Interface. It doesn’t have our fancy beefed up role or resource.

This I think is due to the bug report that I linked to at the beginning. Fortunately, for the moment, there’s a work around:

We have to override the method Zend_Acl::get(Zend_Acl_Resource_Interface $resource) and the method Zend_Acl_Role_Registry::get(Zend_Acl_Role_Interface $role);

To do this, you have to subclass Zend_Acl and overridde the get method as such:

public function get($resource)
{
    if ($resource instanceof Zend_Acl_Resource_Interface) {
        return $resource;
    }
    return parent::get($resource);
}

and similary for Zend_Acl_Role_Registry:

class RoleRegistry extends Zend_Acl_Role_Registry {
    public function get($role)
    {
        if ($role instanceof Zend_Acl_Role_Interface) {
            return $role;
        }
 
        return parent::get($role);
 
    }
}

and in your subclassed Zend_Acl:

$this->_roleRegistry = new RoleRegistry();

I first got into timezones when I working on an calendar app which displayed various times of day which are pertinent to Jewish daily life. The app would display calculated times which of course would differ based on the timezone of the given location. As I investigated into timezones, I found them to be fairly complicated. Not all timezones are even on the hour…some are at 30 minute offsets, some at 45 minutes, and historically there have been even stranger offsets than that.

To make matters worse, there’s the whole issue of Daylight Saving Time. Apparently some places have it some don’t. Some countries have a set date for DST, some pick a new one each year depending on circumstances. And of course, DST does not mean only adding one hour. 

My research led me to what is “colloquially” known as the “Olson” database. The Olson database is a de facto standard in the world of keeping time. The most recognizable part of the way timezones are identified is the {Continent}/{Location} signature. For example, the timezone that I am in is called “America/New_York”. The Olson database tracks all historical information about timezones back at least until 1970. By timezone information, this also means transitions for DST and the GMT offset for both standard time and DST.

The best part of all of this, is that PHP 5 and up has built in support for understanding Olson timezones. This means that you all you need is the timezone id (the tzid), and you can have PHP worry about all the timezone and DST calculations.

Recently, I was working on another app which required members to select a timezone. The app is written on top of Expression Engine which contains a full blown membership system. The membership system includes a timezone setting. Let’s take a quick look at the what this look like:

Selecting a timezone in Expression Engine

Notice the checkbox that says “Daylight Saving Time”? This means that the user has to remember, every year, to select that checkbox when DST happens. Not very fun. Expression Engine is written in PHP 4, and the authors intend to keep that, stubbornly, for as long as possible.

I’m not here to wrant on Expression Engine (that’s for another time), but either way, this would not suit my purposes. I can’t rely on users remembering to “spring forward” when they have to.

The alternative is to provide a list based on the Olson database. The problem is that, as of this post, their are 560 tzid’s in the database, and they are not “friendly” nor recognizable to anybody but geeks. 

I started looking around on the Interwebs trying to see what other people came up with. There was a question on Stackoverflow.com which hit the nail on the head, but anybody answering the question missed the point completely.

Eventually I realized that I must present a list similar to Expression Engine’s list, but which has the values as Olson tzid’s. The first step was to clean up the list a little. Much of the information is redundant, and only there for historical purposes. For instance, until 2006, much of Indiana did not observe DST. After 2006, however, the story changed. This explains why there are so many Olson tzid’s with Indiana in them. However, for all practical purposes, they’re the same.

The question is, what defines them as the same? I determined the best way would be to look at the DST transition date (if applicable), and the resulting offsets and compare them. Fortunately, PHP has a function that does this…timezone_transitions_get().

My idea was to pull in all the timezones and their transistions into excel and sort them by offset, and transition dates to identify which tzids are similar. After that, to figure out a friendly name to call them.

Doing more research I found somebody made a spreadsheet which tried to map Windows timezone names to Olson tzid’s. I used this a base reference for the names I chose, although I found not all the data in that spreadsheet was accurate (one day I will submit my changes to the author). Some timezones I had to come up with my own names like “America/Havana” which has different rules for any place in its timezone. I decided to call this (GMT-05:00) Cuba for lack of anything else.

In the end, I came up with a list of about 80 or so timezones, and I’m somewhat proud of my results:

Here is the list:

<option value="Pacific/Midway">(GMT-11:00) Midway Island, Samoa</option>
<option value="America/Adak">(GMT-10:00) Hawaii-Aleutian</option>
<option value="Etc/GMT+10">(GMT-10:00) Hawaii</option>
<option value="Pacific/Marquesas">(GMT-09:30) Marquesas Islands</option>
<option value="Pacific/Gambier">(GMT-09:00) Gambier Islands</option>
<option value="America/Anchorage">(GMT-09:00) Alaska</option>
<option value="America/Ensenada">(GMT-08:00) Tijuana, Baja California</option>
<option value="Etc/GMT+8">(GMT-08:00) Pitcairn Islands</option>
<option value="America/Los_Angeles">(GMT-08:00) Pacific Time (US & Canada)</option>
<option value="America/Denver">(GMT-07:00) Mountain Time (US & Canada)</option>
<option value="America/Chihuahua">(GMT-07:00) Chihuahua, La Paz, Mazatlan</option>
<option value="America/Dawson_Creek">(GMT-07:00) Arizona</option>
<option value="America/Belize">(GMT-06:00) Saskatchewan, Central America</option>
<option value="America/Cancun">(GMT-06:00) Guadalajara, Mexico City, Monterrey</option>
<option value="Chile/EasterIsland">(GMT-06:00) Easter Island</option>
<option value="America/Chicago">(GMT-06:00) Central Time (US & Canada)</option>
<option value="America/New_York">(GMT-05:00) Eastern Time (US & Canada)</option>
<option value="America/Havana">(GMT-05:00) Cuba</option>
<option value="America/Bogota">(GMT-05:00) Bogota, Lima, Quito, Rio Branco</option>
<option value="America/Caracas">(GMT-04:30) Caracas</option>
<option value="America/Santiago">(GMT-04:00) Santiago</option>
<option value="America/La_Paz">(GMT-04:00) La Paz</option>
<option value="Atlantic/Stanley">(GMT-04:00) Faukland Islands</option>
<option value="America/Campo_Grande">(GMT-04:00) Brazil</option>
<option value="America/Goose_Bay">(GMT-04:00) Atlantic Time (Goose Bay)</option>
<option value="America/Glace_Bay">(GMT-04:00) Atlantic Time (Canada)</option>
<option value="America/St_Johns">(GMT-03:30) Newfoundland</option>
<option value="America/Araguaina">(GMT-03:00) UTC-3</option>
<option value="America/Montevideo">(GMT-03:00) Montevideo</option>
<option value="America/Miquelon">(GMT-03:00) Miquelon, St. Pierre</option>
<option value="America/Godthab">(GMT-03:00) Greenland</option>
<option value="America/Argentina/Buenos_Aires">(GMT-03:00) Buenos Aires</option>
<option value="America/Sao_Paulo">(GMT-03:00) Brasilia</option>
<option value="America/Noronha">(GMT-02:00) Mid-Atlantic</option>
<option value="Atlantic/Cape_Verde">(GMT-01:00) Cape Verde Is.</option>
<option value="Atlantic/Azores">(GMT-01:00) Azores</option>
<option value="Europe/Belfast">(GMT) Greenwich Mean Time : Belfast</option>
<option value="Europe/Dublin">(GMT) Greenwich Mean Time : Dublin</option>
<option value="Europe/Lisbon">(GMT) Greenwich Mean Time : Lisbon</option>
<option value="Europe/London">(GMT) Greenwich Mean Time : London</option>
<option value="Africa/Abidjan">(GMT) Monrovia, Reykjavik</option>
<option value="Europe/Amsterdam">(GMT+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna</option>
<option value="Europe/Belgrade">(GMT+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague</option>
<option value="Europe/Brussels">(GMT+01:00) Brussels, Copenhagen, Madrid, Paris</option>
<option value="Africa/Algiers">(GMT+01:00) West Central Africa</option>
<option value="Africa/Windhoek">(GMT+01:00) Windhoek</option>
<option value="Asia/Beirut">(GMT+02:00) Beirut</option>
<option value="Africa/Cairo">(GMT+02:00) Cairo</option>
<option value="Asia/Gaza">(GMT+02:00) Gaza</option>
<option value="Africa/Blantyre">(GMT+02:00) Harare, Pretoria</option>
<option value="Asia/Jerusalem">(GMT+02:00) Jerusalem</option>
<option value="Europe/Minsk">(GMT+02:00) Minsk</option>
<option value="Asia/Damascus">(GMT+02:00) Syria</option>
<option value="Europe/Moscow">(GMT+03:00) Moscow, St. Petersburg, Volgograd</option>
<option value="Africa/Addis_Ababa">(GMT+03:00) Nairobi</option>
<option value="Asia/Tehran">(GMT+03:30) Tehran</option>
<option value="Asia/Dubai">(GMT+04:00) Abu Dhabi, Muscat</option>
<option value="Asia/Yerevan">(GMT+04:00) Yerevan</option>
<option value="Asia/Kabul">(GMT+04:30) Kabul</option>
<option value="Asia/Yekaterinburg">(GMT+05:00) Ekaterinburg</option>
<option value="Asia/Tashkent">(GMT+05:00) Tashkent</option>
<option value="Asia/Kolkata">(GMT+05:30) Chennai, Kolkata, Mumbai, New Delhi</option>
<option value="Asia/Katmandu">(GMT+05:45) Kathmandu</option>
<option value="Asia/Dhaka">(GMT+06:00) Astana, Dhaka</option>
<option value="Asia/Novosibirsk">(GMT+06:00) Novosibirsk</option>
<option value="Asia/Rangoon">(GMT+06:30) Yangon (Rangoon)</option>
<option value="Asia/Bangkok">(GMT+07:00) Bangkok, Hanoi, Jakarta</option>
<option value="Asia/Krasnoyarsk">(GMT+07:00) Krasnoyarsk</option>
<option value="Asia/Hong_Kong">(GMT+08:00) Beijing, Chongqing, Hong Kong, Urumqi</option>
<option value="Asia/Irkutsk">(GMT+08:00) Irkutsk, Ulaan Bataar</option>
<option value="Australia/Perth">(GMT+08:00) Perth</option>
<option value="Australia/Eucla">(GMT+08:45) Eucla</option>
<option value="Asia/Tokyo">(GMT+09:00) Osaka, Sapporo, Tokyo</option>
<option value="Asia/Seoul">(GMT+09:00) Seoul</option>
<option value="Asia/Yakutsk">(GMT+09:00) Yakutsk</option>
<option value="Australia/Adelaide">(GMT+09:30) Adelaide</option>
<option value="Australia/Darwin">(GMT+09:30) Darwin</option>
<option value="Australia/Brisbane">(GMT+10:00) Brisbane</option>
<option value="Australia/Hobart">(GMT+10:00) Hobart</option>
<option value="Asia/Vladivostok">(GMT+10:00) Vladivostok</option>
<option value="Australia/Lord_Howe">(GMT+10:30) Lord Howe Island</option>
<option value="Etc/GMT-11">(GMT+11:00) Solomon Is., New Caledonia</option>
<option value="Asia/Magadan">(GMT+11:00) Magadan</option>
<option value="Pacific/Norfolk">(GMT+11:30) Norfolk Island</option>
<option value="Asia/Anadyr">(GMT+12:00) Anadyr, Kamchatka</option>
<option value="Pacific/Auckland">(GMT+12:00) Auckland, Wellington</option>
<option value="Etc/GMT-12">(GMT+12:00) Fiji, Kamchatka, Marshall Is.</option>
<option value="Pacific/Chatham">(GMT+12:45) Chatham Islands</option>
<option value="Pacific/Tongatapu">(GMT+13:00) Nuku'alofa</option>
<option value="Pacific/Kiritimati">(GMT+14:00) Kiritimati</option>

If anybody can offer any improvements to this or a different suggestion altogether, that would be great.