La Mirage Resort Condominiums is ideally located only 5 minutes from Port Aransas, Texas and 25 minutes from downtown Corpus Christi.  With such a great location on the Texas Gulf Coast, this condo resort is an attractive place to spend a vacation. La Mirage approached us a few months ago, and we built them a new Drupal vacation rental site. As always, we recommend doing a comprehensive SEO setup along with their web project, in order to ensure that we’ve done the basic minimal items, along the lines of 301 redirects, xml site maps, and the like, that facilitate a new web project’s ongoing success with the search engines.

This is where things get interesting; La Mirage was having some issues with a rogue owner of 3 units in the complex who chose to manage and market their 3 properties on their own. Showing the initiative that sets Blue Tent apart from your average web company, Tim (the SEM Account Manager assigned to La Mirage) decided to tackle this problem as part of La Mirage’s SEO setup. The rogue owner maintained their own site that was ranking higher than La Mirage on the search engine results page for our client’s own name. After La Mirage became our client, these erroneous search results couldn’t continue. As you can tell, this situation was causing conflicts with customers mistaking the rogue owner for La Mirage.

We’ve talked about the power of claiming your local business listing, and this case was no exception.  When searching local or “Places” listings, the rogue owner was coming up with their contact information even though it was La Mirage’s (the actual condo management company’s) guest reviews, and location page.  After some persistence, we were able to get things straightened out and take proper ownership of the “Places” page.  This one small step, among other things, has already made a difference in the battle for top search engine rankings, moving La Mirage up and correcting the previous misinformation.  Let us implore you one more time; claim your local business listings, if not the competition might swipe your traffic!

Hilton Head Rentals & Golf, an established vacation rental company with the widest and best selection of lodging throughout Hilton Head Island, had a well-established web presence. But their website was sorely in need of an updated design and improved functionality. To that end, we undertook a complete redesign of the aesthetics, navigation and functionality of their website. We created a warm, airy design with a rotating slide show as a focal point of the homepage–making visitors feel as if they’re already standing on the beach. We also completely revamped the navigation to make it more user-friendly with the addition of flyouts that quickly guide visitors straight to specific pages of the site. And we built it on the Drupal content management system, an intuitive, secure and scalable platform that will serve our client well for years to come.

Search features include a search by area map, and search widgets on the homepage and interior pages make it easy to find the perfect vacation rental on Hilton Head. The search results and property information displayed is powered by Rental Network Software’s (RNS) property management system. This approach provides site visitors with the most up-to-date property and availability information possible, as well as a seamless transition from the main site, to the booking engine.

We also cleaned up their Google Analytics configuration to include cross-domain and e-commerce tracking and have been busy refining their search engine marketing strategy  and email marketing programs as well.

One of the primary reasons why this vacation rental redesign was so successful was due to the proactive participation from the client. A successful web project depends as much on the client’s performance, leadership, and engagement, as it does on us; the vendor you’ve hired to build it. In short, it’s a two way street. Congratulations to the HHRG team for their enthusiasm and engagement in the project – we look forward to seeing more of your site visitors turn into new customers!

Performance testing The Economist Online using The Grinder

Presented by David Strauss of Four Kitchens

The only way to get close to accurate load testing for a real site is to use a replica of production servers and infrastructure.  You must have a solid testing framework that includes hardware, software & tools, and scripts and configurations specific to your site’s needs. Load testing should not be done on production “live” sites or servers.

Hardware that must be added in addition to standard web servers, database servers, etc. is a load testing controller and load injectors.  The load injectors send the web page requests to the dev servers, and the testing controller manages the load injectors.  You need multiple load injectors in order to come close to simulating a real-world scenario.

The point of testing is to find out where the breaks or bottlenecks happen, to find see where problems will be happening and be able to measure their severity. Your next step after testing is to track down the cause of the problem, develop a solution, implement it and run the performance tests again to see if the problem is improved.

Tools

The Grinder

• Load testing software
• Written in Jython

Using The Grinder

• Write some unit tests as sanity checks
• Test actions performed by logged-in users (voting, viewing, editing)
• Test variety of data, some was behind a paywall
• Test hard enough that you can actually break the site. (This is done on development machines, not the live site.)
• Write tests that simulate a live load
• Some Issues that can be discovered
  • Menu Rebuild Stampede
  • Variable Cache Rebuild Stampede

Innotop

