Posts by "David Leffler"

Preparing to Upgrade to v2.3.0

Version 2.3.0 is the follow-up to version 2.2.3 and was given a version bump due to the many new features added.  It also marks a 'slowing down' of version releases as it's purposely been five months since the last release.  While it doesn't require as many changes as the move to v2.2.0 (which deprecated all the old 1.x code), it would still be wise to note and adhere these following changes.

The navigation showall_Flydown view for a bootstrap based theme now includes all the associated markup in the view instead of in the theme template.  Therefore if you use this view or have based your custom theme on 'bootstraptheme' (it is the default menu for the boostraptheme) you MUST edit your theme templates (including subthemes)

  • The older code looked something like:
    <!-- navigation bar/menu -->
    <div class="navigation navbar <?php echo (MENU_LOCATION) ? 'navbar-'.MENU_LOCATION : '' ?>">
      <div class="navbar-inner">
        <div class="container"> <!-- toggle for collapsed/mobile navbar content -->
          <a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse">
          <span class="icon-bar"></span> <span class="icon-bar"></span>
          <span class="icon-bar"></span> </a>
          <!-- menu header -->
          <a class="brand" href="<?php echo URL_FULL ?>"><?php echo ORGANIZATION_NAME ?></a>
          <!-- menu -->
          <?php expTheme::module(array("controller"=>"navigation","action"=>"showall","view"=>"showall_Flydown")); ?>
        </div>
      </div>
    </div>
    <div class="navbar-spacer"></div>
    <div class="navbar-spacer-bottom"></div>
  • This is simply replaced by:
    <?php expTheme::module(array("controller"=>"navigation","action"=>"showall","view"=>"showall_Flydown")); ?>
  • Depending on which exponent version you created your theme from (first shipped w/ v2.2.0), you may not have all those lines above.  In fact, in v2.2.0, the menu was a theme custom menu simply call 'showall'

There may be duplicate Search Engine Friendly (SEF) URLs.  We include an optional upgrade script to correct this issue, but do NOT run it automatically.  Duplicate SEF URLs can cause issues when using the new 'Workflow' feature.

If your pages/content seems to have disappeared for non-admin users, you should first (re)run the 'Fix Sectionrefs' upgrade script.  If that doesn't fix the problem, you need to ensure the 'Disable Privacy Feature' is selected found in 'Confgure Website' Exponent menu item, under the 'Display' tab.

If you have manually loaded the 'jQuery' script, it may be colliding with the auto-loaded jQuery script.  The BEST method to ensure that jQuery is auto-loaded, is to set the theme framework (in the theme template/subtheme templates) to either 'jquery'.  jQuery is also auto-loaded with the bootstrap theme frameworks.  Documentation found here.

Again, not a lot of earth shattering changes required, but we always recommend doing a test before upgrading a production web site, just in case.

Which WYSIWYG Editor to Choose?

Version 2.3.0 includes a second optional What You See Is What You Get (WYSIWG) editor called TinyMCE.  While in most cases you'll probably want to stick with the venerable CKEditor, TinyMCE will work on Android devices, where CKEditor does not.TinyMCE WYSIWYG Editor

To enable the TinyMCE editor, open ''Configure Website' from the Exponent menu.  Then select the 'WYSIWYG Editor' tab and select 'TinyMCE' as the system text editor.  For the time being, the TinyMCE text editor is only an option and not the default.

In addition to working on an Android device, TinyMCE offers most of the features found in the CKEditor.  However, some features are not as advanced as with CKEditor.  TinyMCE also offers a menu bar which may contain additional commands not found in the toolbar.

You may not have a need to use the new TinyMCE editor, but we offer it for those requiring WYSIWYG editing on Android based devices.

Using the new elFinder File Manager

Version 2.3.0 includes a new modern File Manager which (in the long run) will make it much easier to manage and work with uploaded files.  In general, elFinder follows an 'operating system' paradigm, so it should be fairly logical to begin using, but it is much different than the old Exponent File Manager.elFinder File Manager

