Archive: May 2008

SolutionSet specializes in extending company’s brands to the web. For most of our clients, this means more than creating a static website with a few pages of sales copy and the occasional press release. Our clients want their websites to reflect the constant innovation and dynamic nature of their companies. They want their customers to see and participate in their companies’ evolution.

To that end, most of the websites we build today employ a technology platform referred to as a “Content Management System” or CMS.

At its core, a CMS allows website managers to quickly add and modify content on their websites without making physical changes to the web server or files used to display pages—this is a boon to companies with busy IT personnel (or no IT personnel), since it enables content authors to publish their articles directly to the website, usually via a special administrative interface which requires little or no knowledge of HTML.

However, many modern CMS platforms go well beyond this basic functionality, providing capabilities such as workflow approval chains, pre-set publish and expire dates for content, support for multiple document types (PDFs, Word docs, PowerPoint presentations, etc.), RSS feeds, blogs, forums, email notifications, integrated search, permissions-based access to content, user-generated content, and more. The most sophisticated systems can integrate with your company’s existing infrastructure, such as Active Directory or SharePoint.

So it’s not unusual for companies to feel overwhelmed when selecting a CMS. There are solutions for virtually every need and budget, and when the right packaged solution isn’t available, customization is always an option.

Based on our experience implementing many CMSs for many clients, here are some key points to keep in mind when selecting a CMS:

• Bring together stake-holders early in the selection process. If any one group feels left out of the selection process, later buy-in will be difficult. Include marketing, communications, PR, IT, and other appropriate departments/groups/individuals.
• A CMS is a blank canvas—regardless of the features and capabilities it exposes, you’ll need to plan on investing time during the development of your website to ensure that the implementation is reflecting your company’s brand, culture, and workflow. SolutionSet is accustomed to working closely with clients to design an implementation that meets precisely with your needs.
• Balance all of the potential features with the reality of supporting them. Blogs, forums, email blasts, etc., demand ongoing attention from the site owner to ensure that they are serving the needs of the brand. Make a sober assessment of how your site will be supported over the long-haul. Identify the responsible personnel and provide the necessary training.
• Recognize that your site need not “do it all” on Day 1. In many cases, SolutionSet can recommend a full-featured CMS that will allow for “phased deployment”. That is, certain features can be turned on only when your company is ready for them. This way, you can start small without locking yourself out of future growth.
• Look for “synergies” across your existing systems to find ways to integrate your website more closely with your internal operations. If you already have a process for publishing press releases, determine if the CMS can tap into that so that new releases are automatically published on the site. If you have an existing document store, see if the CMS can pull directly from that store for publishing documentation, white-papers, etc. on the web.
• Start early. For most companies, the web is only growing in importance as a medium for connecting closely with customers, employees and partners. Your CMS will likely need to support this growth for at least 3-5 years. Don’t rush the selection process.

Below is a list of features and questions to help get you started with assessing your CMS needs. It is by no means exhaustive; during an engagement, SolutionSet will typically provide more in-depth guidance.

Content Editing Capabilities. Check all that apply:

• Easy content creation/editing without HTML knowledge
• Easy creation of new page “template” designs for display of content
• Preview content on site before it is available publically
• Set content “go-live” and “expire” dates
• Create an “approval chain” for content creators/approvers
• Publish content in multiple languages/locales
• Organize and display content by category
• Provide historical tracking of content and “rollback” capabilities

Special Features

• Specialized content such as blogs or wikis
• Support for documents, such as PDFs, Word docs, video/audio, zip archives, etc.
• Support for “user-generated” content, such as forums, ratings, or commenting
• Integration with existing systems such as Active Directory, Salesforce.com, SharePoint, e-commerce
• Restricted access to content based on user permissions
• Customized content based on user profiles
• Email generation

Technical Support (answer each question as completely as possible)

• Who will be internally responsible for maintaining the CMS servers? What training will they need? How much of their time will be required?
• Does the CMS vendor provide on-going support and upgrades?
• If new features are added to an existing site, such as forums, who will be responsible for monitoring them?
• What technology stack do you prefer? Open source (LAMP), Microsoft (.Net), JAVA, ColdFusion?
• What stack will integrate best with your current systems?

Performance

• How many visitors will your site need to support?
• How scalable does the platform need to be? How easily do you need to be able add capacity?
• How geographically diverse is your viewership? Will you need high-performance on a global basis?

Costs

• How does the CMS vendor license their platform? Per server? Per domain name? Per user? Open source?
• How much will it cost to build out the functionality and features you need?
• What are the ongoing (maintenance and support) costs?
• How much will internal support cost?

Although selecting a CMS platform for your website may seem overwhelming, taking the time to do a thorough job will leave you with a website that serves your company’s needs now and well into the future. And of course, we’re here to make the process as painless as possible.

We don’t usually think much of “breaking” bread with friends and family. Between tinkling glasses, interesting conversation and passed salad bowls, the lowly loaf of bread is often overlooked. It sits there, surrounded by crumbs, waiting to be tossed away when stale. But not all loaves are created equal.

Modeled after a stalk of wheat, pain d’epi offers an experience far different than the usual baguette. Rather than a hunk of bread that must be torn apart or sliced in advance, pain d’epi consists of conveniently sized segments that are easily broken off. A perfectly sized portion for everyone around the table. When served at a restaurant, this ingenious design avoids waste. Rather than a single loaf for every party, servers simply break off the required segments: two for the couple in the corner, four for the family by the window, and a full loaf of eight for the party in the back room.

