Tuesday, May 21, 2013

Presentation: Vagrant as part of a production workflow

The following presentation was given on 24 July 2012 to the DevOps Brisbane group. Some of the technical detail about Vagrant is outdated but I think it provides a good overview of why moving to a "Infrastructure as code" setup makes a lot of sense.

Friday, May 17, 2013

eZ Publish 5 Virtual Machine

One of the most common issues of newcomers to eZ Publish is the setup of a system suitable for running it. Without a correctly configured system in place they usually do not get beyond the installation process and abandon their evaluation before having experienced the product. 

The eZ Publish puppet module is an attempt to codify the requirements  for running eZ Publish and provide a means for automatically creating a system suitable for running it - no more following a checklist of "setting up eZ Publish on XYZ".

The eZ Publish 5 Virtual Machine can be found on github at https://github.com/brucem/vagrant-puppet-ezpublish.  It combines Vagrant, VirtualBox & Puppet to generate a VM with the current eZ Publish community version (2013.4) installed and ready to be configured.


The README.md provides details of the requirements and how to use it.

Vagrant is a system that orchestrates the automatic creation and configuration of systems. It has been used to define a system that provides a platform to run eZ Publish.

By default Vagrant uses VirtualBox to provide a local Virtual Machine environment. This allows for systems (guests) to be created and destroyed locally in isolation to your own system (host). For example if you want to test a version of eZ Publish that requires a newer version of PHP that you have installed, you can do so using a VM solution and not have to update your local system, potentially breaking other functionally.

Many thanks to +André Rømcke for his input and help in polishing both the eZ Publish puppet module &  eZ Publish 5 Virtual Machine setup. 

I'm happy to receive issues with or without pull requests on either repository via github.


If you use it or have any questions let me know in the comments!

Friday, April 19, 2013

New eZ Publish Puppet Module

In my last blog post I wrote about an eZ Publish Puppet module that I'd created that could be used to setup and install eZ Publish.

Its been awhile since I'd done any work on it (and blogged for that matter!) and in that time both Puppet and Vagrant have matured considerably. I've also had more experience creating Puppet modules and managing systems with Puppet.

I've decided to re-write the eZ Publish module from scratch utilising Puppets own modules for apache and mysql.

The result is available on GitHub and in the Puppet Module Forge.

The overall functionality in the new module is essentially the same as the old one, but elements have been decoupled.  This allows for the various components that make up an eZ Publish "stack" to be combined to match the desired architecture. e.g. a standalone system with the database and application on the one system to a clustered systems where different components are on separate systems.

In the coming weeks I hope to post some examples of how it can be used to configure different architectures.

Currently the module is specific to Debian/Ubuntu systems but I hope to update it in the near future to also work with Redhat/CentOS systems.

Wednesday, December 07, 2011

Hassle free eZ Publish setup

This is not another how to setup Ubuntu to run eZ Publish guide...well not really.

One of the biggest hurdles when getting started with eZ Publish is successfully installing the CMS. This process often fails because the system on which it is being installed is not configured correctly. If you do not have a helpful systems administrator handy it can be quite difficult to get past the initial steps.

There are a number of solutions that allow you to manage the configuration of computer systems. Two of the most popular are Puppet & Chef. These systems allow you to create "recipes" of how systems should be setup.

I've put together a eZ Publish module for Puppet that:
  • Configures a system suitable to run eZ Publish 
  • Setup Virtual Hosts configured to run eZ Publish 
  • Sets up a Database 
  • Downloads eZ Publish 
  • Configures a kickstart.ini file

It's a bit like a guide to setting up eZ publish on Ubuntu but doesn't require you to manually follow the steps (and that you can keep under revision control)! It can also be rerun time and time again with the same result.

This doesn't help unless you have a system to apply it to and it would help if it was a system that you could trash if you wanted.

Introducing Vagrant
Vagrant is a very cool tool that manages VirtualBox virtual machines (VM). It will also provision (setup, configure) those VMs with Puppet (and Chef). This makes it an great complementary tool for testing your Puppet configurations. Vagrant can also be used to manage multiple VMs, allowing it to be used to test configurations with more than one system (e.g. separate systems running application and database).

