P'unk Avenue Window

Apostrophe is a beautiful CMS, if we do say so ourselves. In-context editing and thoughtful design make it a joy to use. And this is a problem.

It is a problem because people look at it and say “if it’s that pretty, it can’t possibly be intended for big organizations, or big websites.” And they persist in this opinion until someone drags them by the ear to an institution where Apostrophe is actually being used to deploy a large website with many users.

The Franklin & Marshall College website has hundreds of actively editing users, with widely varying permissions throughout the site. Some users are permitted to edit only the pages in the Chemistry department, others in Judaic Studies. Some have the privilege of creating and deleting pages, others can only revise content. Privileges are inherited, so if you can edit the biology home page, you can edit all of biology. Simple and effective.

Everyone can contribute to the media repository, but only administrators can remove media that others have uploaded. Reusable content can be created via the blog plugin, and blog post categories can be restricted to particular editors as needed.

We’ve had rich support for granting specific permissions on specific pages to individuals in specific parts of the site since even before Apostrophe 1.0. For F&M we added group permissions, and that is now in the svn trunk of Apostrophe, soon to be released in version 1.5.

All of this is under the control of the website administrators (i.e. our clients)… via a thoughtfully designed interface that is accessible from every page if you have the appropriate privileges. Which fits with our philosophy: there are no back-end applications. Every part of the interface should be good, thoughtful and usable. If an interface is used to manage big sites with hundreds of editors, then it is more important that it be friendly, not less.

It’s easy for developers to hook Apostrophe up to an existing directory service like LDAP. And that can mean thousands of users, some of which belong to people who shouldn’t have the privilege of viewing locked pages. No problem: don’t add them to the guest group. A large number of users could make the controls for managing who can edit what unwieldy. There’s a simple solution to that too: use group permissions, or add people to the editor group, which makes them candidates to receive permissions as individuals. We’ve thought through this stuff.

Of course scalability isn’t just about creating interfaces that work for managing large sites. It’s also about building code that won’t fall over with thousands of pages and simultaneous edits taking place. We faced some new challenges in this area on the F&M project and worked through them.

We pushed the Zend Lucene search engine to new levels, deferring search engine updates to a scheduled task to avoid slowing down edits and making sure the search index gets reoptimized regularly. We broke potentially memory-busting tasks into manageable subtasks that are scheduled to ensure PHP can get the job done. And we addressed those subtle problems that come up when two people do things simultaneously— issues that are often overlooked in software.

Since implementing F&M we’ve added even more scalability-oriented features which are in the trunk today and will appear in version 1.5, most notably a built-in minifier that drastically improves page load times and reduces server load without forcing designers and developers to think differently. And because there sometimes are right and wrong ways to code things, we’ve also added a_js_call, a robust solution to the problem of enhancing sites with JavaScript without killing performance or creating unmanageable code. And yes, we’ve added shiny new features that enhance content in more obvious ways. But we’re talking about scalability today.

Of course, Apostrophe has to be deployed correctly to achieve great performance. System administrators need to know how to get the best results from PHP. And so we’ve written a heavily retweeted article on best practices for PHP web hosting, as well as a sequel for the Windows folks.

F&M isn’t the first large institution to use Apostrophe. But the F&M site is the largest single Apostrophe site we’ve built, with the largest community of editors. It’s also an example of Apostrophe being chosen for its large-scale usability rather than on the merits of a new website design. In fact, the site was migrated from another CMS without changing the basic design.

Much as we love to redesign sites from scratch, it’s important to note that Apostrophe has been chosen on its technical merits, scalability and ease of maintenance. Spread the word: you can be smart and pretty at the same time.

We’ve released version 1.4.2 of Apostrophe. This is a maintenance release primarily made up of stability and security fixes. We strongly recommend upgrading if you are using any 1.x version of Apostrophe. Even for those keeping up with Apostrophe’s 1.4 stable branch via svn (as we recommend), the following remains a handy list of what has changed recently.
(more…)

You’ll want to watch fullscreen for readability.

Which web development framework is the best? I can tell you this: Symfony gets the job done fast.

Last week Alex and I took part in a panel discussion of web frameworks at the Wharton UI Conference. I had half an hour to kill beforehand, so I decided to build a web application with Symfony. I had time left over to play with the CSS and demonstrate the power of layout templates. After we returned I went upstairs and made a screencast while building the app once more.

I made a number of educational mistakes along the way, so I included those along with their solutions.

Is this a full-fledged practical web application? Not quite— there’s no user management, for one thing. But that’s a topic for another screencast. Be sure to comment if you’d like to see additional installments.