It’s usable bread, perfectly suited to its task.

We notice things like this at SolutionSet. It’s the sort of attention to detail and usability that we bring to all of our projects. And, of course, we like to eat . .

So you’re in a situation where you need a controlled search, and stuck trying to search multiple columns, this might be a great situation for Sphinx. What is Sphinx? Very simply, it is a full text indexing, search solution.

http://www.sphinxsearch.com

Ok I’ve downloaded Sphinx, now what?
Now you are going to want to create your very first index. This isn’t as scary as you think, let’s have a look at the controller for your search, sphinx.conf.

First off, we need to define where we are going to get the information to be indexed:

source m1
{
type = mysql
sql_host = localhost
sql_user = username
sql_pass = password
sql_db = csp
sql_port = 3306

Easy enough, next up things get a little more interesting, you need to decided whether you want to use a standard or ranged query. This largely depends on index size, as an index is created usually by accessing a database instance, and a long query can tie up you database (not what you want for a production server).

A simple index might be created as so:

sql_query = select * from members;
}

Now we want to create our index,

index ind_m1
{
source = m1
path = /var/data/m1
docinfo = extern
mlock = 0
min_word_len = 1
charset_type = sbcs
morphology = none
min_infix_len = 2
enable_star = 1
}

Important things here are matching source from above, & real writable location on the filesystem. If you want to do the equivalent of a wildcard search you will need to include the final two lines.

That’s it… Now we are ready to create our index. Simply run:

/path/to/binary/indexer –all

All done.. Great, now we just just need to search that index from php.
The search daemon is run as a separate executable, /path/to/binary/searchd, once that is up and running, you can search from a php script.

require ( “Sphinx/api/sphinxapi.php” );
$cl = new SphinxClient ();
$cl->SetServer ( $host, $port );
$res = $cl->Query ( $query, $index );

There you go, if all went well, you should be retrieving the results from your index that match your $query.

Happy Searching!!

SolutionSet has been using Prototype for a few years now and it has served our needs well. But on any AJAX enabled site, you will end up having dozens of JavaScript files to include on your page. This presents 2 problems that will make your site appear to perform slowly in a browser:

1. In many cases there will be upwards of 300kb of JavaScript on the page
2. JavaScript files download in order, one-at-a-time, halting all other downloads

Of course there are some well known solutions to some of these problems including using Gzip (mod_deflate in Apache) and including your JavaScript in the footer of the page to allow everything else to load first. Most of these hints can be gleaned from the YSlow plugin for Firebug. And of course, the number one rule for making your site load faster is to minimize HTTP requests.

One relatively easy way to reduce requests is to combine all of your JavaScript files into one big file. This will save round trips to the server and since the JavaScript files only load one-at-time, it will never be slower to include on large file instead of multiple smaller files. If you are using a compiled language, such as ASP.NET, it makes sense to use JavaScript bundling as part of your build process. However for PHP most people don’t really use build scripts. There is a simple way to combine all of the files together on-the-fly using PHP that is robust and cached on the server-side which makes the system scalable as well.

On several sites that SolutionSet has built using our CSP platform we use JavaScript bundling. You can see it in action at Alias Design. We’ve set up a “bundle” folder and we point to files in that directory with a query string that indicates which files to include in the bundle. We’re using mod_rewrite in Apache to detect a request for new bundles, then we find all of the requested files and save them in a file. Additionally we use our own custom JavaScript minifying code which is similar to JSMin. If you you are using Prototype it doesn’t cooperate well with JSMin or other similar tools like YUI Compressor so it would be best to have your script skip Prototype when it is minifying scripts.

The request for a bundle looks similar to this:

bundle/b82e26e477aeadbe2959d5af55ea9542.js?bundle_files[]=js%2Fprototype.js&bundle_files[]=js%2Fshowthemes.js

This requests a file named “b82e26e477aeadbe2959d5af55ea9542.js” which is usually an md5 string of all of the files that are in this particular bundle. After that we create a query string array named “bundle_files” which contains a relative path and filename to each file. It is important to only allow files with a JS extension that are in specified files. Otherwise this is an obvious security concern.

The mod_rewrite rule would look like this in your .htaccess file:

RewriteEngine on
RewriteBase    /bundle
RewriteCond %{REQUEST_FILENAME}       !-f
RewriteRule [a-f0-9]{32}\.(js)$ bundle.php

Your bundle PHP file, as described above would do the following:

1. loop the $_GET[’bundle_files’] array
2. open a file pointer to the requested bundle ($_SERVER[’REQUEST_URI’] = ‘/bundle/b82e26e477aeadbe2959d5af55ea9542.js’)
3. collect each file after checking that
   1. the file has a JS extension
   2. is located in an approved “safe” directory
4. read the file using file_get_contents()
5. Compress the file using JSMin
6. Write the compressed file to the end of the bundle file
7. After writing all of the requested files to the bundle
   1. send the proper content header “Content-Type: application/x-javascript”
   2. return the bundle file to the browser using a chunked stream
8. All future requests for the bundle will be served directly by Apache.

At some point in the future we will be open sourcing our example bundle script and our custom minifying script. The same process can be used for combining CSS files which suffer the same bottlenecking concerns as JavaScript files.