I'm looking to see if anyone has any resources or tips for developing basic Drupal modules faster? Have you come up with anything to make your Module development faster?
The Drupal module documentation is kinda hard to understand and pretty massive. I'm wondering if anyone has simplified it and given techniques/tips for getting specific things done quickly. I'm currently looking for Drupal 6 and 7. Any help saving time will be greatly appreciated :-)
In general, I'd recommend picking up a copy of the Productive Programmer. There's nothing earth shattering in it, but there are lots of small tips that can increase your productivity incrementally.
For Drupal specifically, Pro Drupal Development and Pro Drupal 7 Development, though not focused strictly on speed of development, are indispensable.
Beyond that...
in the first place, if you don't have to, Don't Write Code
get familiar with the most commonly used hooks
learn to use Drush and Drush Make
learn to use Devel and Theme Developer modules
use the Schema module to generate your module's schema code, based on an existing table
use the Data module (+ this patch) to generate the code to expose your module's tables to Views
use the Form Builder module to generate form code
use Coder to learn the Drupal coding standards, which will help others help you
set up "quick searches" to allow you to quickly search api.drupal.org
learn the shortcuts in your IDE or text editor (I like Netbeans partially because of the Drupal plugin); print out a good cheatsheet
learn to use version control effectively
Well, there really no fast track to it. If you understand the Drupal API regarding module development (install, menus, blocks, forms, etc) you will grasp it. The hardest part I remember was wrapping my head around the menu system.
One thing that helped was taking simple modules and seeing how they worked, and problem solving my own solutions. Reading Pro Drupal Development helps too.
You basically need to have an understanding where to look (API function, hook, system... ) when you want to do X. There is really no need to memorize all hooks/functions in detail with all the arguments and stuff. That's something you can easily look up. Especially if you're using an IDE with I suggest (Using Netbeans myself).
Especially when you're altering stuff, try to develop some techniques to quickly figure out what code is responsible for the stuff you want to change. One example is to look at the hook_menu() definition of the module that does it and then check out the page callback and skim through the code. Things to look up: Are there hooks you can use, is it a form (if yes, what is the form_id, how is the form structured) and so on.
The best and maybe only way to get there (knowing where too look) is exercise. Every time you do something, you'll be faster the next time when you have to do something similar. I think what also helps is working on core/contrib modules together with others. You not only get to learn these modules better, you also learn how to read and understand code written by others better and you improve your own coding style.
Try to utilize proven, generic "building block" modules like Views, Flags, Panels, CCK/Field and so on. Then, the heavy lifting is done by these modules and you only need to provide the glue code to properly integrate them with your site. Might take a bit more time the first time you use these modules but you will likely save a lot time after that.
That having said, I'm not sure if the goal should be to build modules fast. I'd say the goal is to build modules better. Try to make them generic, secure, flexible, theme-able and so on with the goal to re-use these modules on the next site your building, when you need something similar.
The majority of basic drupal module development is copy and paste. If you use textmate, the Drupal bundle for it allows you to build up key bits of modules (menus, theming functions etc) just by point and click (as it contains most of the necessary code snippets; you just fill in your info).
Following the module building tutorials is good too; the truth is, if you spent 3 or 4 weeks doing it day in day out, and you already have some background in coding, you'll be just fine.
Gedit for Drupal will preconfigure the very good Gedit editor/IDE for you.
For example, a new module: create an empty module file mymodule.example. Enter that file.
module<tab> And it expands into a full, predefined module.
Or in any module: hook<tab> to see a list of available hooks. Choose e.g. menu<tab> and it expands to a full predefined hook_menu. With <tab> you can walk trough all the variable parts in that new hook, to fill in the details.
Drupal.rb Has a.o. a $ drupal generate module "modulename" command that opens an interactive shell, wich allows building scaffolds for modules. The templates from which these scaffolds are built, are overridable.
Related
I'm migrating a site from a proprietary cms (reddot) to drupal. For all its flaws, reddot has a very simple yet flexible model:
templates consist of markup with placeholders for variable content
every piece of content, from a full page, to a shared piece of sidebar content, and even a single image can be built from a template, if an appropriate one exists
My first impression of drupal is: woah, this is complicated! Rather than three simple objects, now i'm dealing with nodes, pages, blocks, regions, views, panels, etc. What is the simplest way to recreate the template/content/placeholder model that i'm familiar with?
Reddot uses a rather well architectured MVC-alike system. In addition, from my limited experience, Reddot follows the there is only one way to achieve Foo-philosophy.
Coming to Drupal, especially as a frontend-developer you will be dissapointed, lose a lot of hair and probably curse a few times when you realise everything has to be done all over again.
Coming to Drupal you will love the gigantic amount of (unfortunately unorganised) documenation and its flexibility and enormous amount of new posibilities.
When people come from properly architectured systems into Drupal, I advice them to do one thing: become pragmatism-exstremists. Don't (ever) try to make things proper, clean or well-thought out. You will only be able to do that once you truly grok Drupal. And that only comes with a lot of experience. Just fiddle untill it works, close the code and never look at it again.
First thing you will need to learn, is Drupals PHPTemplate engine, which is rather different from Reddots, but has a lot of similarities. Where Reddot uses RenderTags, Drupals PHPTemplate uses plain old PHP.
<%!! Context:CurrentPage.Template.Name !!%>
becomes
<?php print $name ?>
And yes, $name is entirely globally scoped. Remember? I told you to be a pragmatism-extremist. Don't even think about namespacing, object scoping and such.
Want to know what variables you have available? Just do a <?php print get_defined_vars() ?>.
Want new variables in your template? You need to preprocess them.
Want to change, alter, strip or modify existing variables? You either need to preprocess, or template override or even write new modules that make new or different variables available?
Knowing which to choose, when to preprocess, when to create modules, when to override, when to implement hooks to alter stuff is experience.
Drupal has never thought that out clearly, there is no general rule or best practice, other then the last eleven times that Foo-concept did not work out, maybe Bar proves the best.
Drupal's templates are similar to what you describe of reddot, but there are probably more options and they can be nested. To get a good sense of how the templates work together download the Theme Developer module and watch the associated screencast.
To get a sense of the "placeholders" you can use in a given template, visit the api.drupal.org page for the template file or check out this Drupal 6 Theming Cheat Sheet.
Another one bites the dust.. ;)
Let me know how you go with the migration Bobby Jack.
I think for the content you might be able to create an XML variant in the CMS and export everything to re-import it to Drupal..
On the Drupal note: Once you get your head around the concept of templates being able to inherit/being overwritten it's easy.
It's like a set of pre-assigned content classes in RedDot which can change to render them in a different layout. Similar to the "replace content-class" functionality.
I've been coding in PHP for 4 years and even I find it so convoluted and hard to grasp. I have no idea how they expect designers to manage theming.
I know basic theming, theming with tpl files, views templates, contemplate templates etc. However I get lost whenever I enter the template.php file.
I needed to theme a node input form for a custom content type. I wracked my brain over it with like 7-9 tutorials and it's still not coming together. I understand why module building can be complicated - because most people who work with modules are developers anyway.
However, when even a developer can't understand theming, it's definitely over-engineered!
Maybe it's my fault, maybe I didn't learn Drupal properly. In that case, is there a step-by-step system to becoming a Drupal guru?
Theme is really not that difficult, if you only know basic php. You have 3 ways of altering the markup, the css and js, you should be able to handle.
Template files. By creating a template file in your theming and naming it correctly, it will take precedence over other template files, and you can thus create custom markup for views, nodes etc. By creating a template for a noce type, you can do stuff like printing out the cck fields in any other instead of using $content. All you need is on the node object.
Preprocess functions, which are placed in your theme, will give you the possibility to add or alter variables that will be used in your template. You name the functions like hooks: yourtheme_page for the page template yourtheme_node for the node template etc. Here you can create some custom logic, or modifications, to help make your templates more clean and just handle the printing of the variables.
Theme functions. You can overwrite theme functions to alter the markup that's used. You only need to create a function called yourtheme_[theme_function_name]. You don't need to understand much php to do this. Often, you can just copy the original theme function, and make a few alterations in it to get the markup you want.
With the above you can do 90-95% of what you need. Forms are a bit special since you in Drupal 6 can't alter them (easily) in your theme. Instead what you want is to create a small module and use hook_form_alter, which allows you to modify the form, text used on buttons etc. This is changed in Drupal 7, which will be even easier to theme.
So it really isn't all that complicated, just use the 3 basic tools described above. The tricky part can be to name your functions and templates, but devel themer can help you with that. Another tool you use is devel which can assist you in printing out variables so you can inspect them and see what you have available, fx CCK fields on the node.
Maybe you should get a copy of Front End Drupal.
In my opinion, Drupal theming is not difficult once you wrap your head around the concepts like templates, overrides, .info files and preprocess functions. Those things are not directly related to php skills, it's all about understanding the system.
It's interesting to see that you're a themer, yet you only talk about php, not CSS and HTML. In my experience, a lot of theming tasks can be accomplished with CSS, without even touching php.
Finally, I don't know if you are using a base/starter theme (like Zen or Genesis) already. I recommend using a base theme and realizing your own design as a sub theme.
Most people get an 'ahah!' moment when themeing suddenly starts to make sense.
I'd argue that this is probably tougher for experienced PHP developers, since you have to get past a lot of concepts that don't make sense in vanilla PHP ("the function is magically called at the appropriate time ... because of how it's named?!")
#googletorp's answers is pretty comprehensive, so I'll just add some practical tips that helped me along:
1) Try building a module that implements it's own themeable output and simple hooks. Hooks and theme functions make a lot more sense when you see how modules are actually calling them and using them.
2) Make liberal use of the devel module, especially the Theme Registry menu (note how it changes when you add a new theme function), the 'Render' tab, and the dpm() and dvm() functions
3) Buy a old-tyme dead-tree book on Drupal themeing. The online docs are really outstanding if you already know what you're doing, but can be extremely confusing if you're not sure what you're looking for.
4) Empty your cup. At the theme level, PHP is really just for simple logic and syntax -- almost everything of substance is getting handled by Drupal API functions. Try to think like a Drupal developer and not a PHP developer (i.e. don't assume you know how to do something just because you built a vanilla PHP site that does the same thing) and you'll have an easier time.
Keep with it! The theme system is actually really easy to use once you've figured it out.
to answer your question on why it is so hard:
Drupal themes may seem overwhelming, due to the sheer amount of possibilities, see #googletorps answer for a good overview.
Having "many ways to do one thing" brings power: power users can choose the best of all possibilities. But it also brings complexity: new users don't get a good lead, because there is no "you should do it this way. fullstop."
Alongside that amount of ways to get stuff done, there is the problem of nesting. Drupal has a concept of very deeply nested items. To take a random, yet simple example:
username<menuitem<menuitem<menuitem<menu<block<region<page.
Will render a menu-item, containing a username in a three level deep menu-item in a sidebar-block.
Where most templating-environments have concepts of a page, containing several "contents" that, at most, might contain some partials. the nesting is at most three levels deep. And each level has a clear, distinct area of expertise. Drupal does not have that: the nesting is fairly arbitrary. And each nested item is no different from its parents. This, again, offers power-users a great concept and power to work with, but is hard to grok for new developers/designers.
Lastly, another reason why it is hard to learn, is that the Drupal online documentation is more a wiki then a read-from-begin-to-end manual. There are great books that fill htat gap, you will have to buy them, though.
If you haven't seen it already, this is a great presentation on why Drupal 6 theming is difficult and how it is improved in Drupal 7. There is hope! The video made more sense to me a second time watching after more experience theming.
http://sf2010.drupal.org/conference/sessions/design-and-theming-whats-new-drupal-7
One of the biggest tricks is to override something that is normal rendered with a theme function into a template. This gives you much more control over the markup, and also lets you use the preprocess functions to manipulate the variables before handing it over to the template.
This is a huge boon to theming forms. See a short video that explains it better than I could here: http://drupaldojo.com/session/fine-tuning-ui-theming-forms-drupal-60
For about a year and a half I used Codeigniter to build my sites. Then a client begged me to build theirs in Wordpress. I soon found the joy of using a CMS (if Wordpress can be called that). So for about the last 8 months I have been using Wordpress as much as possible to buld my sites - I made the content fit the design.
Well, I began to grow very tired of the limitations of Wordpress - I needed more control and flexibility over my sites. So, I have recently started using Drupal 7 (not 6.x - I really like the admin panel).
After working with Drupal now for a little under two months - I have begun to feel like I'm using Stone Age Tools to build Space Age equipment.
So my question is: does Drupal get any better? Do you really have to use Views to display your content? Asking for help on the forums is just a shake better than asking a wall. I feel like to do anything requires a module. Why? Is one better off sticking to a framework?
"After working with Drupal now for a little under two months - I have begun to feel like I'm using Stone Age Tools to build Space Age equipment."
Well, my intiial reaction is that this is what you're going to feel like you're doing when you're working with Drupal 7, which isn't out of alpha yet. A good number of the folks who maintain modules haven't started upgrading to 7 yet, and that means that you're missing out on one of the great features of Drupal, which is it's wide and deep space of premade modules.
Try 6.
Do you need to use views to display all content? No, not at all. You can go in, create a new module, and write the sql and presentation that you want. Or you can find a module that will display things for you. Or, depending, you might be able to get the effect you want just by adjusting the theme you're using.
(As a side note, using an admin theme really pretties up the Drupal experience. I'm fond of rootcandy, although Rubik is nice too. Problem with Rubik is that it's not on drupal.org.)
The strength of Drupal is that by using modules, you don't have to re-write code that someone else has written - you can instead take that code and modify it (with hooks) to do what you want. This means you don't have to write an authentication/autherization system again - it's there in core. You don't need to write up openid handlers - it's in core. You don't need to write code to integrate with twitter directly - there's a module that contains an api that helps out. You don't have to write an xmlrpc server from scratch - you can use the services module.
You don't need to write a website from scratch. Instead, you can start with Drupal, add most of the functionality you need, and then spend your time making it fit what your client wants.
Firstly, you can install the Admin module to pretty up Drupal 6 admin. You don't have to use 7. 7 is still in alpha, by the way. Garland sucks, but, Garland is just a theme- its not 'the' admin itself. The Drupal admin can take the form of any Drupal theme, which is useful in its own right, depending on the use-case.
In Drupal, you can create content types clicking through the interface in Drupal 6 or 7. As far as I can see in WP3, you have to script it. A few clicks vs scripting, the choice for me is not hard there. The first way is a lot more efficient, and a task you can hand off to a non coder to get done.
You don't HAVE to use Views to display content.
You -can- use Views to make the display of content easier, by telling Drupal to gather data and provide a Page, Block, or Feed to display . This lets you create specific sections of content for areas of the site. Otherwise, you would have to create a node, and hijack its template, run a direct sql query yourself AND write the pager functions just to show something easy like the latest 10 "Press Releases" content type. Then, if someone added a new field to that content type, you have to update all that SQL code and display code. Views makes your life easier in that respect. In minutes you can flesh out site sections and arrange content in a myriad of ways. In Wordpress, this method of arranging content without functionality of Views is/was a modern nightmare and a reason I do not want to use it at all unless its a blog and nothing more.
The Drupal Support Forum is tricky. Not all modules are as active as say, Views or Pathauto (being two of the most popular modules). However, SO is also at your disposal. I answer a lot of Drupal questions here. The trick to the Forum there is you have to ask it in the right spot. True, sometimes you may have to wait a few days to get an answer, then again no one -owes- you an answer for a free product. Thats the nature of open source.
Every developer has their favorite modules to use with Drupal, and more often than not, its the same 20 or so modules. It depends on what you are doing, what you are trying to implement. It's not that 'everything needs a module' its that Drupal is such a vanilla install because Drupal does not want to assume your purpose nor overwhelm with options. The UX is something they are trying to improve anyway, and popular modules are making their way into core.
Well, I began to grow very tired of
the limitations of Wordpress - I
needed more control and flexibility
over my sites. So... I have recently
started using Drupal 7
Why not go back to CI? Drupal certainly has it's strengths, but I don't think Drupal will give you any more "control and flexibility" than Wordpress.
If the standard modules/plugins, themes/templates, from WP, Drupal, or Joomla, fill your needs, then using a CMS can be a lot faster than building a site from scratch. But, if those CMSs do not fill your needs, you could find yourself "fighting the framework" and never really getting what you want.
You're just coming out from WordPress, which has great support and is relatively easy to extend to overcome what you call its limitations, if you know basic PHP, HTML, CSS & JavaScript. Every framework has its own potential/limitations.
As a user of WordPress my humble opinion is that you should have stayed with it.
As of you last question, It depends, to stick with one and only one framework has its advantages and disadvantages, the best of all is that you get to know it very well and eventually learn how to extended it. The bad part is that very often frameworks lose popularity and you are left to you own without an active user community and support.
Regards.
All of the popular CMS products (I'd maybe add Expression Engine to the mix) are great for 80% of what you want to accomplish and a huge pain to handle the other 20%.
That's just the nature of the beast.
On the plus side, it's OS so there's lots of people hacking away at it just like you which opens up the potential for someone else already having invented the wheel.
And with bulky enterprise CM solutions like SharePoint I find that you have to reverse the equation to 20/80 (ugh!).
If you're discouraged with Drupal and prefer to stick with WP, WordPress has many thousands of plugins, including ones that can overcome the limitations you're running into and make WP behave more like a normal CMS.
Just do a Google search for "top Wordpress CMS plugins." There's a lot of articles out there that can recommend ways to get WP to do exactly what you want.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I'm trying to write out a list of key Drupal competencies, mainly so I can confirm what I know, don't know and don't know I don't know. (Thanks D. Rumsfeld for that quote!)
I think some of these are really broad, for instance there's quite a difference between making a functional theme and creating a theme with good SEO, load times and so on, but I'm hoping you could assume that a half decent web developer would look after that anyway.
Just interested to see what people here feel is also important. I've edited the suggestions so far into this list.
Languages
PHP
MYSQL
Query
Drupal Skills
Research and install modules to meet project requirements
Configure the basic modules and core settings to get a site running
Drush command line tool
Create a custom Theme from scratch which validates with good HTML/CSS.
Able to customise forms, core, themes without altering core files but by using template.php or custom modules.
Can make forms from scratch using the API - with validation and posting back to the DB/email
Can create custom modules from scratch utilising core hooks and module hooks.
Be involved with the community, understand the naming conventions, CVS system and ideally have submitted some code or revisions.
Modules
It's not easy to make a must know module list, as not only is the modules you use very dependent on the site, but also how you use them. However the following are widely used:
Views
Know how to make basic views and blocks.
Know how to make more complex views with relationships and terms.
Know how to use hook_views_query_alter, to make complex queries.
Know how to use hook_views_default_views, to create specific views.
CCK
Know how to setup content - what field types to use.
Know how to create your own field_formatters - the foundation for theming CCK fields.
Hooks
The most important hooks to learn, to create a basic module are probably:
hook_form_alter() - change forms without changing code.
hook_menu()
hook_theme()
hook_nodeapi() - almost anything regarding nodes
hook_schema() - create tables
hook_install() / hook_uninstall() - create tables and clean up.
hook_perm() - when you need special access control.
hook_init() - things to want always to happen.
hook_user() - if you need to tap into user actions or modify the user object.
I good understanding of client-server architecture, how servers and browsers works. And knowledge of php and mysql, templates engines. And of course, you should also read Drupal documentations.
Able to create a custom Theme from scratch which validates with good HTML/CSS and also pays attention to usability and accessibility. (Whilst still looking kick-ass).
You usually don't want to create themes from scratch but from a starter theme like Zen instead.
For Drupal you will need:
PHP, it's a PHP framework, so to really understand and use it, you need to understand PHP.
SQL, the list of SQL serves that Drupal can use is growing, but you will need to understand * SQL, relational database and how to setup some basic architecture.
Javascript (and jQuery). Drupal uses the jQuery js library, so it will be a lot easier if you not only, know how yo use javascript, but also understand how to use jQuery and some of it concepts.
The hook system and how you can alter Drupal core and modules implementing hooks.
The naming convention for hooks, theme functions etc.
Modules
It's not easy to make a must know module list, as not only is the modules you use very dependent on the site, but also how you use them. The two top modules in Drupal is.
Views
Know how to make basic views and blocks.
Know how to make more complex views with relationships and terms.
Know how to use hook_views_query_alter, to make complex queries.
Know how to use hook_views_default_views, to create specific views.
CCK
Know how to setup content - what field types to use.
Know how to create your own field_formatters - the foundation for theming CCK fields.
Another module that I find very powerfull once mastered is Panels. It allows you to do a lot of complex and difficult things with very little and simple code. There is a lot of hooks you need to learn, and not much documentation. But once you understand Panels, you find that you time has been well spent.
Hooks
The most important hooks to learn, to create a basic module is probably:
hook_form_alter() - change forms without changing code.
hook_menu()
hook_theme()
hook_nodeapi() - almost anything regarding nodes
hook_schema() - create tables
hook_install() / hook_uninstall() - create tables and clean up.
hook_perm() - when you need special access control.
hook_init() - things to want always to happen.
hook_user() - if you need to tap into user actions or modify the user object.
You don't need to use all of these hooks all of the time, but they are some of the most used ones.
Great list so far! Some others for consideration:
Ability to use Drush to update or setup a site
Strong understanding of good best practices configuration for performance, security and SEO of a Drupal site (think launch checklists)
Having submitted a module to Drupal.org (however simple) or submitted a patch (the process of getting a CVS account and getting your first code in is instructive to the community and to standards)
You don't need SEO skills for templates, drupal usually helps with SEO alot. Ofcourse a developer who will slice a design must know that all headings must be done with h1,h2,h3,h4 tags. that's really basic one. everything all is up to drupal..
as for my opinion to be a drupal "developer", you need some very basic skills in PHP. Because drupal is really written without object-oriented programing, and without DESIGN PATTERNS, so these are two things is really makes you a programmer.. without them it just [sorry for this word] bullshit not a programming.
I think anybody can install drupal or wordpress or some cms-made-simple, systems if you have at least once connected to ftp in your life... to develop plugins for them is a requires basic skills of php. Ofcourse if you'll find skillfull developer then he will know oop basic, and will write plugins with OOP and that code will be really NiCE! =)
Being able to edit existing functionality (core or module) without touching the core or module and knowing whether to put it in template or a custom module.
As we anything web related these days, you really must have a good understanding of the HTTP protocol. You also need a good understanding of JavaScript, the DOM, CSS and HTML5. Knowing a bit of jQuery is not enough for a developer, you need to understand what your are doing with the DOM, HTML5 APIs and CSS in order to build features and behaviours into the browser. You also need to understand the Drupal JavaScript APIs, both on the server side (hook_library(), #attached, etc.) and the client side (Drupal.behaviors, etc.)
You also need to known the various APIs of Drupal. The Form API is not the only one. You need to understand the Menu system (page, access, title and delivery callbacks, how to pass parameters to them, etc.), the Queue API for asynchronous operations, Batch API for long running operations, Entities and Field APIs for user editable structured data, Theme API and Render Arrays for anything presentation, Cache API, Schema and Database APIs, File API, Cache API and the Localization API.
I am new to Drupal and I am figuring out a set of steps for developing a Web Application. I planned:
1) Develop the application without any template or graphic effect. Just create your nodes, your views, integrate some plugins and so on. Goal: to have a website up and running from a functional point of view
2) Customize plugins: if some functionality is missing, customize plugins or develop on your own
3) Choose Theme and Customize it
4) Insert graphic effects (ex. JQuery)
5) Fine tuning
I am learning Drupal so I haven't any experience. Am I figuring out correctly ?
There are different approaches. This is how I work:
Define the goal of the site
Define functions
Define menu / pages
Deleveop theme / templates. Either from scratch or themes you downlowd.
Replace dummy text with Drupal code to show content. Here you functions comes in to place.
Remebmer that a node i Druapl, is basicalle your content / your text when you write articles.
When I tried to learn Drupal, I summarized some content here : http://stiengfoto.wordpress.com/category/development/drupal/
If you never have used CMS before, find some tutorials and start with the very most basic things.
Drupal i a great piece of machinery, but it might not be the best choice as a web app framework. It depends what you want to do really, but usually web apps is a lot of custom code / logic. Here Drupal's complexity might become a hindrance for you.
If I was going to build a site or application I would probably do something like this.
Find all the modules that I need. This can involve
Finding the contrib modules that I absolutely need.
Figuring out if I should use a contrib module + alterations or build my own module.
Searching for modules that can solve a problem, looking for solutions to problems that seem common etc.
Do the actual development, and create the features needed.
This include functional jQuery like AJAX.
Theming - this can in some extend be done while developing.
First step is usually to find a good base theme for your design, like Zen.
Then you need to implement the design.
Add jQuery where needed for flashy effects
Test and bugfix.
This should be done while developing, but when all looks good, be sure to give it all some good testing to make sure that it doesn't fail anywhere.