Most projects start with you trying out something locally, getting it working and then after some initial testing you might then want to publish the project on Drupal.org. Sandboxes are a great way to throw up some code and the perfect place to pop random code that others might find useful or a project that you just don't want to maintain. If you go and create one on Drupal.org then you'll get helpful instructions for creating a new git repository and creating a basic module to go in the repository and then pushing that code to Drupal.org's servers.
In Drupal 6, if you called node_load then what you'd be returned would be your own copy of the node to change and modify as you pleased, but in Drupal 7 this was changed. By default, what you actually get back from a node_load is essentially a reference to a global singleton for that node. This has the interesting side effect of meaning that if you change anything in the node object, you are probably changing everyone else's copies of that node too.
Here's a quick follow-up to my original post on Dynamic forms in Drupal 7, as a reply to Wappie08, who asked me about combining conditions in the #states array to add increased control over the display of your form elements.
The code that runs http://api.drupal.org is of course Drupal, and it is essentially just scanning the code it's told to and displaying it in a nice format. You can quite easily set up your own API site that you can use to scan your own custom code, or if you're a module developer, your module's documentation (you do have documentation in the code right?)
I'm going to outline how we can use Drupal and Jenkins to build a really nice system for creating an API site that will get updated on-demand, and will manage itself.
It sounds very simple, and indeed it is - with only one small gotcha that we couldn't find any documentation for. We basically followed the steps outlined here : http://code.google.com/apis/+1button/ which is simply :
We are all very excited about DrupalCon coming to London (well London-ish - http://london2011.drupal.org/conference/venue ) - and now that we are Silver sponsors we are literally jumping for joy ... now we just need to think of something to put on our very own exhibitor table ...
Not strictly a Drupal post this, but something that I was playing with yesterday that I was really struggling to find any documentation on. We wanted a simple "share" on facebook link, we didn't want to go through the process of creating an app and using the opengraph API - instead we just want to use the simple sharer.php script but have a bit of control over what is being shared.
Aegir is a very clever Drupal hosting system built using Drupal and Drush. It is divided into two parts: the frontend and the backend. The frontend is essentially just a standard Drupal site that stores its data in the database and then some drush scripts that manipulate the data. The backend (provision) is just a collection of drush scripts, and it stores its data in Aegir contexts which are essentially just arrays of data stored in text files on disk. One of the most mysterious processes in Aegir is sending data from the frontend to the backend to be stored in these contexts. Recently I cracked this mystery, and I'm going to explain how.
Aegir is a very clever hosting system for Drupal that sites and provisions them on various servers and does lots of clever things. One of the clever things that it has had for a while is a task queuing system. You can ask Aegir to lots of different things all in one go, and Aegir will queue them up and run them at its own pace. This provides a really good separation from the front-end Aegir website and the back-end Aegir scripts.