Symfony is the best framework for building web applications in PHP. The forthcoming Symfony 2 is a dramatic improvement and a complete rewrite with many new features and, even more importantly, better software architecture. Enthusiasts may have heard about the State of Symfony 2 Online Conference to be held on June 23rd. Fabien and the Sensio team have encouraged folks to become “Symfony conference hubs” and invite others to attend the conference from our offices and enjoy the benefits of our lovely projector, coffee, etc. And P’unk Avenue is definitely all about it. Please RSVP by commenting here.

WHAT: Symfony 2 Live Conference
WHERE: P’unk Avenue offices, 1168 E. Passyunk Ave, Philadelphia PA
WHEN: 11am Wednesday, June 23rd

Thanks to our hub status, You do not have to buy your own Symfony 2 ticket to attend at our office.

We’re looking forward to discussion and possibly busting out the Symfony 2 sandbox and experimenting after the conference.

---

Amid the excitement about Symfony 2, this would be a good time to mention our ongoing support for Symfony 1.4, and by extension Apostrophe 1.x. If Symfony 2.0 is coming, does that mean we’re going to abandon Symfony 1.x and Apostrophe 1.x?

No, not by a long shot, not any time soon. Symfony 2 will not be backwards compatible in a “super easy upgrade path” way, which is a valid choice to make improvements that would otherwise be impossible but an obvious problem for existing projects. And we have plenty of those. What’s more, Symfony 2 requires PHP 5.3.x at a minimum, and we know how tough it can be to move clients along just to PHP 5.2.x.

Fortunately, Sensio had the wisdom to make Symfony 1.4 a long-term-support release. And since Apostrophe 1.x is happily married to Symfony 1.4, that means we’re all in good shape.

Symfony 1.4 is supported until November of 2012, and Apostrophe 1.x will also be supported until at least November of 2012.

At some point, Apostrophe 2.x will come into being and it will be based on Symfony 2, but we have many client and internal projects that are purring away happily on Symfony 1.4 and we have absolutely no interest in abandoning it. So you can very safely pursue client projects based on the current stable releases of Apostrophe.

We’re looking at doing a meeting the following week or possibly next month. Fact is, we’re busy!

Speaking of Symfony and being busy, if this announcement disappoints you— if you’re eager to hobnob with other Symfony developers— may I suggest you apply to work here? You’ll have all the Symfony you can eat! We’re particularly eager to talk to experienced PHP5 framework coders, and to Ruby on Rails coders who are open to working in PHP (sekrit plans to convert us to Ruby are a bit unrealistic given the depth of our commitment to PHP and Symfony).

Things are moving pretty fast lately on our corner of E. Passyunk and Federal. Apostrophe is rolling along at a full clip and we have all sorts of other exciting projects we’re in the midst of. Olivia Rabe recently joined the team to work closely with our clients on issues of content strategy and Apostrophe support. We’re even beginning to expand our studio space into the adjacent building.

If this sounds at all interesting to you, the best news is that you might be able to help us fill some of our new space: We’re looking to make another addition to the team so we can continue to build these amazing applications and still go home on time. Right now we are looking for a new developer, somebody who would assist in the creation of new Apostrophe features and collaborate on development of products for our clients.

If you think you might be the right fit, or know someone who is, read on after the cut.
(more…)

IN WHICH our hero is narrowly saved by vague memories of a really dull presentation by some guys in suits.

You may recall my recent post on speeding up PHP on Linux without changing your PHP code. Those techniques have become standard practice around here, and the article has since been retweeted, linked to, engraved on an unobtanium disc embedded in a space probe to be launched next week by the Malaysian space forces, et cetera. So it seems we have the Linux PHP thing down to a science, for now.

But not every shop runs Linux, and one of our clients has asked us to deploy in a Windows environment. We’ve deployed PHP sites for them before, but that was in the Symfony 1.0 days, and there just weren’t nearly as many class files to compile. When we set out to deploy a modern site built with Apostrophe, our content management system based on Symfony 1.4 and Doctrine, we were reminded that out-of-the-box PHP is slow, slow, slow.

I would gladly have addressed this the same way we do it on Linux: FastCGI, APC and Apache’s worker thread MPM. And in fact Apache for Windows seems to only support a special threaded MPM under Windows anyway, so that part is already familiar.

Unfortunately, the official PHP infrastructure for Windows has, frankly, undergone a bit of code rot lately:

The PHP binaries don’t seem to include a CGI/FastCGI binary! Shoot. Well, maybe APC alone will be enough. But APC is not standard with the Windows PHP binaries, so I need to get it from PECL. Okay, but the PECL for Windows site is “temporarily out of service.” A new solution is coming, but it’s not here yet.