Some of the (new) elFinder features include:

  • True file folders for easier file organization
  • Drag and Drop file upload and moving (CAUTION: while you can move a file, it may break any references within WYSIWYG text since they are embedded as hard reference links instead of as an expFile object)
  • File cut/copy/paste
  • Single 'pane' file management and upload, instead of the old separate file uploader
  • Command toolbar to access most actions directly
  • ​Item option (context) menus
  • 'Touch' enabled to work with mobile devices
  • Integrated file archive creation and extraction (not available on windows servers)
  • Icon and details folder views

To enable the new elFinder file manager, open ''Configure Website' from the Exponent menu.  Then select the 'File Manger' tab and select 'elFinder' as the system file manager.  For the time being, the elFinder file manager is only an option and not the default file manager.

How to use these new features:

  1. Basic Window Layout
    • As with most modern file mangers there are three basic areas or panes in the elFinder window
      • Toolbar - is located at the top of the window
      • Folder Tree Pane - is located to the left side of the window.  The folder hierarchy can be collapse or expanded and the pane width may be adjusted
      • File Pane - this is the largest area of the window which displays all the file in the current folder or those matching a search request
    • elFinder also uses context menus which appear on folders, files, or the File Pane background
  2. File Uploads
    • ​​The easiest way to upload files into the file manager is to simply drag them from your PC desktop/file manager and drop them on/into the folder you choose.
    • You may also click on the 'Select files to upload' toolbar button, or choose the 'Upload files' context menu item from the file pane.  This will present a window to drag/drop files, to paste a file, or open a file select dialog to choose the files to upload.
  3. File Selection
    • The easiest way to select a file when the file manager is opened from within an editor or edit item dialog, is to simply double-click the file.
    • You may also click on the 'Select files' toolbar button, or choose 'Select' from the context menu for the file(s)
    • You may select more than one file by using the control/shift method or a drag box.
  4. File Operations/Management
    • You may cut, copy, paste, duplicate, rename, delete, or preview a file using the appropriate toolbar button or context menu item
    • You can display the files in the file pane as either large icons or a detailed list
    • You can sort the displayed files by name, size, kind, and date, in ascending or descending order
  5. Image Editing
    • elFinder includes integrated image resizing, cropping, and rotation using the 'Resize & Rotate' command
    • For more advanced editing, we now use an online service called Pixlr to provide full graphics editing features.  
    • As is the case with all commands, you can use the toolbar button or the context menu which will present you with a dialog to select either the full-blown Pixlr editor or Pixlr Express which has fewer features.
  6. Exponent File Management
    • The options to change file sharing, image title, image 'alt' title are now found in the 'Info' dialog of the file which can be displayed via toolbar or context menu
    • The 'sharing' status is changed instantly, but the 'title' and 'alt title' require you click on the 'update' button for the change to take place
    • You'll also see additional details such as file type, size, dimensions, file owner, etc...
    • There are also details about the file/folder found in the 'status' bar at the bottom of the window
    • There is also a 'Preview' command available to display/play images, videos, & mp3 files
  7. File Search
    • There is a built-in search feature using the input box in the toolbar.  Simply enter the phrase, press 'enter' and all the files in the system matching that phrase will be displayed, regardless of their folder location.
    • Click on the 'x' button or select a folder in the folder tree pane to clear the search.
  8. Transfer (back) to the Insert/Modify Link Dialog
    • If you are inserting a 'link' to a page into an editor instead of a link to a file, you can switch to the dialog with a list of pages available, the option to select a module on a page, or to switch back to the file manager.  This button is found on the toolbar to allow you to switch back to the Insert/Modify Link window.  It is located next to the toolbar 'Help' button.

Overall, we think you'll be pleased with the new elFinder File Manager and find it much simpler to use.

 

More About Less