I've configured a Vagrant setup that utilises the eZ Publish module for puppet module to create a single VM that will be setup to run eZ Publish (Community Project 2011.11).

Getting up and running
Once you have required software installed on your local system and the eZ Publish sample Vagrant setup checked out you can have a VM with the latest version of eZ Publish running by running one command - "vagrant up".

Running this for the first time will take a while as the base Ubuntu 10.4 LTS image needs to be downloaded. It's around 400Mb so depending on your connection speed it may take some time. The good news is that the base image is only downloaded once and can be used for other Vagrant managed VMs.

Once the "vagrant up" command has finished running visiting http://33.33.33.10/ will display the eZ Publish configuration wizard. A kickstart.ini file has been pre-configured with all the details to perform the installation.

Clicking "Next" will run the installation with the default parameters defined in the eZ Publish Puppet module. This will take a little time as the packages for the eZFlow Clean Site need to be downloaded and installed.

Quick guide to Vagrant commands
The VM can be shutdown by running "vagrant halt" and started again by running "vagrant up". reloading is as simple as "vagrant reload"

Once you are finished you can destroy the VM by running "vagrant destroy". Running "vagrant up" will setup new VM and provision it from scratch.

More detailed documentation can be found on the Vagrant site.

Last words
I've done my testing on a Linux system but you should be able to try this out on any system that can run ruby & VirtualBox. The Vagrant site has a guide on getting systems setup for Windows, Mac OS X, Linux, and Solaris.

I'd be interested to hearing any feedback you might have.

It's been a while since my last post...

I've just checked my blog and was quite shocked to see that's my last post was almost 2 years ago!  In my defence I've been quite busy and managed to get quite a few things done in that time.  A few highlights have been:
Hopefully I'll have some time for blogging again soon!

Wednesday, December 23, 2009

eZ Publish Admin Prototype extension

Following on from yesterdays post on checking out the eZ Admin Interface prototype I've created an extension that can be easily downloaded, installed and enabled.
  1. Download the extension from here
  2. Copy to your extension directory and untar:

    tar xzf admin2prototype.tgz

  3. Enable it in your admin siteaccess by editing settings/siteaccess/site_admin/site.ini.append.php and adding:

    [ExtensionSettings]
    ActiveAccessExtensions[]=admin2prototype

  4. Clear the cache
To disable, simply remove the settings from step 3 above and clear the cache.

Note: If you enable the extension via the admin interface (Setup -> Extensions) this will effect all site accesses including your front end ones. 

