When it comes to building Drupal sites with a team of developers, there's perhaps nothing more important than establishing a productive workflow.
Blog series: #1 of 5.
(Part 1 of the "Site Performance with Drupal 8 and Symfony" blog series)
(This article does not represent the current state of Drupal 8 development.)
Back in the days of yore there was FTP, and it was OK (don’t fool yourself, it was never ‘good’).
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.
I recently attended the Percona Live MySQL conference and wanted to share some of the exciting activity in the MySQL community. For our databases we use Percona Server 5.5 and standard MySQL replication with a multi-region offering using Tungsten Replicator.
At the conference there was a lot of attention for MySQL 5.6. The first aspect to hit the spotlight was the fact that Oracle had produced another quality release among worries that under their stewardship MySQL would slowly be killed off. There are a couple of aspects that still warrant attention like the number of bugs in the official MySQL bug database that are not open to the public. This makes it harder to do proper research on open or fixed bugs and introduces the possibility of duplicate bugs and duplicate work. That said, most of the presenters at the conference seem to agree that MySQL 5.6 is the way to go. It’s still early in the life cycle so there are not many production deployments yet and it makes sense to wait a couple of minor versions to ensure the bugs have been shaken out. Oracle is however starting to create a good track record for their QA of MySQL releases, especially in comparison to previous versions like 5.0 and 5.1.