less cssCSS3Back in version 2.0.8 we added the LESS ​stylesheet compiler to Exponent.  LESS is a dynamic stylesheet language which extends CSS with dynamic behavior such as variables, ​mixins, operations and functions.  This functionality makes it much easier to create flexible stylesheets since redundant styles and style variations can be handled by the compiler/server instead of the designer.  Though this addition to Exponent was primarily to support Twitter-Bootstrap, its use is increasing especially beginning with v2.2.3.

In this article our focus is on creating or updating .less stylesheets.  For information on how to incorporate .less style sheets into your custom theme, module, or view, please see this help doc.  The use of .less stylesheets in place of .css stylesheets is transparent within Exponent.  

In version 2.2.3 we convert all our core css stylesheets to .less, since we now also have custom 'mixins' to do some of the heavy lifting.  Mixins allow you to tie a bunch of properties and customizable values all into one nice little package.  Here’s an example:

/* Mixin */
.box-shadow (@x: 0px, @y: 3px, @blur: 5px, @color: #333) {
  -webkit-box-shadow: @x @y @blur rgba(0, 0, 0, @color);
  -moz-box-shadow: @x @y @blur rgba(0, 0, 0, @color);
  box-shadow: @x @y @blur rgba(0, 0, 0, @color);
}

This takes all of the box-shadow code needed for display on multiple browsers and wraps it up nicely into a single mixin that can be implemented with custom values (or the defaults that we used above). Now, instead of writing a huge chunk of code every time you want a box-shadow, this is all you need:

