Drupal Camp Wisconsin is on! and will be held on July 29-30 in beautiful Madison Wisconsin. This year we will be meeting at the Chemistry biulding on the UW Campus. There are still open slots for presentations --- so please stop by at http://drupalcampwi.org or make a session proposal, or to sign up for the camp.
Yesteray I went off on an experiment with one of our own Drupal sites. For some years now I've maintaned the web site http://www.uppitywis.org - it's a political blog about progressive politics in Wisconsin. It's gone thorugh a lot of different configurations and life stages. At the moment it's built on a pretty straightforward build of Panopoly,. In the most recent version I have taken it out of Varnish, and it runs behind Cloudflare.
In an attempt to eat our own Dogfood as a Cloudlflare host, I though I'd make a stab at making Cloudflare cache the entire site, rather than just the static assets. You can do this in the free Cloudflare implementation by setting up a rule that says "cache everything" and putting it in with your three allowed rules. I've also set up rules to not cache admin* and user* and have put those ahead of the cache everything rule - so that admin functions are not cached.
I'm spending time this week at Nerd Summit 2015. This has been a great experience, covering many different areas. This is fairly heavy on Drupal, but not at all Drupal-specific. At the moment I'm in the Business Panel, which is really very interesting.
The latest requirements for Drupal 8 include a requirement for MySQL/MariaDB/PerconaDB of version 5.5.3 or later - now THAT one may be an issue for a lot of hosting companies. We're going to get that done, but it's a little more unusual than the PHP requirement. At the moment our solution to this is to be using CentOS 7 for all of our database servers (and since CentOS 7 uses MariaDB 5.5, that works fine). We're currently re-thinking what we're actually going to do about this before the Drupal 8 release.
I'm writing a little bit today about some of the concerns that folks are having about Drupal 8, the new hosting requirements it imposes, and particularly the concerns that smaller organizations will not be able to find Drupal 8 compatible hosting plans. There is a lot going on with us and with other hosting companies at the moment to support Drupal 8 and other PHP software that has more modern requirements. We don't think this will be an issue with most reliable hosting companies by the time Drupal 8 ships.
Some people call it spring, but obviously they're not coders. Twin Cities Drupal Camp is just starting up and runs through the weekend. This is always a great camp, and has a lot of Drupal heavy-hitters. You're bound to learn a lot (and my heart is broken that I cannot cross the river to go to it this year due to a bunch of other commitments).
Even nearer to our hearts over here in the land of cheese is Drupal Camp Wisconsin - which this year is going to be a little later than normal (August 7 and 8), but will be in the stunning new Madison Public Library. I just opened up session proposals on the site, so if you're interested in coming to Madison, WI for some Drupal goodness, come register for the free Drupal Camp WIsconsin, and sign up to present. This is a lower key sort of camp than a lot, and will feel more familiar to those who remember Drupal camps from a few years back. But great fun, and this year it will be downtown right next to lots of great Madison places for food, spirits, and relaxation.
Lastly is the ever-wonderful Drupalcorn in Iowa. I'm actually planning on going this year and have put in a couple of session proposals. You should go too, since there's no such thing as too much Drupal conversation. July 30-Aug. 2 in Cedar Falls Iowa. Don't miss the Powerpoint Karaoke, where hapless souls get to do Powerpoint presentations based on random selections of slides. Heck, that's what most of my presentations look like anyway, so I should be GREAT at that.
See you all at the various spring and summer Drupal activities in fly-over land.
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:
- Composer baked into our servers for easier development.
- Compass baked into the servers for better development with CSS pre-processing.
- Starting to move new servers into CentOS 7 to provide newer hosting binaries.
- Better support for resellers.
- Easier setup for use of varnish and memcache on our higher-end server packages.
- 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.