More About Less
Back 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.