• MySQL monitoring tool

VarnishHist

• Included when install Varnish (a reverse proxy server, usually installed to improve performance)
• Histogram view of your Varnish cache
• See when it is having to send lengthy requests back to Apache

HTTP Traffic Proportion Analyzer

• Safe to run on live sites.
• Analyze traffic patterns on live sites. Use this data to help you develop good tests based on actual traffic, not just guesses.
• Can group into buckets (usually based on section of the site, but can be grouped by many custom rules.)

Further Notes

They spent about ten times the amount of time developing and running the tests, compared to fixing the problems that were discovered in running the tests.  Working out the fixes was fairly quick, once the actual causes were known.

More Grinder tips on the Four Kitchens wiki.

How Drupal 7 Fields are changing the way you write modules

In Drupal 6, you used hook_nodeapi() and created a table

In Drupal 7, you create a Field.

Fields are shared between entities. Define once, reuse on different things (nodes, comments, users).

Anatomy

• Schema = storage
• Widget = how to edit. the editor’s interface.
• Formatter = how to display the contents of the field
• Settings = global or per-instance
• Bundle = entity type

Field API

• starts with hook_field_info()
• defines the schema, formatter info, widget info.

Entities (are the new nodes)

• high level object
• fieldable (can have fields attached)
• revisionable (can have revisions)
• can have bundles (sub-types. content types are a current example.)
• can have a URI
• can have build modes (Full, Teaser, RSS, Tile, etc.)

Entity API

• hook_entity_info()
• hook_entity_ [load | insert | update] (no delete)
• entity_load (no save or delete)

Entity API module fills in the missing pieces, such as hook_entity_delete() and entity_save().

Application

Nodes and Comments can share the definition and data of the same field.

Creating an Issue tracker. This was demonstrated in the session.

• Used an custom content type of “Issue”
• Added a “Severity” field in content type and in comment.
• Custom Module: sets default value, adds checkbox to content type settings, updates value of node when submitting the comment.

Don’t use nodes for anything that is not content. (This might be a big change in thinking.)

• Create your own entities instead of creating custom content types.
• Examples: Group, Product.

If extending an existing content type, or something defined by another module, use entities. Don’t create your own tables; let the entities API handle that for you.

Rely on the Views module to display your entities. (Views is not yet aware of alternate data storage engines, such as MongoDB and Flickr.)

Upgrade path

1. Start with doing a simple upgrade of existing modules.
2. Next, start rethinking how to make better use of fields, entities, and bundles.

Open Source in the Cloud Era

On the rise: data capture devices, cloud based data stores (e.g. google docs), and data displays (augmented reality such as google goggles). Again: more intelligent data capturing devices, and the data being stored in huge stores by large companies, such as google and facebook.

Movement toward an “Internet OS”

Who owns this collected data? If it’s “them” do they want to share it like we do? If we want to own it, we’d better get busy creating an open cloud or open network.  This is after all how the internet became popular.

Data.gov is an example of data stores being made more open.

“Government 2.0″ is DIY on a civic scale. Drupal is a DIY web platform.

Views for developers

Focus is mostly on views 3, which is currently under active development and does not yet have a stable release. (Views 2 is very stable.)

The stack:

• what = handlers
• how = plugins (styles, pagers, rows)
• where = display, access, exposed forms

Plugins

• only one per view
• themeable: display, style, pager, exposed filter
• non-themeable: access, arguments, validation, caching, query

Handlers

• can be multiple per view
• fields (select)
• filters & arguments (where)
• sort
• relationships
• area plugins (header, footer)

Example modules

(my biggest takeaway from the session was to go study existing views modules, as well as the views module itself.)

Study views_tree module

• start with hook_views_api()
• Uses mainly FormAPI, just add fields
• No “Save” callbacks are needed. They are handled automatically by the views module.

Area Plugin

• this is a handler.
• See the Views Link Area module

Access Plugin

• see the demonstration Fizzbin module

A Match Made in the Cloud – How to Best Take Advantage of Cloud Technologies with Drupal Sites

First example: Mercury

• Mercury is a complete technology stack, preconfigured with industry and Drupal-oriented best practices.
• Includes Apache Solr, Memcache, APC, Varnish, MySQL tuning

Amazon Web Services (AWS) = “Computing”.  All about computing, oriented more around computer scientists than the average web developer. Generally too complex and tinkery.

