We've come to realize that we are hosting more and more developers who are using Git to manage their projects (including ourselves).  The current Git repository that we're hosting on our own servers is a little cumbersome, so we're working toward having our own Gitlab repository, which will be available to our hosting clients.  This way you'll have a Git repository that can be private, on your local network, and will be free as long as you host with us.

We're still in the process of deciiphering the details of Gitlab, so it's not available yet - but I expect some time before summer.

As a CloudFlare Optimized Partner, we are thrilled to offer the CloudFlare Railgun™ technology to all our customersas a free addon for Half-Acre and VPS hosting packages. Railgun is CloudFlare’s latest performance optimization technology that gives you significant improvements in site load times. To activate Railgun, log into your Cloudflare account and select Railgun “On”. Note that Railgun costs at least $200 if purchased from Cloudflare directly. Read on for additional details and instructions:

Railgun ensures that the connection between our network and the CloudFlare network is as fast as possible. Railgun achieves a 99.6% compression ratio for previously uncacheable web objects by using techniques similar to those used in the compression of high-quality video. The average website can expect a 1.43x performance increase.

Almost everyone who does any form of Drupal development uses Drush - it's the Swiss Army Knife of the Drupal world. Drush is the Drupal Shell, and it lets you do a whole lot of amazing things with Drupal sites without actually going to the site, logging in, and clicking buttons.  It's a command-line tool (and since I'm an old UNIX hand, it's just right for me.

Despite the fact that we all use Drush, it's pretty clear that some of us use it better than others. I'm often really impressed with seeing someone else use it effectively, with powerful aliases, and doing workflow things with drush that I could hardly imagine. And let's face it, we can't always have a mentor at hand.

This book, Drush for Developers Second Edition,  can be your mentor. It's a pretty quick read (a little over 150 pages) as technical books go. It covers a lot of territory along the way, though.  As all these books seem to do, it starts out with installing Drush on your server, and then moves forward into using it.  Though I've been using Drush for some time now, I never have quite been able to grasp the more advanced uses, like using Drush to move code and features from development to test to production, for example.  This book give a really good idea of how to do some of those functions.

We're working on a lot of new hosting infrastructure projects we though you might be interested in.  A lot of this is in preparation to provide a better development and hosting enviornment for Drupal 8. We are re-imaging web servers and other servers to do a better job for modern Drupal hosting.  Things you can look forward to include:

1. Composer baked into our servers for easier development.
2. Compass baked into the servers for better development with CSS pre-processing.
3. Starting to move new servers into CentOS 7 to provide newer hosting binaries.
4. Better support for resellers.
5. Easier setup for use of varnish and memcache on our higher-end server packages.
6. Better support for Drupal 8 on shared hosting.  We want to be able to offer a reasonably-priced environment for hosting Drupal 8 sites.

This is all part of our commitment to provide useful hosting services to the Drupal community. We expect that although Drupal 8 is great, it's going to require more specialized hosting in a lot of cases.  We're committed to the Drupal community, and look forward to getting more input from you on your Drupal hosting needs now and in the future.

You may have heard the recent information about the POODLE attack. Essentially this is an issue where SSL connections may revert to the known-unsafe SSLV3 protocol. There's really no fix for SSL V3, but there IS a cure that amounts to disabling the fallback to older SSL protocols such as V3. We're going to be doing two things about this:

1. We are in the process of rolling out the recent Openssl fix that uses TLS_FALLBACK_SCSV to stop the rollback to older SSL protocols
2. We are in the process of setting up to make our SSL servers no longer accept EITHER SSL2 or SSL3 as protocols.   This is really the right thing to do, but it WILL mean that people using browsers that do not understand recent secure connection protocols will be in trouble.  This specifically includes old versions of IE. The upshot of this is that once this is completed, people on Windows XP will no longer be able to make secure connections to our servers (with IE).  We see this as a minor issue compared to the possibility of compromised security.  We are NOT doing this step in the near future, but will be doing it as a normal consequence of a larger operating system upgrade some time in the next few months.

More details on POODLE below the fold: