Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Jan 20 2014
Jan 20

As many of you know, CSS and JavaScript aggregation is one of the easiest ways in all known methods to increase performance of any Drupal site for end-users, yet many have not taken this into consideration. Aggregation is provided in Drupal and works magically out-of-the-box, so no need to worry. This would be true under normal circumstances, but as the site grows more complex and more modules are added, you may find that the site is not loading any faster than if you had aggregation turned off. Well, allow me to welcome you to the Dark Side of Aggregation!

Concept 1: “One large file is better than many small files.”

Under normal circumstances, Concept 1 holds true because making a call to download one large file is much more efficient than calling the server many times to get smaller files. CSS and JavaScript aggregation is based on this concept, but there are exceptions. Aggregation would fail when files are constantly changing – if one line of code differs from the original, all files will need to be re-aggregated and downloaded again. What a waste of resource and bandwidth, right?

Drupal 7 addressed this shortcoming with a new strategy; aggregates are separated into three distinct function groups:


And files are aggregated in the order described, introducing another concept:

Concept 2: “Sometimes a few smaller files are better than one large file”

Let me explain why Drupal decided to handle aggregation in this manner. The order in which files are loaded into the browser is very important – dependencies would cause problems – especially with JavaScript since it can be added at the top of the page or at the bottom. Also, modules and themes can conditionally add JavaScript and CSS into the page, which would definitely defeat the purpose of aggregation.

In order to maintain the desired effects we can group files that remain unchanged throughout the site into one. Those that require strict ordering need to be put into another file; files that change often may or may not require you to aggregate them. This allows us to sort out dependencies and save resources and bandwidth on dynamically added scripts. After all, we would have to aggregate the files again if one line of code changed.

As outlined in the API documentation, JavaScript aggregates are generated in this order (CSS follows similar pattern):

  • First by scope, with 'header' first, 'footer' last, and any other scopes provided by a custom theme coming in between, as determined by the theme.
  • Then by group. Then by the 'every_page' flag, with TRUE coming before FALSE.
  • Then by weight.
  • Then by the order in which the JavaScript was added. From Drupal: "For example, all else being the same, JavaScript added by a call to drupal_add_js() that happened later in the page request gets added to the page after one for which drupal_add_js() happened earlier in the page request."

The take-away:

For site admins:

  • If you are managing a small to medium size site, default aggregation settings from modules and themes would do just fine. As CSS files are the main ones on the page, we can safely assume that there aren't many JavaScript files on the page.
  • If you are managing a large site with over hundred modules there is a very high chance that there are a lot of JavaScript files. In this case we would need to take aggregation into consideration. You might need to use hook_js_alter() and hook_css_alter() to make aggregation effective.

For module and theme developers:

  • Be aware that the JavaScript and CSS might not play well with others when aggregated.
  • JavaScript dependencies need to be sorted first with the appropriate flags set so that order is respected. For example, if you are adding a library then use JS_LIBRARY flag in the options array of drupal_add_js().
  • Conditionally added scripts should not be aggregated, unless the scripts might appear in various places.
  • Files added in the .info file via css[] and script[] arrays appears on every page.
  • One thing to note is Drupal.settings JavaScript object never gets aggregated.
Dec 12 2013
Dec 12

It’s official! Our module for osCaddie Drupal Alfresco Integration is officially open to the public! You can now download the Development version directly from Drupal.org. In case you wonder what is osCaddie Drupal Alfresco Integration (or osCaddie for short), and what does osCaddie do? I’ve provided a snippet from the project description…

“osCaddie Drupal Alfresco is an integrated solution providing seamless communication between Drupal and Alfresco. Contents are synced with Alfresco whenever there is an update to content in Drupal, Alfresco will be updated. New content is created on Alfresco as soon as it is created on Drupal.”

For the site administrators and/or content managers, this means that Alfresco can act as a centralized repository for all content. Drupal, thus, can serve as the entry point for content creation (since Drupal has a much more user-friendly interface for creating content than Alfresco) and for display. One of the best features of osCaddie is that it can connect multiple Drupal sites from different physical locations into a single Alfresco server.

In order to sync content from Drupal to Alfresco, it must converts the underlying data structure of Drupal into Alfresco. Having that in mind, osCaddie is designed to allow…

“… content-type mapping with Drupal and Alfresco, meaning a non-standard content-type (such as additional textfields, radio buttos, or checkboxes) can be used on Alfresco.”  

