Problem at hand!
When it comes to building Drupal sites with a team of developers, there's perhaps nothing more important than establishing a productive workflow.
This post is part of the "All you need to know to become a great Drupal developer" blog series.
The Migrate module provides services for migrating data from various sources (other CMS frameworks, external web services, or other Drupal installations) into the local Drupal environment. It has been used to migrate sites such as The Economist, Examiner.com, Stanford Law School, and PayPal and eBay's developer forums (x.com) to Drupal.
Migrate 2.6 is now in beta. Today I will cover some of the most significant changes at the framework level, for those who have been developing their data migrations using Migrate 2.5 and earlier. There have also been significant UI changes, and the introduction of a framework for implementing wizard-style UIs for defining migrations, which will be covered in future posts.
Security issues are created in custom code when developers cut corners during development or don't make proper use of the APIs, among other reasons.
In this article, I’m going to show you a few methods to separate your public site from the vulnerable parts of your administration area.
[Update 09/09/2013] I mentioned below that we'd make our scripts available for setting up BPF.