Rackspace Cloud = “Hosting”. All about web hosting, geared around web developers who want to host their sites.

• Provides full DNS, console access, integrated backups, CPU Bursting, root access
• Supports libcoud API
• Also available: cloud files and Limelight CDN

Mercury and Rackspace Cloud integration

• Order a Mercury instance at http://getpantheon.com/get-mercury.
• In a few minutes, a VPS cloud server will be available for you at Rackspace, completely configured with best practice technology for Drupal.
• As updates are added to Mercury, your server instance will receive them using the bcfg2 configuration management tool.

Rackspace API enables:

• setting up load balancing
• temporary servers for heavy tasks or expected traffic spikes
• clustering

Plans for next steps

• More linux distros: Ubuntu Lucid, Centos, Debian, and more
• CDN Integration with Pressflow
• Drupal 7
• Site Import Wizard

Later in 2010

• Start using Git as a version control system
• Integration with automated testing systems such as Hudson
• Aegir pre-installed or readily available
• Monitoring and uptime alerts
• Integration with Drizzle (a MySQL replacement) and Cassandra
• Clustering and High Availability configurations ready to go
• Customize and save builds for new sites

Main Big Goals

• Enable confidence, a “sure thing” for both enterprise and individuals.
• Hosting for small sites should be automatically ready to scale.

Parlez vous Internet? Ignore the rest of the world at your own risk.

Two main methods of localizing a Drupal site were presented: manually translating your site, and using a service called ICanLocalize.com.

The Manual Method

Many different things to translate: Site name, slogan, custom menu items, menu items from views, categories and terms, content, ….

Three main categories of translatables

1. User Interface
2. Strings created by admin (such as field names, cck names)
3. Content created by users

Important modules

• Core Modules: Locale and Content Translation modules
• Contributed modules: Internationalization, Localization Client which imports interface translations from localize.drupal.org, Localization Update which eases translation of the rest of the interface

First Steps

• Add languages to your site
• Set language negotiation settings (“path prefix with language fallback” was recommended.)

Menus

• Don’t print menus directly in them. Include them as blocks instead.
• You have the choice of using a separate menu per theme, or translating each menu item individually.

Content Types

• Enable multilingual, with translation.
• Set current language as default.
• Require a language.

Enable the language switcher block

On all blocks, set a translation. Then translate the text of the blocks by using the translation interface.

Multilingual variables

• Override in settings.php
• Examples: site name, slogan, frontpage, site footer
• Edit settings.php, re-save the settings page in Drupal, then start translating

Translating a node

• On node, go to the Translation tab
• Creates a copy of the node, for the different language
• Edit menu title here
• Now, there are more links listed in the menu.
• Go back to existing menu items and specify language.

Views

• Add filter for node translation
• Use the translation client for the menu title and page title.

Forums options

• Separate set of terms (forums) for each language (this is generally preferred.)
• Translate each term into each language

ICanLocalize.com

Drupal module to connect to icanlocalize

Provides human translators, quick turnaround, automated Drupal integration.

Other notes

Drupal sets the language header. Search engines normally detect this and are aware of the language the page is written in.

The focus of Planning and Executing a Successful Drupal Implementation was primarily on “Hard Drupal Projects,” not so much on simpler projects.

First steps, educate the client

• Explain terminology of the web and of Drupal.
• Explain how open source works.
• It’s not magic. It does take planning and work.
• Set expectations: timeline, client responsibilities, polishing, deployment, content loading.

Communicate effectively. Send regular status reports.

Drupal (and web technology in general) can be difficult.

Planning

Documentation

• Write more of a Starter Guide. Not so much of a full-blown documentation of every little bit of the site.
• Creating a short screencast of how to manage the site can go a long way.

Regular testing by stakeholders (typically, the client)

• Are details right?
• Is this meeting their needs?
• Does it look great?

• Make them part of the team.
• They must be accountable and work hard with you.

Executing

Important: having the right team assembled is essential to executing a successful project

• Project Manager
• Analyst (Solutions Architect) — Solidfies requirements, specs, might build out some content types.
• Designer
• Web Producer
• Developers (plural!) — segmented logically

Be a soccer team (each team member can play multiple positions) not a base ball team (each team member has clearly limited boundaries of work). — Be flexible.

Adopt “Agile” principles.

• Deliver in iterations. (Each iteration produces a functional deliverable)
• Be firm on scope, flexible on features. (scope = amount of work, features = exactly which things get done)

