March 19, 2008
Our very own PM, Matt Goyer, recently setup his Seattle condos WordPress blog to include a syndication of new Redfin listings. We thought it would be a great idea to share how we did this.
Required Plugins
Steps to Follow
- Install the plugins listed above
- Create a writable cache folder if you haven’t already (wp-content/cache)
- This problem is solved if you use WP-Cache
- Perform a search on Redfin
- To syndicate new listings, make sure you select the “New Listings” option (pictured below)
- Once you are satisfied with your search, click the “Save this Search” link above the map
- In the pop-up that will appear, click the “RSS 2.0 Feed” link (also pictured below)
- Follow the SimplePie Plugin usage instructions to include the Redfin RSS feed
Here’s an example of how syndication looks on Matt’s blog:
You’ll have to fiddle with the SimplePie templates and settings to get syndication to look like Matt’s. Again, refer to their usage instructions on how to do this.
March 10, 2008
Believe it or not, but up until the beginning of March this year, we were not using a Content Management System (CMS). This post will take you through the reasons for needing a CMS, along with the process we went through to choose a CMS.
We needed a CMS for the following reasons:
- We used to have to release a whole new version of our website to include content changes. With the CMS we’re able to just release content, without having to change any code at all.
- We used to have a pseudo-CMS that required a lot of coordination at deploy time between staging and production. Moreover, we needed to be very careful that production changes weren’t overwritten when staging changes were copied over at deploy time.
- Our developer bug lists used to be cluttered with content bugs.
- Our marketing personnel could not directly change content, because they don’t have a build on their local machines and they don’t know HTML. Instead they had to hand off a content, layout, and design spec to a developer.
With all of these pain points in mind, we created some requirements:
- Customizable workflow
- Scenario: marketing submits content, PM approves content, then PM schedules the content for a release
- Input forms for content contributers
- Example: a developer defines a form schema for a particular abstract data type (e.g. a real estate agent or a press release)
- A marketing contributor would then fill out this form without having to write any HTML
- Output templates and static file generation
- When content is submitted, templates get triggered to convert the abstract content into static files (HTML, XML, JSP, etc)
- Staging preview capabilities
- Mutli-site delivery
- Some of our content goes to www.redfin.com and some goes to seattle.redfin.com, sfbay.redfin.com, etc
- This content should all be housed in one repository
- Multi-server deployment
- URL Control
- Versioning, release branches, and rollbacks
We chose some open source candidates:
We started off by looking at open source platforms, and we considered an insane amount of platforms by looking through a cms matrix. After some preliminary research, we narrowed our scope to a few candidates:
We found out right off the bat that Alfresco was the only enterprise-level CMS of the group. Drupal, Joomla, Mambo, and Plone were all lacking static content generation and URL control. They were also not capable of deploying to multiple web servers, hosting multiple sites. After a lot of fiddling, reading, and talking to support, we learned that Alfresco was not able to output static files in certain cases. For example, assume we have a collection of press release HTML files and a single page that lists each of these press releases. Alfresco required us to write our own JSP code using their API to create a dynamic list of press releases - they didn’t provide a template engine that could create a static list. We later learned that Alfresco is now able to create static files in cases such as the above, but we learned about this too late in the game.
We considered some proprietary candidates:
At this point we started researching proprietary CMS platforms such as Interwoven, RedDot, and CrownPeak, only to find that most of these services are insanely expensive. We needed something open source, but we thought we had considered all of them. During lunch one day I began ranting about my open source CMS frustration, when out of nowhere our Linux/data center operations magician says, “Why don’t you use Bricolage?” We took a look at Bricolage.
We found Bricolage!
It turns out that Bricolage has most of what we want. It uses a Mason templating engine that allows for static file creation, and it basically meets most of our other requirements.
Here’s a list of the things that it does very well:
- Bricolage’s data modeling methods are insanely powerful. Not only can you define different types of pages (they’re called stories in Bricolage), but you can also create HTML components (sub elements in Bricolage) that can be included in pages in any way. For example, you can define a bulleted list, a link, etc, which makes data entry for non-technical folks very easy.
- Similarly, Bricolage’s templating engine is insanely powerful. Each sub element only needs one template, and templates can be strategically chained to allow for very efficient template design.
- Deployment is simple and powerful. Bricolage offers a well-documented API that makes deploying to multiple sites on multiple servers seamless.
- Bricolage allows you to control URLs for each story by either putting the story in a particular category or by changing the slug of the story.
Here’s a list of the things that it does not do well:
- Bricolage’s admin panel is totally usable but very clunky.
- The mechanism for working with different branches (for example, one branch of production content and another for soon-to-be released content) is unnatural. Instead of being able to commit changes into different branches, you have to create a network of cloned stories and bucket these clones in different categories (ex: / is trunk, /dev/2.3 is 2.3_dev_branch, etc).
- Bricolage is mostly geared for managing story-based sites such as MacCentral, so sometimes its naming conventions are confusing for non-news sites such as Redfin.
- While the API is fairly well documented, discussions of the larger concepts and best practices are spread over multiple sites, mailing lists and power point presentations. This makes the learning curve fairly steep.
We’re very happy with our choice to use Bricolage. Our website is much more agile, and our engineering team is very happy to have our marketing team take over the deployment of new content.
Expect a post very soon talking about the details of how we implemented Bricolage.
September 11, 2007
I rounded up our developers and got a list of blogs that we all enjoy reading. I’ve included them below and also on the right sidebar under the “Blogs We Like” heading.
Ajaxian - http://ajaxian.com/
Joel on Software - http://www.joelonsoftware.com/
John Cook’s Venture Blog - http://blog.seattlepi.nwsource.com/venture/
lifehacker - http://lifehacker.com/
MS Virtual Earth Blog - http://blogs.msdn.com/virtualearth/default.aspx
Slashdot - http://slashdot.org/
TechCrunch - http://www.techcrunch.com/
Like a blog that’s not on this list? Write a comment!
August 30, 2007
As some of you may have noticed, we made the switch from Movable Type (v3.33) to WordPress MU on July 9th. We thought it would be a great idea to discuss why we made the switch as well as the technical requirements of making the switch. We’re currently serving seven blogs, containing 2,034 posts by 47 authors, with 1,924 comments. The switch took roughly 60 work hours including research, and the effort was led by me, an intern, with our product and ops teams supervising.
The most compelling reason for us to switch was WordPress’s usability — managing WordPress is strait up easier from a source code, data, and content management perspective (authoring, user management, etc). There were many specific reasons for the switch as well. First, WordPress, with all of its plugins, can offer an unbelievable amount of functionality. For example, with WordPress we could offer features such as author profiles and archive paging functionality. Our previous installation of Movable Type was also somewhat chaotic, making maintenance and expansion grueling. Find below a feature comparison between Movable Type and WordPress MU.
Keep in mind that the list of features below does not perfectly represent each platform’s feature set. The list instead contains features that we at Redfin wanted for our blog.
Though this chart suggests that WordPress is the better choice for us, we had to consider the side effects of switching, the largest side effect being older permalinks potentially being broken. Other side effects were a potential loss of data (posts, comments, authors), a requirement for more blogger training, and having to familiarize ourselves with a new platform. Once we decided that we were willing to deal with these side effects, we began the migration process.
Both Movable Type and WordPress MU offer importing and exporting functionality, which made the task of getting our data into WordPress very simple. The WordPress import function also requires that all authors be in the system before the import begins, so we added our authors before performing the import. The reason for this is because the WordPress import process has a step that forces the importer to make author correlations between the imported data and the WordPress author list. The author correlation step provides a list of authors that were found in the imported data and requests that the importer decide how these authors correlate to the authors in WordPress. Unfortunately, this feature was broken in our installation of WordPress, so we were forced to write a custom script to correct the WordPress MU database by using the old Movable Type database.
With our data in place, the next largest task was to ensure that our old permalinks be properly redirected. To do this, we wrote a script that used the Movable Type database to produce a large set of Apache rewrite rules that redirect old permalink requests. To limit the number of required rewrite rules, we configured our WordPress permalink structure to match Movable Type’s (/year/month/post_title_etc.html). This also required an additional WordPress plugin that forces permalinks to use underscores instead of the default hyphens.
The last hurdle we ran into during this migration process was achieving our desired link structure. WordPress MU allows blogs to either appear as sub domains (new_blog.domain.com) or folders (domain.com/new_blog). We wanted our blogs to be accessible by blog.redfin.com, sfbay.redfin.com/blog, and seattle.redfin.com/blog, etc, and after lots of fiddling with WordPress, we concluded that we could not use the sub domain option. To get around this, we configured WordPress to use folders (blog.redfin.com/sfbay, blog.redfin.com/seattle, etc). We then configured a virtual host for each blog, sfbay.redfin.com, seattle.redfin.com, etc, to reverse proxy the /blog folder of these virtual hosts to the blog.redfin.com/sfbay, blog.redfin.com/seattle, etc folders. The reverse proxy article showed us the road, but the path we took was slightly different. Instead of using ProxyPass and ProxyPassReverse, we used the [P] option in a RewriteRule. This allowed us to apply other rewrite rules to the /blog folder, where the ProxyPass and ProxyPassReverse option did not.
We’re very happy with WordPress MU. In fact, we’re happier with WordPress MU than we were with Movable Type. The migration process was not easy, but it was worth the benefits of switching to WordPress. Feel free to post some comments if you’d like more specifics about the switch.
