We are very proud to announce today the launch of a revamp of the Acquia Network. The Acquia Network has been at the heart of our offerings to customers since the founding of the company. This launch is the start of a massive upgrade in the software and services Acquia provides to help our customers be successful building and maintaining Drupal sites.
Building on feedback from our customers, we have refocused the Acquia Network on providing value to our subscribers in three ways;
Do you have a site which is 2 years old, and you’re not sure if your site is ready to upgrade? We can help. Our team will deliver a course on upgrading Drupal, the day before DrupalCon. In the day long course, you’ll get expert advice and feedback from Jacob Singh (Engineer), Joshua Brauer (Client Advisor), and Erik Webb (Technical Advisor) from Acquia on Upgrading Drupal. You can learn about what's new in Drupal 7 and how it will affect your site upgrade.
You can register for our webinar about this course: Thursday, February 3, 2011 - 1:00 PM EST
The standard 14 step instructions outlined in UPGRADE.txt for Drupal 6 are simple to follow. Many of the steps are common sense; update contributed modules; back up your site; test restoring from backup; verify and test your new upgrade...
Yet each Drupal site is unique with many contributed modules and modifications which make the process more complex. Our PS team reports that larger sites have on average 80-100 projects installed on their sites. Before a major upgrade, each one of those must be updated to the latest 6 compatible version. But are all of those projects on your site ready with a Drupal 7 upgrade path?
Lynda.com has just announced three new training courses...
The first few months of Drupal Commons business for Acquia has been great.
Wanna come to a BoF about BoFs?
Birds of a Feather, has such a nice ring to it. This way of self-organizing allows people of like minds to flock together in their motley way spontaneously sprung from the confines of the well architected schedule which didn’t quite fit their needs.
It’s a testament to the efforts of conference organizers at DrupalCon that they can field submissions from such a large number of presenters striving to satisfy the needs of thousands of people with wildly popular sessions. In Copenhagen, rooms were filled to the brim with eager listeners, and even afterwards people seek out the recordings of the sessions they missed. It’s an ideal opportunity to broadcast the latest and greatest in Drupal.
But then there’s the fringe. And the DrupalCons provide for that too. Many computing conferences allow for physical spaces for BoFs: Birds of a Feather sessions. A whiteboard is used to mark the available time slots and locations, where people put in their suggestions and find their niche.
Not seeing anything on the official schedule that suits? Head on over to the BoF board! There's now a forum on the DrupalCon website where people are chatting about BoFs already! I really love BoFs, and I think we can even make them better and get more out of them.
Making a better BoF
At DrupalCon San Francisco, I had an epiphany, OK, not a huge one. BoFs kinda suck when you spend 20 mins going around and introducing one another, and then you get into the meaty bits and it’s already over. There’s an alternative: Open Space Technology.
I wanted to show how so-called "non-coders" can make significant contributions to the Drupal project. Probably the quickest way to make friends with a module maintainer is to help out in the issue queue. You can also help out with triage on some of the busiest projects. This requires no coding at all. (Check out the Views bug squad!) After triage, the next things you can do are:
- Try to replicate bugs - are you finding the same problems under the same conditions?
- Download and test patches - does the patch work as expected under your conditions?
Previously in Part 1 - I described how you can simply download and test your favorite modules to make sure they are working in Drupal 7. Even simple modules like "Environment Indicator" have alpha versions available for Drupal 7. That project has no issues for 7.x version. But has it been fully tested? Give it a whirl! If you find a bug, then say so.
In this next part, I have 2 videos which will show your how I apply and test a patch with a GUI; then how I create a new patch. Now we'll look at patches: applying, testing and submitting.
First: What's a patch?
Does the word "patch" sound mysterious to you? Never had a chance to "apply a patch"? or "Reroll a patch"? Or possibly even submit a new one?
Patches are text files they have instructions indicating differences with lines preceeded by a "-" to indicate that a line will be deleted, and a "+" sign to indicate a line will be added. This set of instructions is saved, instead of just making the changes directly. This means you can pass along this fix. By sharing this fix, other people can apply this patch and get the same fix.
When we say "don't hack core" in Drupal, it means don't change the files directly. You can however write neccessary patches, apply and share them. Patches are written to fix a bug, but sometimes can introduce new problems. Because of that, they need to be tested. And we'll see how to do that.
Drupal 7 RC 1 needs testers. And now more than ever, your favorite modules need testing too. As Moshe wrote yesterday, they're here to collect on the D7CX pledge. This is a great way that a new Drupal user can make a significant contribution, and make some friends in the process :)
I was amazed at the most recent DrupalCamp in Ireland that some people I spoke to weren't trying out Drupal 7 yet. I've been using Gardens so much, I adore D7 and get all itchy when I use D6. Come in, the water's fine!
Well, except that many of your favorite modules aren't quite ready yet. Many module maintainers took the D7CX pledge to be ready for the release of Drupal 7. That looks to be in about 7-10 days! There's a mad rush on and even as a non-coder, or a new user to Drupal you can help.
Download Drupal 7, and test your favorite modules. Report bugs and submit patches! It's easy, right? I'll be making a few posts this week to take "the scary" out of testing patches, and show you exactly how I do it. In this post, we'll get D7 up and running, and determine the best way to locate modules which need help, and the specific issues which need testing.
We had 226 respondents to a survey about roles in the Drupal community. Though we pilot tested the survey and honed down the questions, the findings were inconclusive, though we could draw one result. Apparently we use terms like "themer" or "module developer" yet these platonic ideals seem to only exist in our heads. In reality, a person on a team will find themselves handling many roles. In the context of a larger organization, Drupal is one tool in a larger set to be integrated with. In a smaller dev shop, Drupal is again, one tool of many which are used. Slicing up Drupal developers into roles turned into a muddy exercise.
However, there was one interesting outcome. Of the respondents, 203 individuals replied to the open-ended question: "What do you wish you had known when you started Drupal"? It's taken me this long to code and analyze this information so we can make some use of it. I think it can give people within Drupal some insight on how we can improve our welcome mat. And for those who are new, I hope this gives you some good tips and advice!