The module allows any number of standard CCK fields such as text, textarea, select list, checkboxes, radio buttons, and date fields to be mapped into Alfresco with help from the osCaddie administrative interface to ease the mapping process. One of the marvels of osCaddie is that content-types can be synced back and forth between Drupal and Alfresco. You can create a content-type in Drupal, sync it into Alfresco, delete the content-type in Drupal, and have it restored from Alfresco. In fact, if more than one Drupal instances are connected with Alfresco and each has its own set of content-types, you can sync content-types across them all. This is truly a Special Feature unique to osCaddie!

The solution consists of a set of modules that are standalone and can be deployed to any new or existing Drupal instance. osCaddie Alfresco portion of the solution is compatible with Alfresco 3 and 4 community and enterprise. However, the current of version osCaddie Drupal is only available for Drupal 6. A version for Drupal 7 will be available in the near future.

Visit the osCaddie project on Drupal.org: https://drupal.org/project/osCaddie

May 02 2013
May 02

Thank you for attending my webinar - Building Rich Internet Apps with Drupal & HTML5. I really appreciate the support and the amount of interest in this topic that you guys have shown! This blog post is dedicated to answering the questions that were asked during the webinar; unfortunately I couldn't get to all the questions but please feel free to leave any more in the comments and perhaps there will be a Part 2 of this Q&A.

Building Rich Internet Apps with Drupal & HTML5

Learn the power of combining Drupal + HTML5 + CSS3 + JS

Q1: What type of applications would you recommend to develop using these technologies together?

Applications like the one I’ve shown in the demo are the perfect example. And for good reason, I have shown a reader app, not because I want to promote Kobo, but to demonstrate the effectiveness of HTML5, CSS3, and JavaScript (which is what Sproutcore is about) in creating a web-app. A reader app ties in with the concept of Hybrid Model perfectly. The Kobo server not only serves data for this HTML5 Reader app but for their native iOS, and Android app, which follows our model – the server-side is separated from the client-side.

Facebook apps are good candidates to use these technologies. Facebook gives you a Canvas to work with, which essentially loads your website into an iframe, however, performance is not that great when working with traditional-style websites. For every page request, Facebook has to load the webpage first, and then show it to the user. Facebook is acting as a middle-man. So if you can eliminate the need for Facebook to fetch pages then your app will perform so much better.

In a nutshell, if you foresee that your application is going to have a content repository with workflows and needs to be highly interactive then a JavaScript HTML5 UI coupled with Drupal is best choice.

Q2: How could we introduce and streamline this hybrid model into a development environment?

As mentioned before the Hybrid Model demands a deeper consideration in deciding on how to separate business logics or requirements for client-side and server-side. It‘s architecture that is not too well adopted for websites, but for web applications it’s second nature. To start off, Business Analyst will need to gather as many requirements as possible so that the Solution Architect or Lead Developer can draw the line between what business requirements can be accomplished on client-side and what on server-side. Once that is established, we should focus our attention to designing the JSON REST API. Front-end and Back-end developers must agree upon the API before any work can begin. In this case, both front-end and back-end can work in parallel.

Q3: What do we do with the themes and templates on Drupal and is the UI going to be on the same server or somewhere else?

Since external users are not interacting with Drupal directly, we don’t need Drupal to do any themes and templates. Now our JavaScript HTML5 UI is external to Drupal, meaning it is not a Drupal theme. We may view the UI as a standalone app that talks to Drupal. So the UI doesn’t need to be living on the same server, in fact, performance-wise, the UI would ideally be hosted somewhere like on a CDN (Content Delivery Network). However, it can be on the same server with Drupal just not within the Drupal directory.

Q4: Can you please define assets briefly?

In our context, “assets” refer to anything that enriches the UI, or adds “life” to it. These are, but not limited to: images, video and audio files, Flash (SWF) objects, CSS, and JavaScripts.

Q5: This might get answered later on... but I thought one of the great strengths of Drupal was its theming! If Drupal becomes SaaS, where is the theming motor going to come from?

I agree that one of the great strengths of Drupal, besides content managing, is the theming/template engine. When we drop that part from Drupal and attach our external UI crafted from the HTML5 and JavaScript, the template motor is coming from the JavaScript framework that we are using. I highly recommend using a strong framework such as Backbone.JS, Sproutcore, or Ext JS. For the theme, you may want to combine the templates with a CSS framework like Compass and/or Foundation 4.

Q6: It seems like "thickening" the client is a good choice for sites that are frequently used. What are some best practices for sites that may be visited infrequently and aren't likely to create app interest in users/viewers?

As you’ve termed it “thickening” the client is good for sites that are frequently used, but that’s not all. Websites that want to respond well to users, say, the user clicks a button or a menu pops up or the page would flip and content is already there, and with no wait time between the interactions, thickening the client is a reasonable thing to do.