Things to check out in the prototype:
  1. Lack of Shop and Design tabs - these are disabled by default in eZ Publish 4.3
  2. Hidden right menu. Click on the [+] to expand
  3. Content menu (Left Hand side under Content, Users & Media Tabs) can be variably sized. Grab the bottom right hand corner and drag to desired size
  4. Different context menu when left clicking on items in the content menu (I'm not a fan of how sub items cover the top menu items)
  5. Drag and drop block ordering (When editing a Front Page in eZ Flow) Apparently this is eZ Flow 2.0 (included with eZ 4.2)
  6. Full screen editing (this rocks)
  7. Edit action buttons (Send for Publishing, Store Draft, Discard) replicated at top of edit page
If you have issues with the extension let me know.

Comments on the prototype should be made here. Remember that this is a prototype!
    I'll attempt to keep the download up to date with the latest changes.

    Tuesday, December 22, 2009

    How to install the eZ Admin Interface prototype

    The Admin Interface Refresh project has had a concept implemented that can be reviewed live with an eZ Publish install. This is a guide on how to get things working.

    The new Admin Interface design is a prototype and it's constantly being refined so don't try this on your production servers.

    Starting from a clean install of eZ Publish 4.2 with the the eZ Flow package (with content)
    1. Change into the design directory
      # cd design
    2. Checkout the design
      # svn co http://pubsvn.ez.no/nextgen/trunk/design/admin2
    3. Edit settings/siteaccess/admin_site/site.ini.append.php and change the SiteDesign to admin2
      [DesignSettings]
      SiteDesign=admin2
    4. Grab new menu.ini - this is required to display the left hand menus under Setup and My account.
      # cd settings/siteaccess/admin_site/
      # wget http://pubsvn.ez.no/nextgen/trunk/settings/menu.ini
    5. Clear the cache
    You should now be able to view the new interface and it should look something like this:


    To revert back to the original interface:
    1. Remove the menu.ini from the admin siteaccess
    2. Set the SiteDesign back to admin_site
    3. Clear cache 
    Updates are occurring on a regular basis so you can update the design with svn:
    1. Change directory into the new admin design
      cd design/admin2
    2. Update from subversion
      svn update
    3. Clear the cache
    Note: If you are attempting to add this to a an existing site make sure you have the ezjscore extension installed.

    Let me know if this doesn't work for you via comments and I'll check it out and update the post.

    UPDATEI've created an extension version to make it even easier to check out.

    Thursday, December 17, 2009

    eZ Publish Community Day to be streamed live!

    The eZ Publish winter conference is a free conference being held in Geneva on 21st and 22nd of January 2010, with the Community Day being held on the 22nd.

    If you are like me and can't make it there is some exciting news! eZ Publish's Community Manager Nicolas Pastorino has setup a Ustream account for the eZ Community and scheduled a event for the community day.

    That's right the Community Day will be streamed live!

    Show your support of this wonderful initiative by signing up to Ustream and RSVPing to the event! (Note that two events for they day one for the morning session and another for the afternoon one.)

    The Ustream interface allows for a twitter channel as well as inline chat allowing participation throughout the day.  The twitter hastag is #ezwintercf.

    If you know anyone interested in eZ Publish get them to RSVP as well.  It will be great to have as many people as possible participating!

    If you have any experience producing an live event like this or can help out on the day please contact Nicolas and let him know what you can offer.

    Photo Credit: http://www.flickr.com/photos/mathplourde/3727973992/

    eZ Publish Admin redesign - Some suggestions

    I've covered two larger topics in other blog posts (Admin interface users & Dashboards) so in this post I'm going to cover a number of smaller suggestions I have for the Admin Interface refresh. 

    Some of the items have been suggested by others and been added to the specification - I hope I've noted these.

    Improve underlying HTML

    Damien has already mentioned linking labels with their related input via the for attribute.  I wasn't aware that there was already an issue for this but I made a start of adding a Accessibility & Usability Improvements project that currently "associates labels with specific form elements, adds "required" class to required input elements to allow attachment of javascript validation".

    The project looked at "fixing" the datatype edit templates and the modifications can be viewed in the CHANGELOG.

    Specific changes I'd like to see in the underlying HTML are:
    • Labels linked to input fields
    • Labels only used when associated to an input field
    • Fieldsets & legends used to group associated input fields
    • A class applied to input field that are required
    • A class applied to input fields based on datatype
    • Size attributes removed from input fields and CSS used to set the size

    These changes will not only improve the accessibility of the admin interface but also improve the front end as well.

    Javascript validation

    I'm not sure there is any Javascript validation of forms in eZ Publish. Adding required input validation is relatively easy especially based on the suggestions above as this would allow for simply selecting input elements with the "required" class and ensuring they contain content before the form was submitted.

    While maybe not exactly matched to eZ Publish needs the JQuery validations plugin is a good example of how this can be done.

    The eZUser datatype is a great example where both Javascript and AJAX can be combined to improve usability. The validation rules ( from when I put together the Accessibility & Usability Improvements project1) is:

    Password: If [UserSettings] GeneratePasswordIfEmpty = true empty passwords are allowed and one will be generated if the password is blank.
    Password Length:  Stored in [UserSettings] MinPasswordLength or default to 3 if not present (in ezuser datatype)
    Password cannot be set to "password"
    Passwords must match

    Email: Must be valid email
    Email: If the email can be used for Authentication the email address must be unique

    Login: must be unique
    Login: cannot be empty

    This is a perfect opportunity to utilise Javascript to ensure the validation rules are followed and that Email and Login are unique using AJAX.

    Primary and Secondary Actions

    Luke Wroblewski begins the "Primary and Secondary Actions" chapter of his book Web Form Design:
    Labels provide the questions that forms ask people. Input fields give people a way to answer those questions. Neither of these items, however actually lets people complete a form.  That singular responsibility rests with actions.
    Many pages in the admin interface have lots of form buttons. Currently they are either:

    Colour

    Meaning

    Examples

    Blue
    Main Function
    Send for publishing, Store Draft, Discard draft
    Dark Grey
    Supplementary Function
    Add object, Disable Editor
    Light Grey
    Disabled
    Remove Object (Related Object attribute where there's not an existing association)

    By default a content edit page has (at least) 5 main function buttons, all coloured blue.  This makes it extremely difficult to scan for the correct path to complete the task.

    Most forms have a primary and secondary action. The primary action being the "save", "continue" or" "I'm finished here, what's next?" button, they enable completion.  Secondary actions are those where the user wants to do the opposite - "Cancel", "Go Back", "Get me outa here!".

    For example when editing content in eZ Publish users are most likely to complete the form by clicking on either "Send for Publishing" (primary) or "Discard Draft" (secondary).  These buttons need to stand out on the page so that they are immediately obvious and the user doesn't have to search for them.

    Suggestions:
    • Ascertain and clearly differentiate primary and secondary action buttons on each page
    • Apply consistent styling to primary and secondary buttons through out the site
    • If there is no obvious primary and secondary actions don't use them (e.g. cache management )
    • Use existing colour scheme (or similar) for all other buttons.  These are less used and it's OK for users to have to scan the page to find them.
    Damien has a similar suggestion:
    Buttons in the admin interface should be of a different colour depending on the action they trigger. For instance cancel buttons can be orange, publish buttons blue, remove buttons red, ... The main key here is to be consistent over all the interface.
    This was also added to the specification (#1 as a "Could").

    My concerns with this is that some pages may end up looking like some has dropped skittles over it. Some pages contain too many actions that may be coloured. I believe that this would limit the ability of users to quickly find and complete their desired action.

    Ability to add help text

    The ability to add help text for each attribute of a content class will be a major improvement.  This not only allows for better interfaces for users but will save an incredible amount of time for developers who currently have to customise each form to include this type of information.

    Note: This has been added to the specification but I'd like to see it a little higher up the list. Much more important than any drag and drop functionality IMHO!

    Setup tab

    The setup tab is the dumping ground of functionality that doesn't fit anywhere else. There are functions located under this tab what don't have anything to do with "Setup" e.g. Search statistics, Collected Information and URL Management.  I suspect that new users may have some trouble finding this functionality.

    The Setup Tab also contains mix of functionality that Content Editors may require access to (the non setup one listed above are a good start as well as URL management translator and wildcards, and Global settings ) and others that they should not e.g. Cache management, Classes etc.

    In fact unless the Content Editor has the ability to clear the cache (setup -> managecache) they'll see an error when visiting the setup tab.

    Thinking about who is using the interface I'd suggest that the functionality that is available under the Setup Tab is split into Development setup tasks and Editor configuration tasks. Another way of thinking about this tasks that are performed during development and those that are performed during the day to day running of a site.

    Suggestions:
    • Only the options that the current user has access to should be displayed (This is in the specification #1.5)
    • The Setup Tab link should go to a landing page that lists the tasks with a brief description of the functionality provided.
    • Group related functionality (put the URL alias management,  workflow links together)

    Ability to use old interface

    Pain of some level usually goes hand in hand with the introduction of change of any kind. I'd hope that along with the new interface there is  the ability for the old Admin interface to be used. The interface is one component of eZ Publish 4.3 but one that have a very big impact. 

    The use of the new interface should not be a barrier to upgrading and taking advantage of the new features and bug fixes.

    I know of at least one site that is still on eZ Publish 3.4 because the cost of retraining staff in the new interface was a significant project in itself! (The current interface was introduced in eZ Publish 3.5)

    Christmas reading

    I can't recommend enough Luke Wroblewski's book Web Form Design: Filling in the blanks. It's a must read if you are creating forms on the web.  It won't tell you how to create the perfect form but presents a number of best practices all backed up with research.

    1 Since I reviewed these additional checks on the Login are allowed.