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.

    Tuesday, December 15, 2009

    eZ Publish Admin redesign - Dashboard = OpenSocial?

    In the preface to the current Admin interface specification the last paragraph caught my eye:
    A overview of user task need a dashboard, where she can follow here own content, approval and other tasks she might do on a regular basis.
    I recently saw a demo of the latest version of the bug tracking system JIRA 4.0 by Atlassian. It used an OpenSocial dashboard to allow users to customise their homepage to access and interact with information that was important to them.  The system not only displays JIRA widgets but any OpenSocial widgets (and those from other Atlassian products). You can check out a video of it in action here and more information on how Atlassian is using OpenSocial here.

    What is OpenSocial? From the official site:
    OpenSocial defines a common API for social applications across multiple websites. With standard JavaScript and HTML,
    developers can create apps that access a social network's friends and update feeds.
    Google personal home page is an example of an OpenSocial dashboard but basically there are 2 parts the gadget consumer/container (dashboard) and the gadget producer (the gadgets themselves),

    Atlassian use the Apache Shindig software to provide OpenSocial functionality in their products.  This is a good match as it's a Java application as are the Atlassian products.  The good news for eZ Publish is that there is a PHP implementation.

    While it's probably beyond the scope of the the current Admin Interface redesign I believe that this is technology that would fit nicely with eZ Publish. OpenSocial is based on Open Standards and has wide industry support from the likes of google, linkedin, yahoo!, myspace, saleforce and ebay.

    Another benefit is that the gadgets are easy to write as they are based on HTML, CSS, Javascript and REST.  Each eZ Publish module could have a number of gadgets that provide views of information that could be displayed on the dashboard. Examples may include: Items requiring workflow approval, a search, number of new users,  new content since last visit or number of active sessions.

    Using OpenSocial not only solves the eZ Publish Admin dashboard problem but opens up eZ Publish to many new opportunities. I can see this as a killer feature for Intranet or Extranet sites.

    Paul Forsyth started an OpenSocial project page when it was launched in November 2007. The project doesn't seem to contain much at this stage but perhaps this can be used as the basis for a proof of concept project? Sound interesting?

    Monday, December 14, 2009

    eZ Publish Admin redesign - Think of the Editors!

    It's been a while since I first posted about the Admin interface redesign that will be part of the eZ Publish 4.3 (due 30 March 2010).  Since that time there have been some great input (here, here, & here) from the eZ Publish community as well as a transparent and inclusive design process from eZ Publish.

    I'd like to congratulate eZ Systems on their approach with this process and encourage any eZ Publish users to have a look at the specification and the prototype of proposed layout changes and add their voice to the process by commenting on the blog post.

    In moving forward with any changes I believe that it's important to understand the users of the system and the tasks they are attempting to carry out. This allows for suggestions and potential changes to be "tested" against a rule of "How does this help [ROLE] complete task [TASK]?"

    In my experience users of the Admin interface can be split into two broad groups:
    1. Content editors, whose role is to use the Admin interface to accomplish a number of tasks that largely revolve around creating and editing content.  These are the day-today users of the Admin interface, but utilise a small subset of the functionality.
    2. Developers, who work extensively with most components within the Admin Interface (including those that a Content Editor would use) while a site is being built. However once a site is live will visits to the Admin Interface are only to resolve issues or add new functionality.

    I believe that the most important group of the two are the Content Editors. They are (usually) our clients, pay the bills and use the system extensively once it's live. They are also the ones who talk to others (potential clients) about the system.  So as well as adding your comments to the blog post, ask your clients what issues they have and improvements they'd like to see.

    Photo credit:  http://www.flickr.com/photos/sybrenstuvel/2468506922/

    Friday, October 23, 2009

    Review - eZ Publish 4: Enterprise Web Sites Step-by-Step

    It's been a while since there's been a eZ Publish release from Packt Publishing but the long awaited eZ Publish 4: Enterprise Web Sites Step-by-Step has finally hit the shelves.  Written by Francesco Fullone and Francesco Trucchia it spans 292 pages and details building a site using eZ Publish 4 from server preparation, eZ Publish installation, implementation and deployment. A imaginary magazine site is used to illustrate examples throughout the book.  A number of topics are covered that will help those new to eZ Publish get up and running.

    The book is based on eZ publish 4.0.1 and while the current version of eZ publish is 4.2.0 the content is still relevant and there are several notes that refer to features and changes in newer versions.

    Packt has provided Chapter 6 - Creating a Design as a free sample download (PDF). A chapter overview is available on the book site as well as a full table of contents.

    This is a review of the PDF version of the book provided by Packt Publishing.

    Text and structure

    eZ Publish 4: Enterprise Web Sites Step-by-Step is not an enjoyable book, in fact I found it quite painful.  The text does not read well and would appear only to have been given the briefest of edits.  Some examples of this are:

     The Achilles' heel of eZ Publish is the template system subframework that cannot, and should not, be overrated, and that is used as a true programming language.
    and
    When we translate a content object, its main URL will change accordingly. But we should only need to create aliases for a single language. For example, we should create an alias for the contact page in the staff section of the site only for the Italian version.
    Unfortunately these are not isolated examples.  I found myself having to re-read passages several times to understand what was being said.

    The text overuses words like "moreover" (33 instances), is not consistent in it's use of terminology and formatting.  The authors make use of the "we" as if they are coming on the journey with the reader instead of instructing them.  There is a explanatory "Note" on breadcrumbs that appears twice. I would expected that these types of issues would have been picked up in the editing process.  The problem is that the number and severity of issues distract the reader from the knowledge the authors are tyring to convey.

    Some chapters just do not deliver what the chapter titles imply. Chapter 5, titled "Creating an Extension" details how to create an empty extension (directory structure, files). The details of creating the actual content of the extension is found in subsequent chapters. 

    The structure of the book is also problematic. At the end of Cchapter 5 the authors take the reader through creating a packaged extension, while at this stage of the book we only have an empty extension.  I don't understand why this information was not moved towards the end of the book.  Another example of this is that the first screenshot of the admin interface login screen appears in Chapter 7, where the first point the user will have come across the screen is in Chapter 3.

    The requirements of the magazine site that is being used as an example are peppered throughout the book.  Giving the users a chapter that detailed the requirements, site-map, write frames and mockups up front would better mimic a real world development process help in explaining how this is to be achieved in the chapters where the site is implemented.

    Image Quality

    The screen shots in the book are not clear and difficult to read. The majority are not annotated with explanation of the image left to the accompanying text.  Images that are annotated only have highlighted regions (circled in red) and are not labeled. 

    There are a number of images that are acknowledged in the accompanying text to come from the the "official eZ System documentation" [sic] according to the footer on the page in which they appear, are licenced under the GNU Free Documentation Licence.  The copyright page in the book makes no mention of these images.  I'm not sure if eZ Systems granted permission for their use but I would have expected some official acknowledgement on the copyright page. 

    The use of these images (regardless of acknowledgement) is disappointing as the book doesn't present anything new. If the reader has read the official documentation may feel ripped off on recognising them. There aren't many images aside from screen shots in the book and more diagrams would have helped better explain some the the underlying structures that are essential to understand.

    Technical Aspects

    Technically the book is OK with a couple of places where best practices are not followed.  One example is using a numerical attribute id instead of an attribute identifier string when fetching related objects (the latter is more easily understood and more portable).  Some statements are quite strong (saying that $node.children must be used instead of using a fetch to retrieve the children of the current node) and may be true in some circumstances but would not be considered a rule that must be followed always.

    Some interesting concepts of using separate siteaccesses for development, staging and production are raised but I would have liked to see some more detail on the development workflows around these.

    The examples used throughout the book rely on command line access to a Unix based system specifically Debian & Red Hat Linux.  If you are not familiar with Unix then you may have trouble following some examples especially if any unexpected errors occur.  I suspect that Windows users would struggle.

    The last chapter (12) on Deployment focuses on using the 3rd party eZ Deploy extension.  This seems to be a strange inclusion for this book as I would have expected details of using FTP or rSync naively to be detailed in this chapter. 

    The Deployment chapter includes the use of Selenium and PHPUnit for functional testing but doesn't detail testing of the functionality that has been built in the example.  This is where the inclusion of a a "Requirements" chapter could have been used as the basis for quality assurance with example tests being written to demonstrate how specific requirements can be tested with these tools.

    Conclusion

    In conclusion there is some good technical information in eZ Publish 4: Enterprise Web Sites Step-by-Step but the language and structure make it difficult to follow. New users to eZ Publish may end up more confused than when they started, while as a reference the book isn't ideal as the chapter titles don't always deliver what is expected.

    It should be pointed out that the issues with the book do not lie with the authors but with the editors at Packt.  I'm a little baffled that the book was published as it is and would believe if told that I've received a early draft.  I'm not sure that I'd be very pleased if I'd paid for a copy.

    Tuesday, October 13, 2009

    eZ Publish Admin to get some loving


    The current eZ Publish admin interface first appeared almost 5 years ago in version 3.5 ( released Dec 2004 ). At the time it was a massive improvement from the previous version. Since it's release there have been many advances in web technologies, javascript libraries and browser support.

    When the eZ publish roadmap was updated in July this year it indicated that version eZ Publish 4.3 (due 30 March 2010) will include a redesign of the admin interface. From the roadmap:

    eZ Publish Admin interface

    Redesign of the current User Interface including :
    • More Ajax based usability features
    • Revamped look and feel
    • Improved management of Object States
    • Dashboard
    A good discussion of the admin interface occurred in the forums originating in Jan 2009 and was reinvigorated after the roadmap announcement. The thread is a rather long one and winds it's way around a number of topics (JavaScript libraries, projects/contributions site, admin interface) but is well worth reading. The issue of JavaScript libraries has largely been addressed in the ezjscore project (which will be bundled as part of eZ 4.3) but other issues of seems largely up in the air.

    Last week Morten Zetlitz tweeted from the Nordic eZ Partner Meeting "Itchy fingers after eZ Systems promises a new admin UI by 2010. We need something like Drupal has, an eZ UX initiative." The project he is referring to is the Drupal 7 UX Project which is a concerted effort to improve usability. The project has the following principles:
    1. Make the most frequent tasks easy and less frequent tasks achievable
    2. Design for the 80%
    3. Privilege the Content Creator
    4. Make the default settings smart
    I agree with Morten in that a eZ Publish UX Project would be a great idea. Unlike the Drupal project an eZ Publish one should focus on more than the Content Creator. The eZ publish admin interface is the place where the majority of content creation, user management and site configuration takes place. It's used by a number of people playing a number of roles to
    perform many varied tasks. It's been around for quite some time so there is quite a bit of experience and interface knowledge out there. Fundamental changes need to be made with caution to avoid incurring retraining for existing users.

    I see a eZ Publish UX Project fleshing out the roadmap list & requirements from the forums to provide an interface style guide as well as providing a user centered information architecture.

    One of the UX people involved in the project, Leisa Reichelt has some insightful observations of the Drupal process, but I suspect that given that eZ Publish is a very different project that these may not apply, in fact it's likely to have a different set of issues all together.

    If you like the idea of an eZ Publish UX Project drop me an email or comment on the blog.

    Tony Wood from Vision with Technology has set up a survey to collect information which will be presented to eZ as feedback. I encourage you to fill out the survey, but also post to your ideas to the forum or your blogs and comment here.

    This post has turned out to be more about background information and a call to action than I'd first intended. I've got a bunch of notes on ideas for the Admin interface that I'll turn into a blog post which I'll hopefully get up in the next couple of days.

    Photo Credit: http://www.flickr.com/photos/captkodak/373622275/

    Monday, October 05, 2009

    Adding negative filters to eZ Find

    I've been doing some work with eZ Find recently and have come across an issue that has also troubled others. While eZ Find includes some powerful filtering options there's no support for negative filters.

    This can easily remedied by adding "NOT" as an allowed Boolean Operator and adding specific handling of NOT to the final query construction to ezfind/classes/ezfezpsolrquerybuilder.php. This small change allows NOT to be used in the same manor as the existing AND and OR operators.

    An enhancement request has been lodged that includes the following patch.

    diff --git a/classes/ezfezpsolrquerybuilder.php b/classes/ezfezpsolrquerybuilder.php
    index 3c997dc..f30813c 100755
    --- a/classes/ezfezpsolrquerybuilder.php
    +++ b/classes/ezfezpsolrquerybuilder.php
    @@ -852,7 +852,10 @@ class ezfeZPSolrQueryBuilder
    }
    }

    - return implode( " $booleanOperator ", $filterQueryList );
    + if ( $booleanOperator == 'NOT' )
    + return ' NOT ( ' . implode( " OR ", $filterQueryList ) .')';
    + else
    + return implode( " $booleanOperator ", $filterQueryList );
    }

    /**
    @@ -1590,5 +1593,7 @@ ezfeZPSolrQueryBuilder::$FindINI = eZINI::instance( 'ezfind.ini' );
    ezfeZPSolrQueryBuilder::$allowedBooleanOperators = array( 'AND',
    'and',
    'OR',
    - 'or' );
    + 'or',
    + 'NOT',
    + 'not' );
    ?>

    To fetch results where the myattr attribute of myclass is not equal to 0 you can write:
    {def $results = fetch('ezfind', 'search', hash(
    'query', $query,
    'filter', array('not', 'myclass/myattr:0')
    ))}

    This query will return any content that where myclass/myattr != 0. This will include objects from other classes, so to limit the results to object of myclass you need to add a class_id filter:
    {def $results = fetch('ezfind', 'search', hash(
    'query', $query,
    'filter', array('not', 'myclass/myattr:0'),
    'class_id', 'myclass')
    ))}

    Great to see the documentation for eZ Find 2.1 make it into HTML format!

    Wednesday, September 09, 2009

    Thursday, August 27, 2009

    eZ Publish 4.2 to include Star Rating module

    Prior to this years eZ conference I was approached by eZ systems to allow for my Star Rating module to be included in the eZ Publish distribution. All and all it was a pretty painless process that simply required the signing of the Contributor Licence Agreement (CLA).

    The CLA is an interesting legal document as it doesn't specify the particular piece of software that it refers to. I was informed that this is by design as it's intended to be a general agreement where specifics are communicated seperately.

    eZ Systems have created a new project for eZ Star Rating on the eZ Projects site where a number of improvments have been made, including:
    • Given it the eZ treatment, better comments, cleaned up code formatting
    • Removed references for full 4.x compatability
    • Changed from xajax to ezjscore + yui3 for ajax calls
    • Merged rating code from ezcore / ezyui
    • Code cleanup (cs & phpdoc and code name conventions)
    • Added fetch operators
    • Added postgresql support
    • Added internationalisation
    The upshot is that the Star Rating module will remain under the GPL, I retain copyright of the original work and it's now installed as part of eZ Flow in eZ publish 4.2 (of cource it can still be used on it's own). You can check it out in eZ Publish 4.2.0alpha1.

    The eZ Projects site states
    NOTE: THIS IS TEMPORARY PROJECT. WILL BE MERGE WITH http://projects.ez.no/starrating
    I haven't had any communication with eZ Systems regarding this matter and I can't see the point in doing a merge. I don't intend to make any further changes to the original so from eZ Publish 4.2 onwards (there appears to be a reliance on core changes that are in eZ publish 4.2) use the eZ publish version.

    Wednesday, August 26, 2009

    eZ Publish 4.2 User module to get workflow triggers

    The upcoming eZ Publish 4.2 (due September 29th) will add a bunch of workflow triggers to the user module. Workflows will be able to be attached to the following views:
    This allows for custom workflow events to be run before and after each of these operations, resulting in a massive increase in the flexibility when interacting with users.

    Some potential uses that come to mind:
    • Emailing users upon activation
    • Creating user specific content upon activation
    • Emailing users when they change their password
    An effect of these changes is that code for these actions is isolated into a class allowing calls to be easily made from elsewhere. Prior to these changes to activate a user outside of the user/activate view you would have replicate code contained in the view. This will also make it easier to test.

    I would have loved to see triggers added for login and logout but I suspect that would be a more involved exercise.

    Unfortunately this enhancement did not make it into eZ Publish 4.2.0alpha1

    SVN changes: http://pubsvn.ez.no/websvn2/revision.php?repname=nextgen&path=%2F&rev=23884
    Changes were based on the enhancement request http://issues.ez.no/IssueView.php?Id=14882

    Tuesday, August 04, 2009

    PHPList extension upgraded for eZ Publish 4.x

    Thanks to sponsorship by DB Informatics the PHPList subscription synchronise extension has been upgraded to work with PHP5 and eZ Publish 4.x

    This extension allows for the addition of a Subscribe to list attribute to be added to the User content class. Users are able to subscribe or unsubscribe from PHPList mailing list by editing their profile.