Now for sites that are infrequently visited, the best practices for deciding whether or not to go the web-app route:

  1. If your current websites are mainly displaying static content, don’t require a lot of user interaction and it’s fine to have users waiting for page load, then stick with traditional websites.
  2. Benchmark your website; find out what is your general audience. Some users have no problem with plain-old websites, but some users love fancy and quick-n-snappy UI in websites.
  3. If you foresee or plan for your current website to have increased functionalities and it’s going to become like an application, this is the great opportunity to “thicken” the client.


Q7: What happened to "don't store state" in the browser? Is this old-fashioned advice that's not needed anymore?

The statement, “don’t store state” in the browser, is typically referring to the stateless model that the World Wide Web and the HTTP protocol is based upon. Because state is not preserved in the underlying protocol, it would make sense to not have the browser remember the state. Now that we are moving toward web-apps and HTML5 is meant to accelerate the process, stateless design is becoming outdated. If you look closely at the HTML5 features list, we have Local Storage, WebSQL, IndexedDB, and Application Cache, these essentially break the stateless design pattern. Now, let’s take a step back and look at how we implement a website before HTML5, we use cookies/sessions and URL to allow the browser to be state-full. In a sense, we’ve already broken the stateless design pattern. One thing to remember is that the HTTP protocol is always stateless, so we are always communicating in a stateless world. What we’ve done is altered how the app behaves but not the communication.

Q8: Drupal seems to be using Backbone.JS how does this compare with Sproutcore?

In a nutshell, Sproutcore and Backbone work in the same way. Sproutcore is heavily on the client-side MVC structure while Backbone is a bit more relaxed. Backbone is super light weight in comparison to Sproutcore. One reason that Sproutcore is more suited for web-app is the Statechart feature which only not organizes views but also drives the application. Statecharts can be seen as the Finite State Machine in Computer Science. Backbone.JS and Underscore.JS are being added to core because they need to provide the foundation for the inline editing feature in the coming release of Drupal 8, and because Drupal 8 is headed toward SaaS, Backbone.JS would really benefit Drupal.

Q9: Is there a recommended IDE for Sproutcore?

Any IDE that can keep track of JavaScript functions and files is great. Sublime Text 2 is a good choice because you will run into cases where you must search through files to look for function names. I personally use Komodo just because I do PHP and JavaScript.

Q10: How much PHP programming is involved in your Hybrid Solution based on Drupal? Can you implement serverside business logic in JavaScript? Can Sproutcore be used server-side?

PHP programming would be the same amount as it is when creating your own modules. It really depends on the business logics you planned to implement on the server. However, if all the business logics can be achieved with contributed modules, then no code writing is needed.

Implementing server-side business logic in JavaScript is not a good idea because of security issues. Keep in mind that JavaScript is not safe; anyone can download the script and look at it. So it is not wise to implement server-side logic there. So in the Hybrid Model, I advised that the client-side only implement that logic which is closely related to display, for that reason.

Can Sproutcore be used on server-side? No. Sproutcore is for the client, if you want server-side JS, use Node.JS instead.

Q11: How can you access the MySQL DB in Drupal? Do you need PHP to do so or can JavaScript on the server be used for this?

Drupal database abstraction layer provides the API to read/write to the MySQL DB. Your JavaScript client will call to the JSON REST services Drupal provides to get data, and Drupal using the DB abstraction layer will handle getting data from the DB.

Q12: What is the preferred IDE for PHP/Drupal?

I use Komodo personally.

Q13: Using the hybrid model, how does one configure the Drupal appearance / theme aspects? What are the ways in which I have to tailor Drupal so that it acts as a content repository and not a UI driver?

In the Hybrid Model, we have dropped the appearance/theme portion in Drupal for external users, meaning visitors will interact with the JavaScript HTML5 UI instead, and only administers would log into Drupal directly. Essentially, if you do a fresh install of Drupal it is already a content repository. The remaining piece is to provide a JSON REST API for the UI to connect to Drupal. Say, we have 'example.com/' pointing to your UI, and 'admin.example.com/' is your Drupal instance, you can create a landing page to allow Admin to login.

Q14: What type of app is good for HTML5 only?

This is a very open-ended question as any app can benefit from HTML5. There's not really an app that is only good for HTML5. So if your app utilized at least 2 or 3 HTML5 components then it is a good app for HTML5. Games, for example, use the Canvas component and WebGL (on Chrome) to render graphics. Reader applications, like Kobo, use Local Storage, Application Cache, History, and IndexedDB.