Searches led me to Pierre Joye’s folder on downloads.php.net. Pierre is a core PHP developer, so I trust him, no problem there. But the version of APC found there just locks up Windows PHP, at least in my tests. I investigated alternative PHP bytecode caches and wound up with xcache. xcache worked for a while, then started spewing errors about classes being redefined, and always began doing so again within a few page views after each restart of Apache.

Yuck!

Fortunately, by this point a vague memory was stirring somewhere in my geeky cortex. I was in Paris… I was full of pain au chocolat… I was very sleepy… two guys in suits were droning on and on about something while the crowd ignored them… AHA! Those Microsoft guys at Symfony Live! They were talking about speeding up PHP on Windows. They even mentioned hiring Pierre Joye to help out. But they didn’t demonstrate anything on Symfony, so I wasn’t paying a lot of attention—

Just enough as it turns out. The deal is this: Microsoft knows that PHP has, historically, sucked on Windows. And they have taken steps. And this is good news for the rest of us.

PHP can now be installed via the Microsoft Web Platform installer. That gives you single-threaded PHP running via fastcgi— exactly like my Linux setup, except for the bytecode cache part. And now the new Windows Cache Extension for PHP delivers a bytecode cache, equivalent to APC.

The end result is definitely in the ballpark with the performance of my Linux solution. Since I haven’t tested them on the same hardware (both boxes were VMs, and they were provided by different datacenters), I cannot say for certain which was faster. The Microsoft speakers at Symfony Live characterized it as better but still not as fast as the best PHP setups on Apache. At any rate it’s a big improvement and well worth your time if you need to host on Windows.

So here’s a HOWTO for configuring Symfony and PHP on Windows with good performance:

To configure IIS for Symfony:

1. Make sure IIS is installed. I know, right?

We want IIS 7. IIS 7 features an excellent importer for mod_rewrite rules, and Symfony loves mod_rewrite rules.

2. Install PHP from the Microsoft Web Platform. Click that link from IE running on your server (hint: remote desktop connection) for the easiest download-and-install process.

3. Install Windows Cache for PHP to get acceptable speed from the above. I installed version 1.0 because 1.1 is in beta. The beta does look interesting because it has an alternate PHP session handler that uses shared memory. You’d have to configure symfony to actually use that feature I believe (welcome to factories.yml).

4. Let’s say your project’s short name (aka “Unix name”) is mysite. So copy your Symfony project to c:\mysite. (I’m assuming a virtual machine for a single client project. Choose a better folder structure if you’re deploying lots of sites on this box.) You can set up cygwin to allow ssh access and rsync those files with project:deploy, and in fact we do, but that’s a subject for another day. FTP also works.

5. Launch the IIS manager (Start -> Administrative Tools -> IIS Manager).

6. Open the server’s icon, then “Sites,” then delete the “default site” entry.

7. Add a new site entry called mysite. Map the site’s web folder to be the web subfolder of the Symfony project which you should have copied to c:\mysite by now. So the web folder path would be c:\mysite\web. Assign it to port 80. Do NOT set the web folder to be the root of your project! That is very dangerous as it exposes your databases.yml file. Point it to the web subfolder.

8. Always clear your Symfony cache after copying a site to a new server. At the command shell (start->run->cmd.exe), type:

cd \mysite
php symfony cc

10. PHP needs write access to c:\windows\temp to store session data in order for logon sessions to work. You should have no trouble here on a new setup with just IIS I suspect, but if you previously ran Apache you might need to clean up. Clobber any existing session files in c:\windows\temp. Note that this is also the folder where the PHP error log file is found:

c:\windows\temp\php-errors.log

You can watch that file using a Cygwin shell and the tail -f command, or peek at it as needed with a text editor.

9. Try the site out, with a frontend controller name in the URL. You’ll get the home page but subpages won’t work yet without manually putting the controller name back in the URL. In IE running on the server itself, visit:

http://localhost/index.php

10. We need to add the mod_rewrite rules that remove the need for `/index.php`. But IIS doesn’t have mod_rewrite. Fortunately IIS7 has its own URL rewriting feature… and it can import your rules.

In the IIS manager, double-click mysite, then double-click “URL Rewrite.” In the “Actions” area at right, click “Import Rules” under “Inbound Rules.”

Edit: if “Inbound Rules” is missing, close “URL Rewrite” and then open that feature again. Also try adding one empty rule manually first. The “incredible disappearing/reappearing ‘Inbound Rules’ feature” appears to be a bug in the IIS manager.

