Sometimes as a module developer you need to have some code execute periodically, like maybe every day or even once a week. This might be to optimise an external system, or pull in some external data or to compute some statistics every day etc. Drupal provides a very simple way of doing this: hook_cron but if you want your code to only execute say once a day or after 6pm only, then you have to add extra logic to your implementation. However, the Job Scheduler module provides a nice framework for setting up and running these periodic functions.
Sorry if you are expecting the 'solution' to be given in this post, but this is basically a brain-dump of where I'm at with this problem, and my thoughts on how I might go about solving it.
Livereload is one the coolest things to happen to frontend development in the last little while, and actually it can really speed up your work. Basically it re-loads your CSS (and Javascript some of the time) automatically as you make changes. You don't have to make a change and then switch to your browser and manually reload the entire page, change 'notifications' are pushed to the browser where they will trigger that single changed file to be reloaded.
There are lots of sites detailing how it works, and there's a great Mac program called: LiveReload that will get you up and running super quick, if you have a Mac. If you have linux though, it's actually really simple too.
When developing we tend to use a lot of different domains to do our work on, I typically will use the .drupal top level domain, so my project URLs look something like:
project-name.drupal
When starting a new project, one of the annoying things that we have to do is create an entry in the hosts file for this domain:
127.0.0.1 project-name.drupal
On Ubuntu there is a really simple way to automate this and give yourself a 'wilcard' DNS entry, so any domain that ends in .drupal will resolve to my local machine. Enter Dnsmasq.
This article discusses how we can use a combination of techniques to take the standard 'Confirmation Form' provided by the Flag module and get it to load in a modal window rather than on its own page. We'll also extend this form slightly to allow the user to include some additional data before clicking 'Confirm'.
This is a real quick one, but so useful! We often want to render a block within content, perhaps as part of a node (maybe in hook_node_view, and then made configurable like a field), but there's no obvious way to do this correctly for any block. Drupal normally renders its blocks per region, so there is no single function to embed a block.
Facebook integration is obviously starting to become a de facto requirement with most web development projects. In most cases the requirements are reasonably straight forward and involve nothing more than including a ‘Like’ button on content, but what about actually adding your own bespoke content to Facebook like The Guardian – bring on the Facebook Canvas App.
Drupal 7 fields are great, but using multiple valued fields and field collection you can quickly reach the point of having a form that looks like this:
In this contrived example I've got two field collections and a multi-valued 'Links' field within that.
Although it's reasonably clear what clicking 'Add another item' will do in each case, when the form is full of data it can become less so.