/* Implementation */
.somediv {
  .box-shadow(5px, 5px, 6px, #eee);
}

Pretty awesome right? When this code is compiled automatically by Exponent, it’ll create a the appropriate CSS stylesheet. You get a much more readable code without sacrificing browser compatibility.

In v2.2.3 we include a custom 'mixins' file which is located in /framework/core/assets/less/exponent.less.  This mixn may be included in your .less file by adding the following line to the top.

 @import '/framework/core/assets/less/exponent.less'

Here are some of the mixins found in exponent.less:

  • .border-radius and .border-radius-custom
  • .box-shadow and .drop-shadow
  • .gradient and .quick-gradient
  • .reflect
  • .opacity

Take a look at exponent.less to see all the included mixins, plus some implementation samples.

I think you'll appreciate how LESS can make your work 'more' productive and will consider using it in your next project.

Permit me to tell you a little about the next version

While v2.2.3 (when released) will focus on addressing issues in v2.2.2 and removing all the deprecated features and 0.9x compatibility, there will be a few minor new features and changes to the permissions system (final implementation will be based on your feedback to this article!).

New features include adding a 'copy' item command to the portfolio module, adding an optional 'force image resize' during a quick upload, and better theme support for mobile devices by use of optional 'touch' icons and the 'meta viewport' tag.  We may also be able to squeeze in a 'multi-day' feature to the event module along with external calendar (ical & google xml) feed caching.

However, the bigger changes will be to user/group permissions.  This will be accomplished by the addition of group global permissions (restrictions) and changing the way we deal with the 'create' permission.

Group Global Permissions - This new feature provides greater control over what basic users are allowed to do (or more accurately 'are prevented from doing').  These restrictions will be implemented within a 'User Group', therefore the 'user' must be assigned to a 'group' in order to enforce these 'global permissions'.  However, this method will ensure that upgrading from a previous version will continue to operate transparently the same as before.  But if you want to apply them to all basic users, you can set the group as a 'default group' to be assigned to all new users.  Based on user requests, Global Permissions/Restrictions already include:

  • Prevent File Uploading - will prevent the user from being able to upload a new file.  They will still be able to select existing files from the file manager.
  • Prevent User Profile Changes - will prevent the user from being able to change their user profile (email address, profile extensions, etc...)  This does NOT affect the user being able to change their password since we already have a global setting to 'disable user password change requests' in the Site Configuration settings.
  • Disable Slingbar (Exponent Menu Bar) or Slingbar menus - will  'hide' the 'Exponent', 'Files', and/or 'Pages' menus from the user (leaving only the 'User' menu).  Or you can select to hide the entire 'Exponent Menu Bar'.  Under normal circumstances, a user with any permission on the site would see the 'slingbar.'  This feature allows greater control on preventing it's display.

Enhanced 'Create' Permission - Unlike the group global permission feature, the enhanced 'create' permission feature may affect some users ability to perform actions after a version upgrade!  Currently (v2.2.2), the 'create' permission also always implies/provides the 'edit' permission.  This means that if you can create new module items, you will also be able to edit all module items (but still requires a 'delete' permission to remove the item).  However under the new (v2.2.3) system, the 'create' permission would be separate from the 'edit' permission.  What's NEW is that the 'create' permission (without an 'edit' permission) would also allow you to edit any module item you had created (no change here), but NOT the other users' module items.  To edit other users' module items, you'd also need to have an 'edit' permission.  The same applies to deleting a module item.  If you have a 'create' permission, you may delete a module item you created, but would need a 'delete' permission to delete other users' module items.  In practice, this new feature will allow a module to have many users who are able to create and manage their own items, but not have any influence on the other module users (unless you also gave them an 'edit', 'delete', or 'manage' permission).

As a permissions primer...permissions cascade down through any child objects such as pages, containers, and the module.  The 'manage' permission implies/provides ALL permissions.  The 'configure' permission is needed to access module configuration settings (change the module's action, view, and other module settings).  The 'create' permission is needed to create new items or modules (and up to v2.2.2 also provides an 'edit' permission).  The 'edit' permission is needed to edit an existing module item.  And the 'delete' permission is needed to delete/remove an item or a module.  Admin users are always granted permission!

While this new approach to the 'create' permission should greatly enhance a multi-user site, it is not a complete solution.  There are some scenarios where a user would be allowed to 'create' a new module item, but NOT edit it (invoices, etc...).  It is recommended the developer create a new module controller method/add_permission for that instance.  Creating a stricter permission system would be very complex and time-consuming to implement.  However, there are plans to implement some 'workflow' features such as 'revisions' (allow rolling back to a previous item version) and 'approvals' (optionally require a user with approval permission to approve new or updated content).  These workflow features would not be as complex as those partially implemented in the 0.9x code, but should become very useful.  The workflow features are targeted for the v2.2.4 release.

If you have any suggestions to the above features especially the Group Global Permissions and Enhance Create Permission, please respond with a comment.

Bring Out Yer Dead!

Bring Out Yer Dead!Monty Python fans will quickly recognize the title phrase and remember the scene where he's not quite dead.  So begins this article on how to remove all the old, dead stuff from your Exponent site and custom theme.  Before the end of the year (probably v2.2.3 which tentatively will be a Thanksgiving/Christmas holiday/last release of 2013) we'll have stripped out several deprecated modules and no longer support older themes (deprecated function calls).

Deprecated Function Calls

  • The most prevalent deprecated call when hard-coding modules is that a 2.0 controller requires an 'action' parameter where all the old school modules only used a 'view' parameter.  The default action is ALWAYS 'showall' (if none is passed) and the default view is ALWAYS the action name (if none is passed).  Therefore if you simply updated an old function call by changing it to 'expTheme::module()' and did not ensure you passed an 'action' parameter...you may not see the correct view...especially if the view you requested was not a variant of the showall action.  
    • Take for instance, the Search module 'Show' view.  If you updated it to simply pass the 'view' parameter of 'show', it would attempt to display the 'showall_show' view with the showall action.  The easiest fix is to change the 'view' parameter to an 'action' parameter which will automatically use the same named view ('action'=>'show').
  • I've previously written about the other hard-coding function calls which must be replaced.  In v2.2.1 you'll now receive a deprecated theme call warning message when logged on as an admin.  The message will contain details about what file and line the deprecated call is on and a suggestion on the fix with a link to a more detailed help page.  (updating to 2.2.0 blog post) (theme update guide)

Deprecated Modules

  • The Headline module was marked as deprecated quite a while back and was fully removed in v2.2.0.  It is replaced by the Text module showall 'Headline' view.  This change is automatically accomplished in an upgrade by converting all Headline modules into Text modules with the Headline view.
  • The Flowplayer module uses a non-HTML5 compliant player and was replaced by a newer Media Player module.  The new Media Player module also plays simple YouTube links using the same player (YouTube module requires using the 'embed' code) so we've also deprecated the YouTube module.  Though they still exist, they will be completely removed as stated above.  There is currently an optional upgrade script to convert all Flowplayer and YouTube modules into Media Player modules.  Currently if you run a 0.9x Migration, it will create Flowplayer/YouTube modules which you can then upgrade to Media Player modules.  This will be changed once the deprecated modules are removed.
  • All the old school modules have been deprecated, replaced, and removed as of v2.2.0.  In fact, you'll notice the 'Old School' modules tab is missing from the Module Manager.  Any old school modules on the site will automatically be upgraded to work with their 2.0 controller replacement during an upgrade.

Updated Requirements?

  • And now that PHP v5.5 has been released, PHP v5.3 is no longer recommended (end of life) and PHP 5.2 is obsolete, we should consider updating the minimum PHP requirement be at least v5.3.1 (or one of the more robust iterations of v5.3) to allow some of the v5.3+ only PHP features such as namespaces, etc...

Facebook and Tweet Integration in v2.2.1

FacebookTwitterThe next release will introduce a new 'Facebook' module and optional Facebook 'Like' and Twitter 'Tweet' buttons to blog posts.  

The new Facebook module will allow you to insert a 'Like' button onto a page which points to the site, the page, or a custom url.  It will also allow you to insert a 'Like Box' (or timeline) onto a page.  These views interact with Facebook to display results from Facebook, and also update 'Likes' on Facebook.  There are several display options which reflect the same options offered by the widget on Facebook.com.

Blog posts may now optionally display Facebook 'Like' and/or Twitter 'Tweet' buttons at the bottom of each post.  These features should allow greater proliferation of your ideas and works.

Additionally, we've added a new optional 'Follow' button to the Twitter module view, and there will be a new (optional) user profile extension which allows creating a 'signature' which is automatically attached to the end of blog posts you create.

The 'Wizard' Returns to Exponent

The WizardOne feature which didn't make the move from Exponent 1.x to 2.x was the 'Wizard'...essentially a sequential set of forms.  Well 'ta-daaa', we're planning to have a wizard or paged-form feature in the next release (already in the 'develop' code branch)!  This will be a much simpler implementation than available in 1.x, as a 2.x paged form can easily be designed all in one place, instead of having to create separate form pages, etc...  This feature will be available in both the forms module/site forms (event registration now uses site forms) and in templates/views.

You may be asking, 'how does a paged form or wizard work?'  Well in many of the system forms, we use 'tabs' to segregate collections of input, and recently also introduced 'groups' to further segregate sets of controls on a page/tab.  These will still be used in most cases, but in some scenarios a sequential or progressive set of controls is more intuitive.  This is more evident in a complex form requiring a great deal of customer input such as a 'camp registration and release' form.  On the other hand, the 'site configuration' form is NOT intended to be sequential and would be practically unusable if it did not remain as a tabbed form.

How will a paged form work in Exponent?  In the form designer, it will be as simple as adding a 'form page break' control as the first/top control, and placing one where ever you want to begin a new 'form page'.  Exponent will do all the heaving lifting from that point.  If you want to revert to a standard form, you'd simply remove/delete the page break controls from that form using the form designer.  In practice a paged form would have at least two page breaks (including the top one) with one or more being the break(s) between the different pages.

The result will then look something like this.  Exponent performs input validation on all visible controls prior to moving to the next 'page.'  And as the development code matures prior to the next release, we will likely add form module configuration settings to enable/disable certain features like the 'page' description (Basic Information, etc...) appearing below the 'page' caption (Step 1, Step 2, etc...) AND also at the top of the current 'page', etc...

How will a paged form work within a template/view?  In the simplest sense a 'paged' form is simply one with controls grouped inside 'fieldsets' and then a jQuery plugin is used.  The {form} block function has been updated to accept a new 'paged' parameter which now also requires you pass an 'id' or 'name'.  Then within the form you group pages of control with the 'page' block with a required 'label' and an optional 'description' param.  Let's take a module view (mass-mailer) that is currently coded like this:

    {form action=mass_mail_out}
        {group label="Send this Message To"|gettext}
            {control type="checkbox" class="emailall" postfalse=1 name="allusers" label="All Site Users?"|gettext value=1 description='Uncheck to allow user/group/freeform selection'|gettext}
            {control type="checkbox" postfalse=1 name="batchsend" label="Batch Send?"|gettext value=1 checked=1 description='Hide email addresses from other users'|gettext}
            {userlistcontrol class="email" name="user_list" label="Users"}
            {grouplistcontrol class="email" name="group_list" label="Groups"}
            {control type="listbuilder" class="email" name="address_list" label="Other Addresses" size=5}
        {/group}
        {group label="Message"|gettext}
            {control type="text" name="subject" label="Subject"|gettext}
            {control type="html" name="body" label="Message"|gettext}
            {control type="uploader" name="attach" label="Attachment"|gettext description='Optionally send a file attachment'|gettext}
        {/group}
        {control type="buttongroup" submit="Send"|gettext cancel="Cancel"|gettext}
    {/form}

a 'paged' version (if we wanted one) is easily created and would be coded like this:

    {form action=mass_mail_out name='mass-mail' paged=1}
        {page label="Send this Message To"|gettext description="Select Recipients"}
            {control type="checkbox" class="emailall" postfalse=1 name="allusers" label="All Site Users?"|gettext value=1 description='Uncheck to allow user/group/freeform selection'|gettext}
            {control type="checkbox" postfalse=1 name="batchsend" label="Batch Send?"|gettext value=1 checked=1 description='Hide email addresses from other users'|gettext}
            {userlistcontrol class="email" name="user_list" label="Users"}
            {grouplistcontrol class="email" name="group_list" label="Groups"}
            {control type="listbuilder" class="email" name="address_list" label="Other Addresses" size=5}
        {/page}
        {page label="Message"|gettext description="Email Content"}
            {control type="text" name="subject" label="Subject"|gettext}
            {control type="html" name="body" label="Message"|gettext}
            {control type="uploader" name="attach" label="Attachment"|gettext description='Optionally send a file attachment'|gettext}
        {/page}
        {control type="buttongroup" submit="Send"|gettext cancel="Cancel"|gettext class='finish'}
    {/form}

As with all pre-release code, the specifics listed above are subject to change prior to the actual release.

We've also already added another 1.x feature missing in 2.x...'Configuration Profiles' which allows backing up and restoring the current site configuration (on the server).  This becomes really handy in a test or development environment as you can very quickly switch between databases and themes to test a new feature or customization.

Prepping Your Site for v2.2.0 (or how to deal with a major update)

(Update: we HAVE reverted to the name 'container' instead of 'container2' for release candidate1!)  Here are some tips and tutorials to help ensure your site is 'v2.2 ready'!  While there is really no show-stopping change moving from v2.1.1 to v2.2.0, the move to v2.2.0 will reveal any themes or custom views which haven't been updated to 2.0 standards.  In a pragmatic sense, though the upgrade must be run and completed to convert the database for use in v2.2.0, your site would continue to work using one of the shipped or add-on themes which are 2.2 ready.

Since this upgrade only affects a custom theme and/or custom views, that's where we'll need to look:

  • Theme 1.0 compatibility removed
    • This one is the easiest to spot and correct.  It will occur in the main theme template (/themes/mytheme/index.php) and the subthemes (found in the subthemes folder)
    • Calls to the deprecated 1.0 theme subsystem look like 'exponent_theme_method' instead of 'expTheme::method'  And moreso there are only three mandatory calls with a fourth recommended call for hard-coding other modules
      • expTheme::head(...) in the <head>...</head> section, this method is used in place of the deprecated exponent_theme_headerInfo(...) call
      • expTheme::main() in the main content area in the <body>...</body> section, this method is used in place of the deprecated exponent_theme_main() call.
      • expTheme:foot() at the bottom of the <body>...</body> section, this method is used in place of the deprecated exponent_theme_footerInfo() call.
      • expTheme::module(...) within the main content area for hard-coding (embedding) modules, this is THE single multi-purpose method to display a module in place of many deprecated calls: 
        exponent_theme_showSectionalModule(...), 
        expTheme::showSectionalModule(...), 
        exponent_theme_showTopSectionalModule(...), 
        expTheme::showTopSectionalModule(...), 
        exponent_theme_showModule(...),
        expTheme::showModule(...),
        expTheme::showSectionalController(...),
        and expTheme::showController(...)
        • A big difference between the expTheme::module(...) call and the others (except the last two) is that it is called with a single parameter of an associative array of named parameters, whereas the deprecated ones were called with simple (sequential) parameters.
        • Likewise most of these various calls were to either deal with a 1.0 module or 2.0 controller, or to hard-code a module with a specific 'scope' (global, sectional, or top-sectional), which is now simply a 'scope' named parameter with 'global' being the default.  The expTheme::module(...) call is 'smart' in being able to to it all!
        • Deprecated call - expTheme::showModule($module,$view,$title,$source,$pickable,$section,$hide_menu,$params);
        • 2.0 call - expTheme::module(array("controller"=>"navigation","action"=>"showall","view"=>"showall_mega","source"=>"mega","chrome"=>true));
  • Old School (1.0) modules no longer exist
    • Another fairly easy thing to spot and correct are hard-coding an old school module within the main or subtheme template.  In many cases, these old school modules have been disappearing and references to them as hard-coded modules may have already been exposed.  However some were replaced with like named 2.0 modules (controllers)
    • A big difference between the old and 2.0 modules is old school modules only required a 'view' parameter, whereas the 2.0 modules require an 'action' parameter (with the default view implied).  The old school default (view) was 'Default' whereas the 2.0 module default action is 'showall' and the default view is also 'showall'. Therefore to locate old school modules, they were typically called using a 'module' parameter instead of 'controller' (however each are interchangeable).  Specifically, 2.0 modules need to have an action parameter, whereas the old school modules only pass a 'view' parameter (with NO action parameter).  If the old school view was something other than 'Default', please see the next area of discussion.
    • Here's a list of old school modules and their 2.0 counterparts:
      • simplepollmodule or simplepoll => simplePoll
      • navigationmodule or navigation => navigation
      • calendarmodule or calendar => events
      • formmodule or form => forms
      • containermodule or container => container (this has changed to simply 'container' in release candidate 1)
      • headlineController or headline => text (this is a 2.0 controller which has been deprecated)
    • Here's an example of an update required since most themes include a hard-coded container
      • Deprecated call - expTheme::module(array("module"=>"container","view"=>"Default","source"=>"@left"));
      • 2.0 call - expTheme::module(array("controller"=>"container","action"=>"showall","view"=>"showall","source"=>"@left"));
    • ​​If you've kept up to date through v2.1.1, the only NEW upgrade involves the 'container' module.  
    • The deprecated call may continue to work, but is unsupported.  If it fails to work because this is a module name change, your custom themes will not seem to work (will say that containermodule is unavailable) until it is corrected.
  • Old School Module Custom Views must be updated to work with their 2.0 module counterpart
    • The most complex of the changes will likely be required for any old school module custom views.  These would be found in the //themes/mytheme/modules/ folder using any of the above full module named folders.  In many cases, the custom view could be upgraded by a couple of simple renames.
      • Rename the 'module' folder into its 2.0 counterpart...e.g., 'navigationmodule' into 'navigation'
      • Within the newly renamed folder, enter the 'views' folder and create a new folder with the name of the module, such as 'navigation'
      • Move all the other files (.tpl files) within that 'views' folder into that newly created folder
      • Enter the folder with the moved templates, then rename the view template(s) into a 2.0 suitable name which includes the action:
        • 'Default.tpl' would become 'showall.tpl'
        • 'YUI Top Nav.tpl' would become 'showall_YUI Top Nav.tpl'
    • Any configuration or form files (.config or .form) would need more complex editing.
      • .config files are no longer used as these details must now be handled within the controller itself
      • .form files are now templates within the 'configure' subfolder of the views folder.  They are named by the associated view name with a .config suffix.  The files are now formatted just like a view instead of using the shorthand notation to create controls.  You should look at a system module like 'events' or 'blog' to get an idea of how view specific configurations work.
  • (Updated) Some YUI constants and file names/locations have been deprecated
    • Both of these issues tend to be revealed as improper formatting such as misaligned columns or font styles.
    • The 'Reset' stylesheet names have been deprecated for quite some time (apparently) and were finally removed in YUI v3.10.0.  Since many of the older themes use YUI reset(s) instead of the new 'normalize' standard, here's the changes you'll need to look for and make in the expTheme::head() call at the top of your theme templates (and subthemes) (note the additional 'css' at the beginning of the filename!)
      • cssreset/reset-min.css has become cssreset/cssreset-min.css
      • cssreset/fonts-min.css has become cssfonts/cssfonts-min.css
      • cssreset/grids-min.css has become cssgrids/cssgrids-min.css
    • We have finally removed the deprecated YUI path constants for consistency with other path constants.  These were typically used to load scripts or stylesheets in the theme templates (also subthemes) and custom views)
      • JS_FULL is now JS_URL
      • JS_PATH is now JS_RELATIVE
      • YUI3_PATH is now YUI3_RELATIVE
      • YUI2_PATH is now YUI2_RELATIVE

Other articles of interest:

v2.2.0...Is it worth the upgrade?

Since v2.2.0 is classified a 'major update' to Exponent, you may be hesitant to consider upgrading your sites.  Although in reality it is simply the next incremental version update, it does mark a milestone in the maturity of the Exponent 2.0 code.  Here are some immediate and long term benefits to updating to version 2.2.0 once the stable version is released in the near future:

  1. As always, a new version means many issues (bugs) have been fixed, and many new features will have been added.
    • For example, as web browser versions are updated more often than ever, an Exponent web site will now offer features to take advantage of new browsers and devices (e.g., html5 forms)
    • There is also a new html5 media player which will work on non-Flash enabled devices, unlike the Flowplayer module.
    • We've also put a lot of work into getting the e-Commerce module(s) working out-of-the-box, including a new sample store database which can be included during installation.  We've especially polished the event registration and donations modules.
    • There are also some new views for the blog module which now offers optional category support.  Additionally, there is a new sample blog database available during installation which automatically creates a new wp-like site.
  2. Once you've gotten your custom theme over the 'v2.2.0 hump,' there shouldn't be any custom theme changes required for future updates since we'll have finally eliminated all of the old 1.0 code.
    • Since the initial release of v2.0.0, a couple version updates have required custom themes be updated to continue working.  This was primarily due to the deprecation and replacement of old 1.0 code or modules needed for that original release.  Therefore, since all the old 1.0 code has been removed in the v2.2.0 release, we don't anticipate any major format changes which would require a custom theme update to work with future releases.

We anticipate releasing a stable v2.2.0 by the end of May 2013.