Q15: Do I have to develop the web-app from start to finish in Drupal to be able to use all of the Drupal features or can I just incorporate it into my existing website?

Honestly, it is best to design the web-app from start to finish in Drupal and in JavaScript UI, because it’s much better to layout where client-side and server-side business logic would belong in the beginning. But you can start anywhere in between, all you have to do is build that JSON API and make sure that API hooks into all the Drupal features you need, so when the UI calls, everything is there.

Q16: Also, Is it a must to use PHP MVC or framework to be able to use it?

No, the Hybrid Model is really an architectural layout to structure your application. You don’t need to limit yourself to MVC frameworks on server-side and client-side. In fact, Drupal is not a MVC framework, it is still a PAC, and yet I recommend using Drupal for server-side.

Q17: If a web-app/website has some interactive content as well as some more static content, can Drupal serve up static pages while the client-side JS serves up dynamic content? (a hybrid-hybrid model?)

Yes. You can do that, as long as you have set aside which URL points to the web-app and Drupal, they can work simultaneously. For example, Drupal site only serves static node pages, and all your Views are outputting JSON instead. Calling those Views will split out JSON and not the actual page.

Q18: It looks like SproutCore uses Ruby and RubyGems somehow - can you please explain how that fits with JavaScript?

Sproutcore is JavaScript. Sproutcore uses Ruby and RubyGems to build and compile your JavaScripts into an app package.

Q19: How would you benefit from Drupal-HTML5-CSS3-JS vs.Node.JS-HTML5-CSS3-JS? i.e. What is the benefit of doing server side Drupal versus 100% JS using Node.JS?

Drupal gives you the benefits of having a CMS, and Node.JS doesn’t. It only gives you the structure to build an application. The question is why build a CMS yourself when you already have it, and all you really need to do is add the JSON REST API component. There is no real benefit in the underlying technology, in terms of, mixture of PHP with JS and pure 100% JS. Even if you implement 100% JS on both sides, you still need to build REST component for the client and server to communicate.

Thanks for reading along; I hope this Q&A has proved helpful! 

Jul 17 2012
Jul 17

Hello, Shadow is here!

Posted on: Tuesday, July 17th 2012 by Richard Mo

Have you ever felt that doing front-end web development for mobile web devices (i.e. Android, iOS) is a real pain, especially when you can’t do any inspections quickly? Designers or Themers would totally agree with me on this. Web developers, in general, would feel the same way but not as much as designers/themers do. And how about QA in general – manually pressing links or refreshing pages? It’s a lengthy process… Now, may I suggest to you that it is possible to shadow your actions across multiple devices?

I’ve recently been introduced to Adobe Shadow which addresses all the pain I mentioned earlier. A quote from Adobe Labs:

“Adobe® Shadow is a new inspection and preview tool that allows front-end web developers and designers to work faster and more efficiently by streamlining the preview process, making it easier to customize websites for mobile devices.”

Basically, it allows you to sync all URL changes to every shadowed device and inspect HTML and CSS on each and every one of them.

Here are some features Adobe® Shadow provides:

  • Synchronized Browsing and Refreshing (Device Pairing) — Wirelessly pair multiple iOS and Android devices to your computer.
  • Remote Inspection —Target a device for remote inspection and using familiar development tools, make changes to your HTML, CSS and JavaScript and see your device update instantly.
  • URL Monitoring — Shadow monitors the Address Bar in Chrome, and sends updates to Shadow devices as they happen.

Setting the system up isn’t hard at all; there are, however, 3 things you must download to get things up and running:

  1. You need to download the Adobe® Shadow service which installs onto your desktop. It acts as a server then communicates with all your devices.
  2. Download and install the Chrome browser extension which you would use to control your Shadow devices.
  3. Finally, each device (Android or iOS) must install their respective Shadow app.

Combining all 3 pieces of the puzzle, hook them up, and there you go!

Adobe® Shadow is excellent for traditional websites, where every page is uniquely named (i.e. each page has a unique URL), because Shadow devices follow URL paths sent by the host and interact with the native browser. Most AJAX elements on the page, however, will not be compatible with Shadow for that reason. Web applications built purely using JavaScript, Sproutcore per se, will not work.

Then, what would Adobe® Shadow be used for? Drupal! Shadow is excellent for Drupal front-end development! It really speeds things up for designers and themers. The built-in HTML CSS inspector will let you see what’s going on with each device and you can take screenshots for all of them at once!

For further information, please visit Adobe Shadow.

Apr 26 2012
Apr 26

Sneak Peek of Drupal Camp Vancouver 2012: Drupal+Sproutcore