Intra-Team communication

• Use a task management tool.
• Use some form of real time communication when needed.

Insist on quality. Is the operation buggy? Is the code or assembly sloppy?

Soft skills such as communication style and working smoothly in a team are very important.

• Being multi-disciplined, cross-trained.
• Understanding the larger Drupal ecosystem.

Defining Scope and Requirements

Site Map

• Visual representation of pages and hierarchy.
• First step only. This usually can not be complete when planning a complex project.

Brainstorm and sketch

Move on to more detailed wireframes with annotations

• Be very detailed
• A developer should be able to pick these up and run with the buildout.

3rd Party Integration

• Have system diagrams (either obtain or create them)
• Understand the larger system that you are integrating with. How does the organization use it, how does it affect the organization, and how does your development piece affect them?

Document the specs of what is needed.  A wiki is a good option.  It doesn’t have to be formal.

Design Comps. Often this is the “ah ha!” moment for the client. “So that is what you’re talking about!”

Defining scope and requirements can be challenging, so use proven techniques.

Common Challenges

Replace bad habits that the client may have. Watch the client work.

Structure content properly. Some content structures are simple, some do need to be complex. Just make sure that the data structure is correct and meaningful. Also consider permissions when creating data structures.

Represent content relationships correctly. (example: noderelationships module)

Use taxonomy effectively. Controlled (pre-set categories) vs. free (tagging) vs. auto (calais, 3rd party services).

Present a clear admin interface. Write help text that is clear and concise.

Adjust the styles used in the wysiwyg to match those used in the site.  Also reduce the buttons that are in the wysiwyg tool bar to only what the client needs.

Allow editors to curate (this was for a specific use case.) — Meet the needs of editors and writers. Consider the needs of everyone who will be experiencing the site.

Provide for editorial workflow

• Custom sorts (controlled by editor)
• Specific fields for different accurences. “home grid title” for the title of a story when displayed in a grid on the home page, for example.

Differentiate between authors (offline person, possibly multiple authors for an article) and users (CMS logins, people who load the article onto the site.)

Improve search with Apache Solr

• Provides facets.
• Allows site admin to bias certain nodes or content types.
• Allows site admin to exclude certain nodes or content types.

Pay attention to roles and permissions

• Test each role
• Use as few roles as possible.
• Start with scaled-back permissions. Add permissions as roles need them.

Migrate content accurately

• Usually requires some custom scripts as well as some cleanup by hand.
• Some tools are available to ease the import process (table wizard and migrate modules, feeds module, querypath).
• Sometimes hand-entering is the best way.

Estimating

• Ask lots of questions.
• Dig in to client background and circumstance.
• These are required to get a good perspective the work that will be involved.

Session Notes: D7UX: How to integrate the core Drupal 7 usability improvements with your module

There has been a big effort in Drupal 7 to improve usability. This talk discussed how to implement these features in your custom Drupal 7 modules. (Or on contrib modules you might be helping with.)

• New IA (Information Architecture)
• Shortcuts bar
• Overlay
• Admin theme
• Local actions
• Modules page (Help | Permissions | Configures — for each module)

The usability improvements that will be included in Drupal 7 are only part of what has been designed in the larger D7UX effort.  More will be implemented in Drupal 8.

Very rough coding notes:

Contextual links

in hook_menu() add:

‘context’ => menu_context_page | menu_context_inline

Contextual links are helpful, supplemental. But they should not be relied upon exclusively. They should still be accessible in the regular admin menu system.

Dashboard

Any normal block is automatically available for use in the dashboard.

Local Actions

in hook_menu() add:

‘type’ => menu_local_action

These are different from tabs. Tabs are things that you look at, see. Typically lists of things or current configurations.  Local Actions are something you *do* such as ADD content.

Overlay (and admin)

Why: because people often lose context when doing an admin task. With the overlay module, when you are through with your admin task, you are returned to where you were before you started.

You tell a link to open in the overlay by specifying that it is an “admin” link. Implement hook_admin_paths()

signup_admin_paths() {
$paths = array (
‘node/*/signup => TRUE
)
return $paths;
}

To alter admin paths set by other modules, use hook_admin_paths_alter()

Vertical Tabs

In form definition

‘#group’ => ‘additional_settings’

Additional Resources

http://drupal.org/ui-standards