Paste the mod_rewrite rules from your web/.htaccess file. IIS will do a pretty snazzy job of converting them when you click Import (but if you have fancy rules that go beyond the usual Symfony rules, give the end results a careful look-see). Then click “Apply.”

Edit: IIS won’t tell you, but the settings you just created live in a file called web.config in the web subfolder of your project. You must not crush this file when you sync your project. Add the file to your project, or rsync exclude it if you’re using cygwin and project:deploy. Since you might want to add more rules to it manually I generally recommend the former. But one disadvantage of adding it to your project is that any edits you make in the GUI will get clobbered on future syncs if you don’t manually copy the resulting changes from web.config on the server back to your project.

11. Try the site again. You should be able to browse the entire site now.

12. Whoops, you can’t log in because IIS is hijacking the 401 Unauthorized error page. To fix that, go back to the IIS Manager pane for mysite. Double-click “Modules” and remove the “Custom Error” module.

Now your site’s login page will appear properly. Also your custom 404 and 500 error pages.

That’s it – you should be ready to go with much speedier Windows PHP.

Note that for the time being the Microsoft Web Platform seems to offer only PHP 5.2.13. This is a stable and sane choice and until recently I would have done it no differently. But PHP 5.3.2 is much better than 5.3.0 and 5.3.1 and offers new features that matter— improved memory management, faster performance and new PHP language features that the forthcoming Symfony 2.0 requires. Hopefully PHP 5.3.x will appear in the Web Platform installer soon.

(*) Yes, I sorted through the maze and found versions of PHP and APC that were supposedly for the same C runtime, et cetera. Still no love. xcache was better, but alas the redefined class errors put paid to that too.

TOM: “Open source help desk, this is Tom speaking. How may we help each other?”

CALLER: “I chose your open source project for my client project and it’s due tomorrow and it doesn’t work! This is your problem and you must fix it immediately or I will explode!”

TOM: [CLICK]

---

TOM: “Open source help desk, this is Tom speaking. How may we help each other?”

CALLER: “Your code has several bugs, which I am going to describe in harsh and unsympathetic but highly accurate detail.”

TOM: [Hangs up on caller, then fixes those bugs]

---

TOM: “Open source help desk, this is Tom speaking. How may we help each other?”

CALLER: “I translated your program into Swahili! Here’s the XLIFF file. Also I found a bug. Here’s a patch file.”

TOM: “Yay! Welcome to the cool people’s club! We’re having chocolate ice cream. Would you like some?”

---

TOM: “Open source help desk, this is Tom speaking. How may we help each other?”

CALLER: “500 ERROR! AAAAAAAAAAAAAA!”

TOM: “Lower your voice, read your log files, try the dev controller and call back.”

CALLER: [reads own log files, discovers glaringly obvious permissions problem, solves it, is never heard from again]

---

TOM: “Open source help desk, this is Tom speaking. How may we help each other?”

CALLER: “something isn’t quite right. When I do X, Y and Z, I get the following error message [copies and pastes complete error message].”

TOM: “reproducible bug reports make me deeply happy. I’ve just committed a fix in svn. Would you like some ice cream?”

Sure, geeks have grabbed Philly by the balls, but that doesn’t mean we can’t sharpen our… skills… where am I going with this?

Oh yeah: the Philly Symfony Users Group. We use the Symfony framework for PHP development all day long. It’s been the basis for every single client project we’ve done since… hell, before I came aboard two years ago. It’s the foundation on which Apostrophe is based. We cannot imagine suffering through web application development without it (or at least something on a similar plane of object-oriented, thoroughly modern, Model-View-Controller awesome, like Zend Framework).

But we haven’t met a lot of other Philly-based Symfony developers. And this is where you come in. We’d like to spread the word and help aspiring local Symfony developers get their boots on the ground. And if other experienced Symfony developers are out there reading this, we’d really, really like to get to know you better.

Announcing the Philly Symfony Users Group! Every second Thursday of the month at 6:30pm, you are cordially invited to our office at 1168 East Passyunk Avenue. We’ll start off with informal discussion (and beer), then someone will present on an aspect of Symfony development.

WHERE: 1168 E. Passyunk Ave
WHEN: 6:30pm, Thursday April 8th
WHAT: Symfony Users Group
PRESENTATION: “Getting Started with Symfony,” Tom Boutell

At this first meeting I’ll talk about the process of installing Symfony, PHP and Apache on your own computer, focusing primarily on what it’s like to build a simple Symfony 1.4 web application.

You don’t have to be an experienced Symfony developer to attend! We welcome all PHP developers and those who aspire to become PHP coders.