Posted on: Thursday, April 26th 2012 by Richard Mo

This year’s Drupal Camp is coming to Vancouver on June 2!
I'm hoping to be giving a talk on an interesting topic that inspires new ideas and sets a new paradigm to web development and UI designs. Proposal was submitted, now just waiting for approval. Indeed, it's an exciting opportunity. Here is a snippet to the opening:

“Drupal and Sproutcore is a power couple; bridging the gaps between data management and interactive UI, thus delivering the users a full Rich Internet Application (RIA). The days where web applications only live on servers are gone, and the days when web applications needed additional browser extensions are gone too.”

It is very true that with the power of Drupal and Sproutcore, we can easily develop web applications with very similar, or should I say, almost behaves like a traditional Desktop application! So what does this entail? Short answer is – we can integrate a higher degree of interactive designs into our application, while maintaining a strong data management component and excellent application-wide performance. And the long answer? Well, I’m going to save this for Drupal Camp Vancouver! Stay tuned...

If you are interested in the topic, please come join me at Drupal Camp!

For more information about the Talk and Drupal Camp Vancouver, you can visit Drupal Camp Vancouver.

Dec 08 2011
Dec 08

Drupal 7’s Fields API – Initial Perspective

Posted on: Thursday, December 8th 2011 by Richard Mo

I’m sure that there's a lot of blogs, tutorials, and presentations out in the public already, which educate us about the Fields API. I’m not going to write “another blog post” about that. Instead, I'm going to share my initial impression as well as what I’ve discovered helpful to people who are new to the API.

Fields creation for content-types behaves exactly the same as CCK module of Drupal 6: selection of fields that can be attached, widget types that can be used with a field, and configuration of fields. The UI, in particular, looks almost identical to CCK module. So, a lot of the basic field types from the CCK module are part of core Drupal 7, however, like I said, it’s only the basic, if I want to have a more complex setup, I must default to something more appropriate…

From experience, CCK API is not easy to work with. If you want to create a set of textfield and textarea, group them as a whole, and allows for multiple sets. CCK can give you a headache. I’m actually quite impressed of how Fields API greatly simplifies the creation process. Although the learning curve is quite steep, yet once you learned where things are its quite easy. (As a side note, the API documentation on Drupal.org is not beginner-friendly.) So to help out our fellow Drupal 7 developers, there are five things you must implement in order for a field to work:

  1. hook_field_info()
  2. hook_field_is_empty()
  3. hook_field_widget_info()
  4. hook_field_widget_form()
  5. hook_field_schema()

The hook_field_validate(), hook_field_formatter_info(), and hook_field_formatter_view() is not required for the field to work.

Sep 02 2011
Sep 02

Project deployment using Features

Posted on: Friday, September 2nd 2011 by Richard Mo

The contributed module, Features, has been out in the community for a while, and has been a tremendous help for deployment. It saves time and energy when moving from Development, Staging, then Production. Configurations become a 'one-click' solution, so to speak.

However, careful planning needs to be incorporated when creating packages with Features. Sometimes two Features can be in conflict with each other when both packages are using the same element - this is especially true for CCK fields. Features doesn't offer the easiest way to move elements within a package to another. For example, if Package A stores a content-type that has CCK fields and Imagecache presets, then to move it, any dependencies must be released manually. Here are a few tips, that I use, to ensure a smoother process for development and deployment:

  1. Whenever possible, group all related content-types, views, pages, etc. into a single package. Better yet, modulate functionalities or features into an atomic unit, so it is isolated and encapsulated.
  2. Try to minimize the amount of sharing of existing CCK fields among other content-types. Content-types within the same atomic grouping can share the CCK fields.
  3. Plan ahead the exact architecture of the site. Most important step!

Jul 21 2011
Jul 21

I have something really, really cool I wanted to share, and I'm sure you won't be disappointed. In scenarios where displays of graphs/charts are needed, either a client wanted to showcase some statistics to their users, or an administrator wanted a summary of activities of what is currently going on within the site. If the graphs/charts are simple, you can just use the Google Charts API, but for something more advanced or simply for the "looks", Google Charts doesn't do a good job. While coding these manually using pure Javascript and jQuery is possible, it is a nightmare to do so...

read more

Jun 08 2011
Jun 08

Installing Drupal 6 on a Windows machine using Internet Information Services 7 (IIS 7) is, in fact, quite simple. All you need is to have FastCGI extension installed and enabled on IIS, and PHP and MySQL installed. Note, in order for Drupal to work correctly with IIS 7, updating the FastCGI module on IIS 7 is a must.

read more

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web