Oct 18 2018
Oct 18

by David Snopek on October 17, 2018 - 11:55pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for the Search Autocomplete module to fix a Cross Site Scripting (XSS) vulnerability.

This Search Autocomplete module enables you to autocomplete textfield using data from your website.

The module doesn't sufficiently filter user-entered text among the autocompletion items leading to an XSS vulnerability.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

Note: We only support the 6.x-2.x branch (we don't have any customers on the 6.x-4.x branch), so that's the only one we're going to do.

If you have a Drupal 6 site using the Search Autocomplete module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Oct 17 2018
Oct 17

by David Snopek on October 17, 2018 - 6:17pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Critical security release for Drupal core to fix multiple vulnerabilities. You can learn more in the security advisory:

Drupal core - Critical - Multiple Vulnerabilities - SA-CORE-2018-006

The following vulnerabilities mentioned in the security advisory also affect Drupal 6:

The first vulnerability is in Drupal 6 core, however, the 2nd is only present in the contrib modules: htmlmail, and mimemail. If you don't use those modules, you're not affected by the 2nd vulnerability.

If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Oct 10 2018
Oct 10

by David Snopek on October 10, 2018 - 12:40pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Critical security release for the Lightbox2  module to fix a Cross Site Scripting (XSS) vulnerability.

The Lightbox2 module enables you to overlay images on the current page.

The module did not sanitize some inputs when used in combination with a custom View leading to potential XSS.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the Lightbox2 module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Oct 08 2018
Oct 08

by David Snopek on October 8, 2018 - 4:45pm

If you haven't heard yet, PHP 5 will reach the end of its security support (from the upstream project) in December of this year.

During DrupalCon Baltimore we announced that we'd be updating Drupal 6 to work with PHP 7.2, and, in September, we announced that we'd be making a big push to get that live with a couple of our customers.

Finally, we have something to show for it! :-)

So far, we've only tested with a few sites, so I'm sure there's some additional issues and bugs we haven't encountered yet. But we have an initial release of Drupal core and some selected contrib modules that work with PHP 7.2 in our testing.

And all our work so far has been released back to the community!

Read more for the details :-)

Drupal core

The short version: We've released Drupal 6.45 with support for PHP 7.2

We've take a particular approach with this:

  • We included a shim for the ereg() family of functions that were removed, rather than converting core to using preg_*() functions. This was done because contrib also uses those removed functions and this saves us from having to update many contrib modules.
  • In one or two cases, we modified Drupal core to maintain the PHP 5 behavior of its APIs if that behavior was depended on by "a lot" (subjective judgement) of contrib modules, again in order to have to update fewer contrib.
  • We made most of the updates recommended by the PHPCompatibility standard for phpcs
  • We tried to retain (and tested for) PHP 5.2+ compatibility, so that our Drupal core fork would continue to work for people who haven't updated yet. (If you're not aware of it, 3v4l.org is a great tool for trying PHP snippets in lots of versions of PHP at once, and, well, we have a bunch of different PHP versions via Docker too.)
  • But otherwise, we've based our changes on actual manual testing and confirmed bugs, and tried to make the smallest possible change to fix each problem.

Important security note!

Drupal adds a .htaccess file to the public (ie. sites/default/files/) and temporary files directory to prevent PHP files that somehow end up there from being executable when using Apache.

However, this .htaccess file won't work with PHP 7 unless modified!

One way to do this, is to delete the .htaccess files and then visit the "Status report" on your site, which will re-create the file with the changes necessary for PHP 7.

We've considered adding an update hook to do this, but we're worried about wiping out any added changes - see the issue on GitHub and leave your thoughts.

Drush

You need a patched Drush 8 in order to work with PHP 7. See drush-ops/drush#3706 and you can grab the patch here.

The Drush maintainers seem open to committing this patch, so hopefully, this will make it into a Drush 8 release at some point. :-)

Selected contrib modules

Of course, the true power of Drupal is in it's contributed modules!

We're committed to updating the contrib modules used by our D6LTS customer to work with PHP 7.2.

That said, updating contrib (especially complex contrib) is a lot harder than Drupal core, so we expect this process to take us all the way to the end of the year.

Here's the contrib releases we've made so far:

There's also a number of contrib modules (generally the simpler ones) that work fine without any changes.

How to get involved!

If you're also working on getting your Drupal 6 site working on PHP 7, and you find any issues or bugs, you can write an issue on the project on GitHub or in the D6LTS queue on Drupal.org. We appreciate the help and a number of people have contributed already - thanks! :-)

Or if you're interested in us doing this for you...

Sign up for Drupal 6 Long-Term Support!

Have you updated your Drupal site to PHP 7 already? How'd that go? Please leave a comment below!

Oct 03 2018
Oct 03

by David Snopek on October 3, 2018 - 4:30pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Critical security release for the Print module to fix a Remote Code Execution (RCE) vulnerability.

The Print module provides printer-friendly versions of content, including send by e-mail and PDF versions.

The module doesn't sufficiently sanitize the arguments passed to the wkhtmltopdf executable, or HTML passed to dompdf or other PDF generation tools.

See the security advisory for Drupal 7 for more information.

NOTE: This vulnerability has a lower risk in Drupal 6 than in Drupal 7 (where it's Highly Critical). This is because you can't pass shell commands to execute using the HTTP basic auth user/pass, like you can in Drupal 7.

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the Print module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Sep 20 2018
Sep 20

by Elliot Christenson on September 20, 2018 - 1:07am

Drupal 8 was released on November 19, 2015 - nearly three years ago. The drastic architectural changes created a difficult upgrade path for those running Drupal 7. With the huge amount of investment in Drupal 7 over the previous 5 years, this set off shockwaves of fear across the Drupal ecosystem. Recently, Dries Buytaert, the project lead for Drupal, announced the planned launch of Drupal 9 in 2020. That signals the "End of Life" of Drupal 7 in November 2021. When do I need to upgrade?

By the way, that is more than ten years after the release of the first version of Drupal 7!

It's also the date of the "End of Life" of Drupal 8 (more on that later).

I'm On Drupal 7, So I Have to Upgrade to Drupal 8 by November 2021?

If you aren't getting support from a company doing long-term support for Drupal 7, then you'll actually need to upgrade to Drupal 9!

PHP versions, Symfony versions, and other software roadmaps necessary to keep your website running safely and securely can be confusing and complicated to follow! If you don't, Dries's announcement might be causing you some renewed anxiety. After all, you had three years to upgrade your Drupal 7 site to the shiny new Drupal 8 codebase. If you couldn't do it in the previous three years, why would you be able to over the next three years? That answer is complicated - and depends on your site!

So If I Upgrade to Drupal 8 Today, I Have to Upgrade to Drupal 9 by November 2021?

Maybe, but that's not nearly as bad as it sounds. :)

The secret of D9 is that it's really just the next iteration of D8 - it's not going to be a complete rewrite like D8 or D7 or earlier major versions were.

The plan is that it's going to drop deprecated APIs, and update 3rd party dependencies (like Symfony) - and not much else. In fact, the goal is to allow contrib modules that don't use any deprecated API to be compatible with both D8 and D9, without needing to have two separate versions of the contrib module (like we have always done in the past).

Upgrading from Drupal 8 to Drupal 9 will be more like upgrading from Drupal 8.5 to 8.6.

So I Never Have to Upgrade to Drupal 8 or Drupal 9?

Well...

We've been providing Drupal 6 Long-Term support for over 2 years (as one of the two vendors officially blessed by the Drupal Security Team), and I think we've proven that commercial Long-Term Support works! We've made dozens of security releases, and kept hundreds of sites support and maintained, and plan to continue to do so for a while.

We're even working on getting Drupal 6 core and popular contrib modules updated to run on PHP 7.2. :-)

So, if you don't update to Drupal 8 or Drupal 9, we're going to provide Drupal 7 Long-Term Support (just like we've been doing for Drupal 6).

But if you don't plan to purchase Long-Term Support from us or another vendor, then you really should plan your upgrade by November 2021.

Is Drupal 7 Dead Already? Be Honest!

The Drupal Community has committed to getting Drupal 7 to work on the newer versions of PHP through November 2021. Drupal 7 needs adjustments to completely work with PHP 7.2. Since the earlier versions of PHP are all being "End of Life" as well, this is a necessary step to keep your Drupal 7 site safe and secure. PHP is the programming language Drupal is built on, so changes in PHP have massive effects on what happens with Drupal! If all of that sounds a little familiar, it's because myDropWizard announced recently that we would update Drupal 6 to make it compatible with PHP 7!

Drupal 7 is far from dead.

How Hard Is it Move to Drupal 9 (from Drupal 6 or 7)?

Since Drupal 9 is going to be so similar to Drupal 8, moving to Drupal 9 (from Drupal 6 or 7) should be pretty much the exactly same as upgrading to Drupal 8.

The changes announced shouldn't make life any harder for anyone who's already on track to update to Drupal 8 before November 2021!

OK, So How Hard Is It to Move to Drupal 8 or 9?

It is significantly easier and more practical to move to Drupal 8 in 2018 than it was in 2015. Many of the best modules have gotten incorporated into Drupal Core, still others have been obsoleted by new and better ways of doing things, and the rest have largely gotten updates to Drupal 8 compatibility! The Drupal 8 ecosystem is now really great, and myDropWizard is committed to Drupal 8 as well as Drupal 7. We built our Roundearth platform on the modern Drupal 8 Core!

So, your needed features are probably now available in Drupal 8 - even if they weren't at launch in 2015. However, what's also amazingly improved is the upgrade path. For simple sites, it's phenomenally simple to move your content from Drupal 7 to Drupal 8. Your mileage may vary with more complex sites, but the good news is that there's no reason to suspect that the upgrade path from Drupal 7 to Drupal 9 will get worse. It will likely get better.

That said, upgrading to Drupal 8 (or 9) is still a big investment, so we fully understand that some organizations won't be able to manage it in time, and that's why we plan to provide Drupal 7 Long-Term Support.

So, Why Are We Moving Beyond Drupal 8 Already?

Unlike the move from Drupal 6 to Drupal 7 and then again to Drupal 8 - which required massive re-engineering of legacy websites, the plan for Drupal 9 is to be 100% compatible with the latest released version of Drupal 8. Drupal 9 will simply drop support for modules that weren't following up-to-date standards of that latest Drupal 8 version. So, in many cases, the same module code will work in Drupal 8 and Drupal 9 for a good amount of time. The focus on backward and forward compatibility was a lesson learned by the entire Drupal community.

The planned major version jump from Drupal 8 to Drupal 9 is because the Symfony 3 PHP framework that lies at the core of Drupal 8 is itself moving on to newer versions. Like Drupal 7, Drupal 8's "End of Life" is also scheduled for November 2021. It's this last part that made many people nervous! The pending "End of Life" for Drupal 8 so soon after they spent so much effort upgrading is sure to fill anyone with anxiety. The plans to update seem sound, and the timing seems appropriate, so that should help calm some of the fears.

What's the Short Answer? When Should I Upgrade?

  • Drupal 6? You should already upgrade if you don't have D6LTS. We've been has been providing Drupal 6 Long-Term Support (and will continue to do so for the forseeable future :-)
  • Drupal 7? You should make plans to upgrade by November 2021 - or make sure you have D7LTS engaged before then.
  • Drupal 8? You should make plans to upgrade by November 2021 - but that should be easy! Upgrading from Drupal 8 to Drupal 9 will be more like upgrading from Drupal 8.5 to Drupal 8.6. By this time Drupal 9 should have been out for about a year.

There are all sorts of reasons why organizations don't update to the latest software - most of it boils down to budget. Small organizations with simple sites can't afford thousands of dollars to upgrade to the latest version of Drupal. Large organizations with comparatively complex sites can't always afford the expense of every upgrade either.

Jul 18 2018
Jul 18

by David Snopek on July 18, 2018 - 2:42pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for the XML sitemap module (version 6.x-2.x only) to fix an Information Disclosure vulnerability.

The XML sitemap module enables you to generate XML sitemaps and it helps search engines to more intelligently crawl a website and keep their results up to date.

The module doesn't sufficiently handle access rights under the scenario of updating contents from cron execution.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the XML sitemap module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Jul 05 2018
Jul 05

by Elliot Christenson on July 5, 2018 - 12:58am

We're Drupalers who only recently started digging deep into CiviCRM and we're finding some really cool things! This series of videos is meant to share those secrets with other Drupalers, in case they come across a project that could use them. :-)

In the screencast below, I'll show how how you can set-up a public membership directory in Roundearth's CiviCRM! Many organizations have a need to have public visitors see their member individuals or organizations

Watch the screencast to see how to add a public membership directory with Roundearth:

Video of CiviCRM Membership Directory

Some highlights from the video:

  • Add Memberships to a Contact
  • Create a Smart Group of Members
  • Boom: Create a Public Membership Directory

Please leave a comment below!

Jun 28 2018
Jun 28

by Elliot Christenson on June 27, 2018 - 11:38pm

We're Drupalers who only recently started digging deep into CiviCRM and we're finding some really cool things! This series of videos is meant to share those secrets with other Drupalers, in case they come across a project that could use them. :-)

In the screencast below, I'll show how how you can set-up a new Campaign in Roundearth's CiviCRM! The thing about campaigns is that until there is activity, there isn't much to see, but we have to start somewhere! So, here we setup a campaign.

Watch the screencast to see how to use a Campaign with Roundearth:

Video of CiviCRM secrets for Drupalers: Fundraising Campaigns

Some highlights from the video:

  • Set-up a new Campaign Type
  • Set-up a new Campaign
  • Send a Mailing attached to a Campaign!

Please leave a comment below!

Jun 27 2018
Jun 27

by David Snopek on June 27, 2018 - 2:06pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Less Critical security release for the Generate Password module to fix an Insecure Randomness vulnerability.

The Generate Password modules allows administrators to create a new user account without setting a password, allowing the system to automatically generate one. The module doesn't use a strong source of randomness, creating weak and predictable passwords.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the Generate Password module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Jun 14 2018
Jun 14

by Elliot Christenson on June 14, 2018 - 12:15am

We're Drupalers who only recently started digging deep into CiviCRM and we're finding some really cool things! This series of videos is meant to share those secrets with other Drupalers, in case they come across a project that could use them. :-)

In the screencast below, I'll demonstrate the new demo of Roundearth! Roundearth is our Drupal 8 + CiviCRM Distribution.

Watch the screencast to see the progress so far on the Roundearth project:

Video of Roundearth June 2018 Update

Some highlights from the video:

  • Drupal 8.5
  • CiviCRM + Bootstrap based Shoreditch theme
  • Quick demo of adding Contacts, using a Group, and sending a Bulk Mailing
  • Quick demo of a Public Event

Please leave a comment below!

May 24 2018
May 24

by Elliot Christenson on May 24, 2018 - 1:24am

When we originally announced that we'd be providing Drupal 6 Long-Term Support, we committed to supporting our customers until at least February 2017.

Each year in the spring, we've taken a look at the state of Drupal 6 and decided whether we'll extend support for another year, and if we need to make any changes to our offering. Here's the articles from 2016 and 2017, where we announced support until at least February 2019.

Today, I'm happy to announce that we'll be extending our Drupal 6 Long-Term Support until at least February 2020!

While I'm sure there will come a time, when it no longer makes business sense to pour resources into Drupal 6 for the few remaining sites, however, it's already clear to us that there's enough demand to one more year.

However, this time is a little different because PHP 5.6 will reach the end of its security support in December 2018 (8 months from now).

We can't responsibly provide Long-Term Support for Drupal 6, if there isn't a PHP version that you can securely run it on.

So, this year we're making some bigger changes to the program and to Drupal 6 itself!

Read on to find out more!

PHP 7 support for Drupal 6 (and supported modules)

If there won't be any more security support for PHP 5 after December 2018, that means Drupal 6 and it's contrib modules will need to run on PHP 7! (PHP 7.2 will have security support until November 2020.)

Unfortunately, the last official release of Drupal 6 (version 6.38) won't work unmodified on PHP 7.

So, we're going to be releasing a version of our Drupal 6 LTS fork which runs on PHP 7.2. Assuming no other security issues come up first, this could be in our 6.45 release! You can see the 'php-7' branch in our Drupal 6 fork on GitHub.

Contrib modules too!?

For our clients, we fully support their Drupal security - even for our Basic Plan! This means that we'll update the contrib modules used by our customers to work with PHP 7 as well! All your favorite Drupal add-ons from Views to CCK to Panels - and most other Drupal 6 modules will updated to work with PHP 7.2! If you're a Standard or Enterprise client, we'll even be covering more obscure modules or even custom code to have some more longevity!

Our interests are aligned on this! If your site does suffer from a security breach, we're here to help you work through it. We'd prefer you to be as proactive as possible!

Will you support Drupal 6 forever?

While some of customers would love if we'd support Drupal 6 forever, the answer is "no."

Our service is billed at a relatively low fixed monthly fee, so it depends on a certain amount of scale and overlap between our customers needs in order to be profitable.

This is great for our customers because they pay less than they'd probably pay hourly for individual services just for their site, by "sharing the load" with other customers with similar needs! But it also means that when enough of our customers quit or upgrade to being Drupal 7 or 8 maintenance and support customers, providing Drupal 6 LTS will be a loss for us.

When that happens (and it inevitably will), then we'll have to either (a) charge higher prices to make up the difference or (b) stop providing Drupal 6 LTS.

But don't worry - we'll let you know long in advance of when that is coming!

Around this time next year, we'll be announcing any changes to our Drupal 6 LTS offering, including:

  • Whether or not we'll be extending Drupal 6 support,
  • If there will be any changes to the price or service offered,
  • And if we have any special offers to help upgrade the remaining Drupal 6 sites

But for the time-being, you can expect our Drupal 6 LTS to last until February 24th, 2020!

May 10 2018
May 10

by Elliot Christenson on May 9, 2018 - 9:22pm

On May 22nd, the giant CiviCRM Meetup CiviCamp Calgary arrives! What is CiviCRM? What is CiviCamp? What is Calgary? And why should a Drupaler like yourself care? If you are familiar with myDropWizard, you probably know some of those answers already! If not, let's carry on:

What is CiviCRM?

If you have heard of myDropWizard, you probably are already familiar with what CiviCRM is and why we're so excited. For the uninitiated:

CiviCRM is a powerful, web-based contact relationship management (CRM) system.

CRM's are software that help manage your contacts, communications, and even financial interactions. CiviCRM is open source (like Drupal) that allows all sorts of organizations handle things that otherwise would have to be handled in much more ad hoc ways like word processing documents, spreadsheet documents - or even paper records!

What is CiviCamp?

CiviCamps are casual, locally-organized one day events covering everything related to CiviCRM. Attend CiviCamp and learn about CiviCRM and what it can do for your organization, meet other CiviCRM users and gather their feedback, learn advanced strategies for managing your online database, ask any questions you might have, share tips and build connections!

If you're familiar with DrupalCamps or DrupalCon, this is the parallel in the CiviCRM community. It's a place to meet other CiviCRM users and creators (like myDropWizard's Roundearth).

What is Calgary?

I'm only half-kidding. I know Americans (i.e. U.S. Citizens) have a poor reputation when it comes to cities outside the U.S. Obviously most of us have heard of Calgary - at least I did - from the Olympics a few years back.

I'm a sheltered American, like I said, and I didn't realize that Calgary is actually a huge city (over a million residents is huge to those of us in Wisconsin!), and it's in fact Canada's third largest.

I personally won't be making the trip, and I feel a bit cheated of the opportunity to check it out!

Why Should Drupalers Care?

So, all of that is great, but why should you care about that as a Drupaler? Great question! If you are a nonprofit operator yourself, or if you are a Drupal developer that works with nonprofit organizations, you should check out what CiviCRM has to offer. CiviCamp Calgary would be a great place to do it!

CiviCRM and Drupal have a long history, and we've written many other blog posts about our efforts with CiviCRM and Drupal 8:

myDropWizard has been actively working with many nonprofits for close to a year on our Roundearth project. This is our distribution of Drupal 8 + CiviCRM. Our long term goal is to increase usage of it, get the costs for development down, and get this into the hands of even more nonprofits as a hosted service.

myDropWizard's First CiviCRM Event

We're very excited to have myDropWizard represented at CiviCamp Calgary. Even more exciting: myDropWizard Co-Founder David Snopek was selected to lead a session on Drupal 8 + CiviCRM!

  • What is the current status of Drupal 8 + CiviCRM?
  • What are some challenges?
  • What are some upcoming milestones?

If you're planning on being at CiviCamp Calgary, please say "hi" to David Snopek and Will Long. I know they're anxious to meet as many CiviCRM users as possible in the short time in Calgary.

Apr 25 2018
Apr 25

by David Snopek on April 25, 2018 - 11:53am

Today, there is a Critical security release for Drupal core to fix a Remote Code Execution (RCE) vulnerability. You can learn more in the security advisory:

Drupal core - Critical - Remote Code Execution - SA-CORE-2018-004

This issue also affects Drupal 6 (although, less severely than Drupal 7 or 8). So, we're also making a Drupal 6 Long-Term Support (D6LTS) release of Drupal core and the Filefield module.

Drupal 6 core security update

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

This fix is both for Drupal 6 core and the Filefield module. This is because the Drupal 7 & 8 fixes include changes to the core 'file' module, which isn't in Drupal 6 core, but an equivalent fix applies to the Filefield module.

Here you can download:

If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install security updates for contrib modules (even though they won't necessarily have a release on Drupal.org).

Apr 18 2018
Apr 18

by Will Long on April 18, 2018 - 4:25pm

When Drupalgeddon 2 (SA-CORE-2018-002) happened a few weeks back, we saw plenty of buzz from agencies and other organizations throughout the community who were having patching parties.

Yay for patching! But were you left vulnerable by not updating all of your installations?

If you didn’t update development and staging sites, you may be at risk!

Due to the nature of the vulnerability, from the largest of enterprise applications to the smallest of brochure or hobbyist site builds, all Drupal sites were affected. This includes any testing or staging versions of your site. Depending on how you manage your local development sites, even those may have been exposed too!

Still not convinced? Read more to find out why you need to update ALL sites!

It's Just the Dev Site, What Could Go Wrong?

Far too commonly developers write off development environments as temporary or non-essential, unconcerned about the implications of those sites getting hacked. Typically those can be thrown away or easily rebuilt, but the functionality of the site itself is only one aspect of the vulnerability.

Where does the data on your staging environment come from?

In many cases production data gets copied into your staging and development sites for testing. In fact, Acquia and Pantheon give you simple tools to perform this very function. Some types of security vulnerabilities could allow an attacker to gain access to some or all of the data including users/profiles, e-commerce transactions, and other restricted content.

An exposed site leaves a target area at an infrastructure level, too.

A vulnerability that lets an attacker access the server or run unauthorized code (remote code execution, for instance) jeopardizes the entire server. Hackers may use the exploit for unsavory or nefarious purposes, such as dispatching spam email or Bitcoin mining.

Even worse, if you’ve got development or staging sites colocated on the production server, an attacker could use the vulnerability in your development site to access your production site.

This could let an attacker access or change live, potentially-sensitive, production data. This scenario also exposes any other infrastructure your site uses, including accessing 3rd-party services.

Mitigate Those Other Sites

At myDropWizard we use a two-pronged approach to dealing with potentially insecure non-production environments:

The first, and easiest, solution is to decommission any environments that aren’t needed.

This is something that should be done as part of routine upkeep, not necessarily due to a security scare, but in a pinch just power down those non-essential servers or otherwise take the sites offline.

The second option, which applies to production or otherwise essential environments, is to address the security vulnerability.

Generally this means updating affected project to the release the release which includes the fix but this isn’t the only option. For sites where upgrading to the next release may be problematic or risky, patching just the vulnerability may be the best way to address the security risk while avoiding unnecessary changes.

Conclusion

In short: Your exposure to security vulnerabilities is more that just your production site.

Every additional instance of a site widens its attack surface. Be sure to keep all of your environments up to date, as your development and staging sites can expose you to just as serious of an attack as the production site.

During Drupalgeddon 2, myDropWizard performed this work on behalf of our customers as they continued on with business as usual. Within just a few hours of the security advisory being published, we not only had all customer productions sites been updated or patched, but all other environments that myDropWizard was tasked with were also upgraded, patched, or spun down.

Our agency clients got to keep on pushing ahead with their active development, while our other clients got to keep working to achieve their objectives--whatever they may be.

If you’re interested in staying focused on your organization’s objectives rather than mangaing support and maintenance yourself, please contact us. Our whole business is support and maintenance for Drupal sites, we can help.

Do you have questions or feedback? Please leave them in the comments below!

Apr 12 2018
Apr 12

by Elliot Christenson on April 11, 2018 - 9:24pm

You may already know that we've been providing Drupal 6 Long-Term Support (D6LTS) for over two years.

What we have been hearing over and over lately - especially at Drupalcon - is "what about Drupal 7?"

Typically, only two major versions of Drupal are supported at once: the latest version, and the previous one. Right now, that means Drupal 7 and Drupal 8.

We don't know when the community's support for Drupal 7 will end or if the community itself will do some kind of LTS. But we do know that community support will come to end at some point. While the details will depend on what the community does, we just wanted to let everyone know...

We intend to provide Long-Term Support for Drupal 7, in order to keep your site going long after the end of official support!

Read more to learn more about our plans for D7LTS...

When will Drupal 7 support end?

We don't know. But probably not before 2020.

Beyond that, there's been a number of proposals. Some have suggested not End-of-Life'ing Drupal 7 until it's usage falls below a certain level. Or when the migration plan reaches a certain level of maturity.

We don't have to end community support when Drupal 9 is released - the community could provide it's own Long-Term Support too!

However, the community support will end at some point!

Maybe there will be an official D7LTS program (like D6LTS) or maybe not. If so, we'll participate.

But no matter what happens, we're going to do our best to take care of the needs of those still using Drupal 7 when it's End-of-Lifed, just like we have for Drupal 6.

Based on our experience with Drupal 6 - and the thousands of sites still using Drupal 7 - we expect to be supporting Drupal 7 for a long time.

Don't worry, we've got you!

We know a lot of people are feeling a little anxious about this. Drupal 8 has been out for a long time, but there's still many times more Drupal 7 sites than Drupal 8.

Drupal Core Statistics from Drupal.org

But don't worry!

If you have a Drupal 7 site and haven't been able to upgrade, no matter what, we've got you :-)

Apr 05 2018
Apr 05

by Elliot Christenson on April 5, 2018 - 1:53am

We're trying something new this year at Drupalcon 2018! Book some time with a myDropWizard "Support Wizard" for some FREE help with your Drupal site!

You're a first time Drupalcon attendee? You're a veteran Drupaler? Either way, you made part of your Drupalcon mission to fix a lingering issue - or at least to be pointed in the right direction!

We're here to help!

We spend our days helping Drupalers just like you every day with their support needs, so we thought "Let's bring that myDropWizard Support Face-to-Face with Drupalers: FOR FREE!"

So, drop by Booth #818 or (better yet!) schedule with us below!

Where we'll be and when

  • Our booth: We again sponsored DrupalCon this year and will have a booth in the exhibit hall! We're in booth #818!
  • David's Session: In defense of small Drupal - Wednesday (4/11) at 5pm
  • Will's Session: Next Level Twig: Extensions - Wednesday (4/11) at 2:15pm
  • Everywhere! Just like you we want to get around the convention to see everyone and everything. Stop us and say "hello!"

Schedule a one-on-one meeting

Again, we'll be happy to discuss your current challenges (or successes!) anywhere at Drupalcon, but if you want to be double extra sure that you'll be able to chat with us, schedule a one-on-one meeting with us!

Maybe you simply want to check on the current status of Roundearth: Drupal 8 + CiviCRM.

Using Doodle, you can see when we have free time and request a meeting:

The user interface is a little confusing, so just in case you're having problems, this is the process:

  1. Click on April 10th (or any date in the week of DrupalCon) in the mini-calendar
  2. You should now see the week of DrupalCon!
  3. Find a free time, click the calendar and "resize" the block to fit the time you want to meet
  4. Fill in the "Meeting request for" field with a short description of what you want to talk about (it could just be "Connect during DrupalCon" - that's fine)
  5. And click the "Create a meeting request" button

Or if you don't want to mess with Doodle, you can just send us an e-mail at [email protected].

Can't wait to see you there!

We're super friendly, non-imposing people who love Drupal and the Drupal community. :-) We all look forward to hearing how your organization is using Drupal and how we can help! Have a great week in Nashville!

Mar 29 2018
Mar 29

by David Snopek on March 29, 2018 - 12:02am

Drupal 6 reached End-of-Life over 2 years ago, so you might be forgiven for thinking that Drupal 6 and its Long-Term Support (D6LTS) no longer matter.

However, yesterday (March 28th, 2018), there was a HIGHLY CRITICAL security vulnerability announced that affected Drupal 6, 7 & 8 (and even Backdrop).

This wasn't the first Drupal 6 LTS core release (did anyone notice that one?) and it probably won't be the last. And there are still ~65,000 sites running Drupal 6 according to Drupal.org, which were affected by this issue, and could be affected by future issues.

Luckily, the Drupal 6 LTS program is still going, and we got a patch and release out immediately!

But the D6LTS program won't go on forever... at least without users of Drupal 6 continuing to buy support from the D6LTS vendors.

I think this is a good time to remind everyone what the D6LTS program is and why it's still important to the Drupal community...

Just how critical was yesterday's release?

Yesterday's release fixed a Remote Code Execution (RCE) vulnerability. That means an attacker could execute arbitrary PHP code on a vulnerable site. This includes the ability to execute shell commands or run arbitrary SQL.

While it's not as easy to exploit as Drupalgeddon - that one was listed as TD:All, or "All module configurations are exploitable", where as this vulnerabliity is listed as TD:Default, or "Default or common module configurations are exploitable" - it's likely that many or most sites are vulnerable.

(BTW, see our article on how to understand the risk calculator!)

So, like Drupalgeddon, this is the sort of vulnerability that needs to be patched IMMEDIATELY in order to beat the attackers that are trying to weaponize it, and start crawling the internet for vulnerable Drupal sites.

This is EXACTLY the sort of vulnerability that we were all worried about when the D6LTS program was first concieved of!

What is the D6LTS program?

Back in 2015, the Drupal Security Team announced the D6LTS program and asked vendors to apply to participate.

Participation means getting access to the private Drupal Security Team tracker, in order to watch for security issues that could also affect Drupal 6, and develop patches for them before the security issues are made public.

In exchange, the D6LTS vendors had to agree to:

  • Make all security patches/releases publicly available (ie. we can't keep them only for our customers)
  • Refrain from making security patches/releases public before the related D7 or D8 releases are published (ie. we can't share them with our customers early)

So, this means that we were able to work on getting a fix ready for this big security release BEFORE it was public. This is good because you want to release a fix fast, but you don't want to rush it: it could cause regressions or fail to fully address the vulnerability or even introduce new security isssues.

But it also means the whole Drupal community (not just D6LTS customers) gets to benefit from the patches the D6LTS vendors create!

Why not just wait for the patches, like, for free?

While the D6LTS vendors release the patches to everyone, we're creating them for our customers, who have specifically signed for a D6LTS plan.

So, we'll only release D6LTS patches for modules that our customers use! If you have a Drupal 6 site which uses other modules, you could end up being vulnerable.

To make things easier for our customers AND the community, we created the myDropWizard module, which will tell you if your modules are supported and if there's any D6LTS security releases for them. This available to everyone, even folks who aren't our customers.

So, you can just wait for the patches for free - we even make it easy for you with the myDropWizard module - but...

The D6LTS program won't go on forever!

While we love the Drupal community, and want to make things easier for people who are stuck on Drupal 6, it takes significant resources to provide D6LTS.

We can only do this so long as it is financially viable for us to do it!

There were 3 vendors originally accepted into the D6LTS program: us (myDropWizard), Tag1 and Acquia.

Acquia was already stopped its participation in the Drupal 6 LTS program. And they have many more resources than us, and several of the original Drupal 6 core maintainers on staff. :-)

At our height, we were providing D6LTS for over 400 sites. We're currently only supporting a small fraction of that!

People are quitting every month as they migrate their sites. Once enough people quit, we won't be able to do it anymore, or will need to dramatically increase our prices.

So, if you have a Drupal 6 site that you depend on, and want to continue getting security updates for it, please sign up for a D6LTS plan!

D6LTS until 2020?

We've currently committed to doing Drupal 6 LTS until at least February 24th, 2019.

Usually, around Drupalcon we announce whether or not we're going to continue doing it for another year, and if there's going to be any price changes. We're in the middle of making that decision right now!

Remember: all the patches we make don't just go to our customers, they are shared with the whole Drupal community.

If you want to continue see these Drupal 6 security releases, please consider signing up for a D6LTS plan!

Mar 28 2018
Mar 28

by David Snopek on March 28, 2018 - 2:25pm

Today, there is a Highly Critical security release for Drupal core to fix a Remote Code Execution (RCE) vulnerability. You can learn more in the security advisory:

Drupal core - Critical - Remote Code Execution - SA-CORE-2018-002

As we noted last week, this issue also affects Drupal 6! So, we're also making a Drupal 6 Long-Term Support (D6LTS) release of Drupal core.

Drupal 6 core security update

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Here you can download the Drupal 6 patch to fix, or a full release ZIP or TAR.GZ.

If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install security updates for contrib modules (even though they won't necessarily have a release on Drupal.org).

Feb 21 2018
Feb 21

by David Snopek on February 21, 2018 - 12:37pm

Today, there is a Critical security release for Drupal core to fix multiple vulnerabilities. You can learn more in the security advisory:

Drupal core - Critical - Multiple Vulnerabilities - SA-CORE-2018-001

What makes this release special, is that some of these issues also affect Drupal 6! So, we're also making a Drupal 6 Long-Term Support (D6LTS) release of Drupal core.

Drupal 6 core security update

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

The following vulnerabilities mentioned in the security advisory affect Drupal 6:

  • JavaScript cross-site scripting prevention is incomplete - Critical

  • jQuery vulnerability with untrusted domains - Moderately Critical

  • External link injection on 404 pages when linking to the current page - Less Critical

Here you can download the Drupal 6 patch to fix, or a full release ZIP or TAR.GZ.

If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Feb 15 2018
Feb 15

by Elliot Christenson on February 15, 2018 - 7:01am

We're Drupalers who only recently started digging deep into CiviCRM and we're finding some really cool things! This series of videos is meant to share those secrets with other Drupalers, in case they come across a project that could use them. :-)

In the screencast below, I'll demonstrate how to create a publicly accessible CiviCRM "lead" form. This form will add a contact into your CRM database. In this example, I'll be creating a "Corporate Sponsor Lead" type of form. This is the sort of form you might put into a newsletter email or just have easily accessible by volunteers.

Watch the screencast to see if I run into any issues with the instructions:

Video of CiviCRM secrets for Drupalers: Screencast of Roundearth CiviCRM Profile Forms

Some highlights from the video:

  • Create a CiviCRM Profile with a "Corporate Sponsor Lead" Form
  • Create a ACL to allow this Profile Form to be public

Please leave a comment below!

Feb 14 2018
Feb 14

by David Snopek on February 14, 2018 - 4:57pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for the Custom Permissions module to fix an Access Bypass vulnerability.

This module enables the user to set custom permissions per path.

The module doesn't perform sufficient checks on paths with dynamic arguments (like "node/1" or "user/2"), thereby allowing the site administrator to save custom permissions for paths that won't be protected. This could lead to an access bypass vulnerability if the site is relying on the Custom Permissions module to protect those paths.

After applying this patch, go to the "Site Configuration Permissions" page and click "Save". If the form saves without errors, your site isn't vulnerable. If you get an error, delete the permission or correct the patch per the information in the error.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the Custom Permissions module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Feb 07 2018
Feb 07

by David Snopek on February 7, 2018 - 2:23pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for the FileField Sources module to fix an Access Bypass vulnerability.

This module enables you to upload files to fields via several sources.

The module doesn't sufficiently handle access control on the autocomplete for reference sources.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the FileField Sources module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Jan 24 2018
Jan 24

by David Snopek on January 24, 2018 - 1:20pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, a security update for the Backup and Migrate module for Drupal 7 was released for a Critical issue that could allow arbitrary PHP execution - see the security advisory.

While arbitrary PHP execution is scary, this issue is actually about the permissions provided by the Backup and Migrate module not being marked as potentially dangerous. The new release simply marks those permissions appropriately.

There won't be a security release for this issue for Drupal 6!

This is because Drupal 6 doesn't provide a way to mark permissions as dangerous. It doesn't even allow a separate description for the permissions, which we could use to call out the danger (the machine name used in code is the same as the name shown to users - this is no longer the case in Drupal 7 and newer).

However, marking the permissions as dangerous isn't the real fix! The real fix is auditing your permissions to "verify only trusted users are granted permissions defined by the module."

This is something you can do with Drupal 6, even without a new release. :-)

So, in summary: no security release for Drupal 6 - go audit your permissions.

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Jan 17 2018
Jan 17

by David Snopek on January 17, 2018 - 10:21am

One of the great things about Drupal, is that it's possible to build a pretty advanced site just by pointing and clicking and configuring things - what we call "site building" in the Drupal universe.

But with all that power, you can also make your Drupal site less secure - and possible to hack! - just by changing configuration settings! We covered other examples of this in a previous article.

Today we're going to talk about one of the most common... and most DANGEROUS: exposing your Drupal private files on the internet.

In this article we're going to discuss how to determine if your private files have been exposed, and also how to fix it.

Read more to find out!

What are Drupal "private files"?

On all Drupal sites, there are at least two different types of files: public and private.

Public files are served directly by the web server, which is nice because it's fast. Private files have to pass through Drupal, which is slower, but allows Drupal to define the rules to access them.

Private files are usually used for either:

  1. User uploaded content you want to control access to (ex. a newsletter than only site members should be able to see), or
  2. Files created by Drupal modules which they intend to keep private, usually for security reasons

You probably know if you have #1, but you might not know if you have #2 if you don't know how all the modules on your site work.

So, even if you're not using private files to power a feature of your site, a module that you use may be using them unbeknownst to you! Because of that, it's always important to make sure your private files aren't being exposed to the internet.

How does Drupal keep private files private?

Public files have to be placed in your public "web root" along with the other files that make up your Drupal site, so that the web server can serve them.

Private files should either:

  1. Be placed outside the web root, where the web server can't get to them, or
  2. If they are in the web root, you need to configure your webserver not to serve them

#1 will always be safe!

It's #2 where things can go wrong. Frequently, private files are placed within the web root (ex. under "sites/default/files/private") but without changing the web server configuration to prevent directly accessing them, and skipping Drupal altogether.

How to find out if they are exposed?

This is pretty easy to check manually, but does require a little bit of Drupal and technical know how:

  1. Login to your Drupal site as an admin user
  2. Go to Configuration -> Media -> File system
  3. Check the "Private file system path"
  4. If you it might be in the web root, then place a file at the given path (probably will require using FTP or SSH to transfer a file to the live server) and then try to access it with your web browser. For example, if your "Private file system path" is "sites/default/files/private" then upload a "test.txt" file and try to access it at http://example.com/sites/default/files/private/test.txt
  5. If you can access the file directly - then your private files are exposed to the internet!

Since that involves messing around with FTP or SSH, an easier way may be installing the Security Review module and running its report. It'll find exposed private files as well as a number of other potential security issues with your site!

How to fix it?

The safest thing you can do is to move your private files directory outside the web root. If your site is at the top-level of your domain, an easy option can be putting the private files at a directory above the web root.

For example, if you login to Drupal by going to http://example.com/user/login as opposed to some prefix directory like http://example.com/drupal/user/login, then you know that your site is at the top-level of your domain, so there shouldn't be any way to access files in the directory above it.

Here's the process:

  1. Use FTP or SSH to move the private files directory to a "sibling" directory to your Drupal root, for example, called "private"
  2. Login to your Drupal site as an admin user
  3. Go to Configuration -> Media -> File system
  4. Change the "Private file system path" to a path relative to the Drupal root, starting with "..", for example, "../private"
  5. Click "Save configuration"

An alternative to this is changing the configuration of your web server to block access to files in the private files directory, but that can be tricky - it depends on your specific web server (Apache, nginx, IIS) and configuration. So, we're not going to go into that today - that could be the topic for a whole new post. :-)

Conclusion

If you have a Drupal site, you need to make sure that your private files are secure - even if you think you don't have any private data on your site, you could be surprised!

Hopefully, the steps above will be helpful, even for users who aren't very technical. Unfortunately, though, maintaining a website will always be at least a little technical, so you may need to call on an expert!

If you have any questions or feedback or tips, please leave them in the comments below!

Or, if you're interested in paid support: Our whole business is support and maintenance for Drupal sites, so if you need help, please feel free to contact us. Good luck!

Jan 17 2018
Jan 17

by Elliot Christenson on January 17, 2018 - 10:13am

We're Drupalers who only recently started digging deep into CiviCRM and we're finding some really cool things! This series of videos is meant to share those secrets with other Drupalers, in case they come across a project that could use them. :-)

You may recall the blog post that David put out way back in August 2017. He gave some very detailed instructions on how you can install CiviCRM on Drupal 8!

We have some new Drupal versions released since August, and we've had some requests to demonstrate how to go through some of the steps. So, I'm going to do just that!

Every step will be followed quite literally. Note that David assumed this was being installed on a development system running Linux. Since I'm running a Mac, this should be a great cross-platform test.

Watch the screencast to see if I run into any issues with the instructions:

Video of CiviCRM secrets for Drupalers: Screencast of Drupal 8 + CiviCRM Installation

Some highlights from the video:

  • Very quick install of Drupal 8 on a Mac running MAMP
  • Download and installation of CiviCRM
  • Brief comments along the way as I follow the steps
  • Finish with a working Drupal 8 + CiviCRM site!

Please leave a comment below!

Dec 20 2017
Dec 20

by David Snopek on December 20, 2017 - 1:31pm

Today, there was a Highly Critical security advisory for a Remote Code Execution (RCE) vulnerability in the me aliases module for Drupal 7:

me aliases - Highly critical - Arbitrary code execution - SA-CONTRIB-2017-097

This module provides shortcut paths to current user's pages, eg user/me, blog/me, user/me/edit, tracker/me etc.

It was incorrectly handling URL arguments that could allow an attacker to execute arbitrary PHP code.

However, the way the Drupal 6 version of the module handles URL arguments isn't vulnerable in the same way. So, Drupal 6 users can rest easy - your site isn't affected by this issue.

But if you do use it on Drupal 7, given the criticality of this issue, please update right away!

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Dec 14 2017
Dec 14

by Elliot Christenson on December 13, 2017 - 8:14pm

We're Drupalers who only recently started digging deep into CiviCRM and we're finding some really cool things! This series of videos is meant to share those secrets with other Drupalers, in case they come across a project that could use them. :-)

Most Drupalers at one time have had to deal with either sending e-mail newsletters directly from Drupal, or integrating with a 3rd party tool like Mailchimp or Constant Contact.

CiviCRM has built in e-mail newsletter functionality, and if you add to it the WYSIWYG e-mail builder Mosaico you can build really rich, responsive e-mail campaigns!

Watch the video here:

Video of CiviCRM secrets for Drupalers #1: E-mail Campaigns

Some highlights from the video:

  • A sneak peek at Round Earth: our project that bundles Drupal 8 + CiviCRM
  • Drupal 8 + CiviCRM vs. "only" Drupal
  • A quick walk-through on how to quickly and easily create an email campaign
  • Plus, we mention a couple of current "gotchas" that could save you frustration!

Please leave a comment below!

Dec 06 2017
Dec 06

by David Snopek on December 6, 2017 - 2:37pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Critical security release for the Mailhandler module to fix a Remote Code Execution (RCE) vulnerability.

Remote Code Execution vulnerabilities are scary - it basically means that an attacker can run arbitrary code on your site. However, there a number of mitigating factors in this case, so, it's recommended to read the security advisory for Drupal 7.

With the help of the D6LTS vendors, a new version was released for Drupal 6 as well.

You can also download the patch the patch.

If you have a Drupal 6 site using the Mailhandler module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Nov 15 2017
Nov 15

You spend so much time writing secure code, and doing security updates, but you're putting all of that in danger with your wiki. A huge percentage of agencies put passwords into wikis - and other shared resources!!!

Using a shared Google/Office document, spreadsheet - even with black text on a black background - isn't much better! So, think of "wiki" in this context as being any "low-cost, low-security, high-accessibility, super-convenient storage."

You are putting your agency AND your customers at risk by keeping passwords in your company wiki!

Read more to find out why, and a better way to do it!

Wiki Pros & Cons

(From Wikipedia) "A wiki is a website on which users collaboratively modify content and structure directly from the web browser."

If you aren't familiar with wikis in business or organizational use, you certainly are familiar with Wikipedia - and Wikipedia's main detraction: security.

When you quote Wikipedia in an argument, your opponent will likely retort with "Anyone can write anything in Wikipedia." While Wikipedia has millions of users to help mitigate the risk of breaches: they do happen!

That brings me to the first of the "cons":...

Con: Security

Security of your wiki is suspect: it keeps data in plain text, so if there's a security issue in your wiki software, someone could get the data out! Wikis are run using common databases, and the information is almost never encrypted. A wiki makes no distinction between some shareable information like customer service instructions - or private information like passwords.

Users in your organization will likely all have access to this! Even people who have no reason to have access them!

And that's if you do everything else right from a security standpoint!

Con: Access Control

Sometimes Wiki software can allow you to have different permission groups. You may want some users to be able to change things - others to only read.

In most cases, the entire wiki is accessible to everyone who has access.

Again, that's if you do everything else right from an access control standpoint!

Con: Password Hiding

Again, because the passwords are "in the clear", they are likely to be less complex, easily copy/paste strings of letters and numbers. If they are "bad" passwords with little entropy, they are easily memorized by users leaving the organization. If they are complicated, they are vulnerable to copy/paste malware!

Con: Accessibility

What if you have to share a password with a vendor or a client? What if you need to access your passwords from the road? From home? From your mobile device?

Sure, there are VPN's, but that's a complication that can cause other issues with whatever you're doing. Alternatively, you could give the world access to your wiki too, but obviously, that's not a great idea!

Those are all solvable problems, but large organizations have complex needs - and often regulatory needs - while small organizations have smaller budgets. Running your own security infrastructure is tough enough when the stakes are low!

Pro: Free

Hey, there's a reason why these things get started! However, while the software is free, training people in your organization on how to best utilize tools like wikis is certainly not free. Plus, as you'll see below, password managers are low-cost - and sometimes even have free options, depending on your use case!

LastPass Pros/Cons

and 1Password...

We talk about LastPass in this blog post because that's what we use at myDropWizard. We have some passing familiarity with 1Password (which appears to have better team grouping features), but for the most part, everything about LastPass is also true of 1Password.

Password Managers - of which LastPass and 1Password are the most common - take a lot of the work of running your own password security out of your hands. Let's go through the Pros and Cons again. This time for LastPass and similar products.

Pro: Security

LastPass is a web based service that holds your passwords. The passwords are encrypted using vetted security methods using your LastPass password as the encryption key. Because the passwords are encrypted while stored and transmitted, not even LastPass can access your passwords!

More details are available about that from Steve Gibson's awesome analysis on Security Now Episode 256. The goal of a password manager is to be convenient but also secure.

LastPass runs as an app on Android, iOS - and as a browser extension for Mac, Windows, and Linux in Safari, Opera, Chrome, Internet Explorer and Microsoft Edge.

The clear-text passwords never get seen or stored by LastPass or your fellow employees!

That said, LastPass allows you to securely share passwords between accounts. Even that is encrypted properly!. It's simple and secure.

LastPass even offers "2FA" Second Factor Authentication.

Pro: Access Control

The reason these password managers are essential to the workplace is the sharing and access controls. If a password changes, you want to change it across the organization - without calls to your help desk! If an employee leaves, you want to revoke their access - for your protection as well as theirs!

In most cases, the browser extension will simply fill in the password! How is that not better than copying and pasting from a wiki!?

It's really about as good as we can hope to achieve without more standardization in the way passwords are handled across websites!

Pro: Password Hiding

LastPass Enterprise allows shared folders, so you can put your passwords into one of these folders and no single employee has to ever even know the password.

Except in rare circumstances, even copy/paste is not necessary!

Pro: Accessibility

You can go to LastPass.com and logon. You can use the mobile apps. You can use browser extensions. As easy as it can reasonably be expected to be, you have full access to all of your passwords! They handle the security, but you can access it freely from anywhere!

Con: Free

Since I'm talking mostly in the context of an enterprise, LastPass is not free. Neither is 1Password. However, they are low-cost.

1Password is $3.99 per "team member" and LastPass is $48/user/year (at most --- larger organizations get slight discounts). So: $4 per month.

LastPass does have free use for individual users - both in the browser and now even in the mobile app. Obviously some of the "team password sharing" features won't work, but you still get all the security if you are in-charge of your own security or are a sole-proprietor!

What About Chrome Saved Passwords?

What About Apple Keychain?

Firefox?

Chrome is the number one browser. If you log-in on your Google Chrome browser using a Google account, Chrome will allow you to share your passwords anywhere you use Chrome (Windows, Mac, Linux, Android, iOS). However, there isn't good sharing of passwords in place.

If you're saving your own passwords, this is preferable to a paper notebook or a desktop note document on your device.

Similar to the Chrome, Keychain is Apple's secure password vault. It works with Safari and elsewhere in macOS and iOS.

Finally, Firefox also has a similar system for sharing passwords between your Firefox browsers on different devices!

Summary

Use a password manager! You don't like LastPass or 1Password? There are others! A quick search showed a recent article listing some I've never used! The Best Password Managers of 2017. (Spoiler alert: LastPass gets a 5 out of 5 Editor's Choice Rating). Wikipedia has another good list!

One other tool that most password generators offer is a password generator! If you refuse to get an encrypted password manager for yourself or your organization, at the very least use secure passwords!

A good resource for generating passwords is security guru Steve Gibson's GRC's Ultra High Security Password Generator. However, I use LastPass's password generator which allows you to tailor the password generation to follow the (sometimes insane) restrictions put on users for what sort of password they can use.

The bottom line, storing things in a wiki is even worse than writing passwords down in a paper notebook. Anything is an improvement over that, but for at least the past 7 years, I've been using and loving LastPass.

Nov 09 2017
Nov 09

by Elliot Christenson on November 8, 2017 - 11:43pm

You need a website. You need to send an e-mail newsletter. You need to track (potential) volunteers, donors, or customers. You could use Drupal, Mailchimp and HubSpot. Or you could do it all in Drupal.

We've been using the tools above in our own organization, and we continue to use them. Yet, we've been toying with the idea of moving more of our daily usage to a more Drupal based solution. I'll try to outline some of the pros and cons of each approach. I think you'll see for many organizations the Drupal solution could end-up on the winning side of the decision!

The Heavyweight Single Purpose Tools

We've used a number of we based services at myDropWizard to help keep sales, projects, and customer communication on track.

I'll outline just a few that we use that are very popular. that would make for a good comparison with a Drupal solution.

MailChimp

Currently, we use MailChimp for newsletters. I think MailChimp is a champion product with low prices and great features. MailChimp is probably the most used email newsletter platform, so it's strengths are well known.

Pros

  • Deliverability: Email deliverability is huge, and MailChimp has great deliverability results due to their scale and their policies.
  • Simple & Good Looking Emails: MailChimp has templates for the most common types of mailings, and it has great customization tools.
  • Integration: Because it's so popular, there is the ability to interoperate with other software solutions relatively easily.

Cons

  • Contact Management: You have to find a way to import and keep users up-to-date and in-sync with your other records.
  • Integration: Yes, the integrations are there, but you have to determine which ones you need, why, and how to exactly implement them.

HubSpot

HupSpot is one of several popular sales based CRM solutions. It's what we currently use to track clients from initial contact to on-boarding. It's a pretty great product.

Pros

  • Feature-Rich CRM: HubSpot has all sorts of features, support and tracking tools - especially for very sales oriented organizations.
  • Integration: It has good integrations as well, and it's been a decent workflow for us to utilize.

Cons

  • Price: Depending on your required feature-set, it can get expensive fast!
  • Extensibility: You can add additional fields, but if you need deeper data tracking or integrations it will be difficult and/or costly to implement.

I think these are great products, and some of the "pros" or "cons" I would choose would be myDropWizard specific needs. Hopefully my brief "pros & cons" assessment is fair and makes some sense.

Drupal Solution

The Drupal solution we are specifically talking about is our Drupal 8 + CiviCRM project. Marrying the flexible content system of Drupal with the powerful contact management features of CiviCRM is a well-proven concept, and it's quickly becoming a great solution with Drupal 8!

Email

Drupal 8 + CiviCRM have some great email capabilities built-in. Also, they are open source, so new capabilities are being added all the time!

Pros

  • Contact Management: At the very least, the tight integration of the email newsletter system with CiviCRM allows for simpler and more accurate tracking of users.
  • A/B Testing, : With some of the most recent updates to CiviCRM, the creation of good looking emails is even easier than before.
  • Integration: By coupling Drupal 8 + CiviCRM, some integrations are unnecessary - but others are easily done - and all integrations are possible!
  • Ecosystem: There is a ton of assistance available for you. There are books written about both Drupal 8 and CiviCRM. There are conferences for both. There are people who can help you - sometimes for free!

Cons

  • Deliverability: You will need an outside service - like MailChimp's Mandrill or similar - to handle the deliverability.
  • More Complex to Setup: While the communities and our own work are pushing to change this, there are some complexities to getting things configured properly.

CRM

Drupal brings a lot of flexibility to the table for a public facing website, CiviCRM brings powerful, time-tested CRM features.

Pros

  • Community: There are CiviCRM conferences, there are Drupal Conferences, there are agencies that specialize in these products, and there are countless (free) online resources.
  • Feature Rich: CiviCRM handles users, events, reservations, and much more. Drupal handles landing pages, blogs, and much more.
  • Under Constant Development: More features are being added every minute.

Cons

  • Complex: While we're working to change this, the initial configuration of Drupal 8 + CiviCRM can be complicated.
  • Integrations: If you have other integrations you need to make - things that aren't handled by the feature set of Drupal 8 + CiviCRM, integrations can be done - but they can be more difficult or costly.

So, Which Should I Pick?!

If I were a small business or nonprofit with appropriate support available (shameless plug for myDropWizard here), I think the costs and benefits of the Drupal 8 + CiviCRM solution are very compelling.

myDropWizard along with many others are working to improve the "pros" and reduce the "cons" of the Drupal 8 + CiviCRM feature set. What do you think? Please feel free to share your perspective in the comments!

Nov 01 2017
Nov 01

by Elliot Christenson on November 1, 2017 - 3:16pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for the Autologout module to fix a Cross Site Scripting (XSS) vulnerability.

This module provides a site administrator the ability to log users out after a specified time of inactivity.

The module does not sufficiently filter user-supplied text that is shown when logging a user out. This vulnerability is mitigated by the fact that an attacker must have a role with the permission "administer autologout".

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

NOTE: This only affects the Autologout 6.x-4.x branch -- the 6.x-2.x branch (which we also support) isn't vulnerable.

If you have a Drupal 6 site using the Autologout module, we recommend you update immediately.

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Oct 17 2017
Oct 17

In about a month, it'll be 2 years since Drupal 8.0.0 was released. Drupal 8 has come a long way since then, especially with Drupal 8.4.0 released two weeks ago, which is the most feature-packed release yet.

Drupal 8 is the future of Drupal. It's awesome.

However, looking at all the blogs and articles and podcasts in the Drupalsphere, we're sending a message that you should only build new sites on Drupal 8.

The common wisdom is that starting a new project on Drupal 7 is dumb idea.

While I'm sure there's lots of people who are OK with that or even think that's the right message...

I strongly believe that we are hurting the Drupal project by sending that message.

Read more to find out why!

Drupal 8 isn't ready for everyone... and might not be for a while

The root of the problem is that, while Drupal 8 can do so much, it isn't a complete replacement for Drupal 7 yet.

I'm not just talking about features, and what modules are available, and community knowledge/ability, and tooling... Well, actually, I'm talking about all those things together. :-)

What made Drupal 7 (and earlier versions) great, wasn't that core was awesome. In fact, while core was always made of well-written code, it was decidedly UNawesame all on its own.

The magic of Drupal was being able to quickly build an application with loads of features, without needing to write much code.

In fact, with Drupal 7, a site bulider — even one who is incapable of writing code — could create a pretty advanced website (say, a Facebook clone?) just by combining modules (with an FTP client) and clicking their way through the admin screens in Drupal.

In Drupal 8, the bar is currently much higher. Working on a Drupal 8 site today, you'll need to write custom code or help port modules, because the contrib ecosystem is less mature.

But even if all the contrib modules were ported and had stable versions, you're now forced to do things that are good ideas, but previously were totally optional, for example: use composer, maintain a staging site, probably use Git and specialized hosting.

Don't force out the "non-techies"

Should the Drupal community "level up" and learn how to use composer, git, etc? Yeah, that'd be good. :-) But does it really make sense to require that?

Many very successful Drupal users are not developers or even technologists. They're librarians, or volunteers, or scientists, or government employees, etc, who do need the power of Drupal (ie. Wix wouldn't work for them), but don't have the time or incentive to become "real techies."

Traditionally, Drupal democratized the ability to create advanced websites by empowering non-techies.

And they are valuable members of our community! They make many non-code contributions, not the least of which is making sure we create software usable by non-developers. And some do eventually make the leap to being developers, but they probably wouldn't have if the initial bar was too high and they couldn't make the transition gradually.

Let's not force these people out of our community.

There are some issues on Drupal.org looking at ways to eliminate or reduce these barriers. For example, looking at ways for site builders to use composer without having to learn composer. But I don't see those problems being fixed particularly soon.

The software adoption curve

Software goes through a predictable cycle where different groups of people adopt it at different times. At first, it's only picked up by innovators and early adoptors, but eventually it's ready for mainstream usage. A lot happens in the process, and not all of it is related to code or the core product.

Many of the tools and processes that we use day-to-day as Drupalists didn't come from Drupal core, but the ecosystem around it (drush, Features, etc) and shared knowledge and best practices (tens of thousands of hours of experience gained by many different people and groups, and remixed via meetups, Drupalcamps, Drupalcons, blog posts).

Drupal went through this process as it was figuring out what it was, and as the community learned how to build sites with it. I'd say the transition to mainstream happened somewhere between Drupal 4.7 to Drupal 6, and continued to mature with Drupal 7.

While all major Drupal releases up until now made big changes, they were more iterative and much about the way that Drupal worked and how our community used it to build sites remained the same.

Since Drupal 8 is nearly a complete rewrite which shook up much of what we know about developing Drupal sites, I'd argue that Drupal 8 is starting the software adoption curve all over again.

While there are some things that have remained the same, there is a huge amount of new stuff, much of it untested over the long-term. Drupal 8 is ready for innovators and early adoptors, and maybe some people in the middle, but it's not ready for all the same groups of people that can successfully adopt Drupal 7.

We're creating a false choice

By pushing Drupal 8 so hard, we're creating a false choice:

  1. Use Drupal 8 for your new site, or
  2. Wait for when Drupal 8 is capable of supporting you (... and while you're waiting, consider moving to other platforms!)

We do Drupal 6 Long-Term Support, and we've seen many people who loved their Drupal 6 sites move to non-Drupal platforms because they didn't see themselves capable of building a new Drupal 8 site, or paying for someone else to do it, or both.

But Drupal 7 is still awesome and isn't going anywhere any time soon!

Since Drupal 7 is still used by nearly a million or so sites (the majority of Drupal sites) we're going to need to continue to support Drupal 7 for a long time, whether that's in the form of official support from the Drupal project or as a Drupal 7 Long-Term Support effort.

Drupal 6 continues to be with us (via Drupal 6 Long-Term Support) almost 10 years after its initial release!

Honestly, I think Drupal 7 is going to be with us in a real way for another 8-10 years.

So, why not say it's OK to build new sites on Drupal 7?

By not saying it, we're pushing people to other platforms

I mentioned this in the last section, but it's worth reiterating:

When people see Drupal 8 as the only way they should be build new sites, and it doesn't seem to work for them, they begin to consider other platforms.

I really, honestly believe that Drupal 8 will get to a point where it can support the same groups of people (including the non-techies) that Drupal 7 supported.

But to keep those people in our community until we get there, we need to be saying, as a community: "It's OK to build new sites on Drupal 7!"

Ok, I've said my piece. :-)

I'm sure this will be a controversial opinion and that many people will disagree. I look forward to discussing further in the comments below!

Do you agree with my argument? Or think I'm totally wrong? Please leave a comment below!

Oct 11 2017
Oct 11

by David Snopek on October 11, 2017 - 1:37pm

Today, there was a Moderately Critical security advisory for an Access Bypass vulnerability in the netFORUM Authentication module for Drupal 7:

netFORUM Authentication - Moderately critical - Access Bypass - SA-CONTRIB-2017-077

The module was bypassing protections on the Drupal 7 user login form, to deter brute force attempts to login to the site, and so was an Access Bypass vulnerability by making login less secure when using this module.

However, Drupal 6 (including Pressflow 6) don't have these same protections for the user login form, and so, using this module is no less secure than using vanilla Drupal 6. Of course, these protections could be added to this module, and while this would be great security hardening, this doesn't represent a vulnerability - only a weakness which is also present (and widely known) in Drupal 6 core.

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Sep 20 2017
Sep 20

by Elliot Christenson on September 20, 2017 - 1:44pm

All businesses have to track their income and expenses. That's the most fundamental axiom of business. We've all learned to think about this in terms of time or "billable hours" After-all, we track our success based on how many billable hours we either get paid or "save".

Is that working for you perfectly?

WTH is "Micro-Tracking" and Why is it Terrible?

I define "micro-tracking" as the "micro-managing of time and resources". We see a few things wrong with "micro-tracking" - specifically for support - but possibly other business expenses.

Do you bill clients by the minute? Even the hour?

It's almost always a terrible idea to watch the clock for support!

Below I'll attempt to outline a few of the downsides...

Issue 1: Time

The easiest to understand is the EXTRA time cost. For example, if a support task takes 5 minutes to communicate to the support employee, 5 minutes for the support employee to complete, and 10 minutes to document, how much time gets billed to the client? 10 minutes? 15 minutes? 20 minutes? Who decides? How do you decide?

Issue 2: Disputes

Do you like having disagreements with your customers? Do you like having disagreements with your vendors? Over an hour? Over a minute?

Wouldn't it be great to be looking at things from the bigger picture? With a more collaborative and less compative frame of mind? Wouldn't it be great to have your interests completely aligned with your clients?

Issue 3: Accuracy

This is very similar to the above. When we are tracked, it's human nature to round up! If you're caught going "62 in a 55*" , you're likely to say "Officer, respectfully, I think I was going 55!"

Customers round up (or down) - so do vendors. Don't you want to really know what you're spending - and why? Also, wouldn't you like to leave the discretion of time accuracy up to those with expertise? Ultimately, if you spend too much, you can't afford the service. Are you really getting a more accurate picture of your expenses if you "micro-track"?

Issue 4: Quality

Finally, the biggest issue: quality. Do you want to spend a minute putting a bandage on an issue or twenty minutes fixing the issue so it doesn't repeat? In the "micro-tracking" scenario, where everyone is fixated on minimizing work and time for a specific task, the answer is "spend a minute!"

We all know the real answer is to spend the twenty minutes. It's better for the support vendor to focus on the long-term lower amount of time, and it's in everyone's best interest to fix a security vulnerability or critical error rather than a bandage solution!

The How?

So, my title promised "how" you make this change. In general terms, a monthly flat-rate is best! For our Standard plan, myDropWizard promises an unlimited number of Drupal support requests.

Your first reaction is probably "That is crazy! What if someone asks you for 5000 support requests in a month?" The reality, however, is that it's in the best interest of the client and the vendor to not have to watch the clock so closely. Vendors shouldn't be skimping on best-practices and clients shouldn't be apprehensive of asking for help!

It works, but it does need to have some limits. In our example, we are limiting the support to "Drupal  Support and Maintenance". While I think flat-rate can be used much more widely, it is true that some limitations are necessary.

So No Billable Hours? Ever?

To be clear, there is a time and a place for billable hours. Larger projects need some sort of tracking of time and resources. Even myDropWizard tracks time for these largest projects.

We do support for small organizations and large organizations, and we love the fact that our interests are aligned with our clients in terms of time, collaboration and quality! We think you should think about it too!

*That's miles-per-hour for the non-U.S. metric system using world!
Sep 06 2017
Sep 06

by David Snopek on September 6, 2017 - 3:24pm

Today, there were two security advisories posted for modules that have Drupal 6 versions:

Happily, neither issue affects the Drupal 6 version of the modules!

I think this is particularly important for the Critical issue in Clientside Validation. Anyone who uses the Drupal 7 version of that module should update immediately! But, this time, Drupal 6 users can rest easy. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Aug 16 2017
Aug 16

by Elliot Christenson on August 16, 2017 - 1:28pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Critical security release for the Views module to fix an Access Bypass vulnerability.

The Views module enables you to create custom displays of Drupal data.

When creating a View, you have the option to enable the use of AJAX. The Views module does not restrict access to the AJAX endpoint to only Views configured to use AJAX. This is mitigated by having access restrictions on the view.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch for 6.x-2.x or 6.x-3.x.

If you have a Drupal 6 site using the Views module, we recommend you update immediately.

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Aug 16 2017
Aug 16

Migrating your site to Drupal 8 isn't simple or cheap. Nor is maintaining it or getting support once your new Drupal 8 site is live!

This is a problem that affects all organizations using Drupal, but it's particularly hard on smaller nonprofits.

A couple weeks ago, I wrote a super long article detailing how Drupal 8 has left many small nonprofits behind. It also proposes a possible path for fixing it!

We're building an Open Source platform for nonprofit websites built on Drupal 8 and CiviCRM, available as a SaaS with hosting and support included.

That article was primarily about why - in this article I'd like to talk about the details of how!

There's a lot to discuss, but I'll try to make this article shorter. :-)

Oh, and we're looking for 10 adventurous nonprofits to join the BETA and help build it.

If you join the BETA, we'll migrate your existing site to the new Drupal 8 & CiviCRM platform for FREE!

Read more to learn about all the details we've got worked out so far...

WARNING: All is in flux!

In response to our recent articles, we received dozens of comments, emails and submissions to our call for nonprofits to join the BETA. As a result, we've scheduled numerous calls with interested folks and already had about a dozen.

We started this process with a painful problem and a rough sketch of a plan to solve it.

But we want the rest of the plan to be finished in collaboration with the nonprofits in the BETA.

We did this on purpose, because we knew any first draft of any plan would be wrong, and we didn't want to get too attached to it. Too much existing software is a "solution looking for problem" and we want to actually solve problems.

Anyway, all of that to say: whatever I write here is subject to change based on further discussions with real nonprofits and what happens during the BETA.

The BETA process

So, with that said, here's how we envision the BETA process going:

  1. Find 10 adventurous nonprofits to join the BETA
  2. Gather use cases from them to cover the critical features of all sites
  3. Build, migrate and launch each site
  4. Iterate for 12-ish months until we have something solid and generally usable
  5. Launch the first version of the SaaS "self-service plan", ending the BETA period, and moving to general availability

Throughout the BETA and beyond, all of the code for the platform will be Open Source and publicly available, or contributed back to Drupal, CiviCRM or to the other 3rd party libraries and modules used.

So, even folks who don't want to work with us commercially can use the fruits of our labor or contribute on the Open Source side, and there's no "vendor lock-in."

Our main business is support and maintenance, which I think we're pretty awesome at, but I'm biased. ;-) We're going to treat members of the BETA like we treat any support and maintenance customer, as if they were on our "Standard" plan, so, we'll answer support questions and perform an UNLIMITED number of maintenance requests.

We'll do whatever amount of initial training is necessary to get you and your team productive on the platform. (Eventually, we'll have some sort of standard training, but in the beginning we need to figure out what should be included in that!) The training will need to be done virtually.

Feature ideas

Like I said above, we're going to work with the nonprofits in the BETA to decide on the final feature set, but here's roughly what we've got in mind for the first version so far:

  • Selling memberships (where members can login and update their profile)
  • Accepting donations
  • Events (created in CiviCRM but exposed on the Drupal site) with all the usual features from CiviCRM, like: online RSVP, optional fees, event reminders/follow-ups, attendee limits, etc
  • "Page" content type
  • "News" (ie. blog) content type
  • Modern front page that can be edited in-place
  • Clean, modern, mobile-friendly theme that can be re-colored and configured for brand identity
  • Contact page with messages recorded in CiviCRM
  • Volunteer management (via CiviCRM)
  • Mass emailing (via CiviCRM)
  • ...the rest of the default feature set of CiviCRM 4.7+ on the backend. If you're curious why we've chosen CiviCRM and not a pure Drupal solution, check out the article I wrote about CiviCRM last week.

Of course, after launching the first BETA sites on the initial feature set (whatever that ends up being) we'll continue to iterate and expand the feature set based on the needs of the BETA participants.

Pricing ideas (for the future)

Like I decscribed above, we're hoping the BETA process will last about a year.

At the end of that, we're going to make our SaaS platform for nonprofit websites (built on Drupal 8 and CiviCRM) available to anyone (what I'm calling "general availability").

We're imagining two plans:

  • A self-service plan for around $50/mo. You get a Drupal 8 & CiviCRM site, pre-setup with the basic things a nonprofit membership organization needs, and the ability to customize it yourself, with some detailed documentation on how to do so. Hosting is included and you'll get updates automatically as they come out.
  • A full-service plan for around $250/mo. You get the same as above, but additionally full support & maintenance service from our staff, similar to the Standard plan we currently provide for any Drupal site, which includes UNLIMITED requests to answer questions and make simple changes to the site. (Our Standard plan is normally $499/mo, so this is a reduced price for nonprofits.)

And, of course, since the whole platform is Open Source, you'll be able to quit at any time and take an exported version of your site with you, which you could setup in another hosting environment.

The goal is to have something that even small nonprofits could affort (like the ~$50/mo), while still giving them the full power of Drupal 8 and CiviCRM.

But, in order to get there, we need to first do the BETA which will have different pricing...

BETA pricing

Joining the BETA is a little risky (the product could flop!) but we're doing everything we can to mitigate that risk for you, and offer some incentives to make it worthwhile.

One thing we are NOT doing, though, is making the BETA completely free - after re-launching your site on Drupal 8 & CiviCRM, BETA participants will be charged $250/mo.

We feel strongly that charging for the BETA will lead to a better product: we want to make something that provides enough value that it's worth paying for. With money invested, participants are likely to be more engaged in the process and demand the things they need (rather than figuring, "eh, it's free, we can deal with it being crappy.")

However, we think this is a pretty good deal, because:

  • The monthly charges won't start until after your site is migrated and live on Drupal 8 & CiviCRM. You shouldn't have to pay until we're providing your organization with value. We will ask for a down payment on the first month to make sure your organization is serious, but if for some reason we don't re-launch your site on the new platform we're happy to refund that.
  • We'll include the same level of support & maintenance as on our Standard plan. Our main business is support & maintenance of Drupal sites, and our customers (many of whom are nonprofits) find value in our Standard plan for $499/mo - you'll get that same value for half the cost.
  • We'll migrate from your current site and CRM to Drupal 8 & CiviCRM for FREE. While there is a fixed, monthly cost, there isn't any additional charge for doing the migration. Drupal migrations are usually billed hourly and can cost tens thousands of dollars. Even if you don't continue your relationship with us past the end of the BETA, you'll now have a site that's upgraded to Drupal 8!
  • You can quit at any time - there will be NO term minimum. We've debated this internally over the last several weeks. On the one hand, we don't want to force anyone to be our customer. But on the other hand, there's a risk that an organization will join for a month just to get their site migrated and then quit. We've decided to trust the BETA participants to act in good faith. We want participants to stay in the BETA for a year, so, if you know up front that you won't or can't - please don't join the BETA. But if later on it's not working out or something comes up and you have to quit - that's absolutely fine, you can quit at any time and we'll give you a full copy of your site. :-)
  • You'll have a lot of influence over what the product becomes. All of the initial features and the features added over the first year will be based on the needs of the BETA participants.

Of course, we understand that there are plenty of small nonprofits that can't afford $250/mo!

The ultimate goal is to have a lower priced self-service plan (around $50/mo) that smaller organizations can afford. However, we need to go through the BETA process to get there, and while we're investing a lot of our own resources to build this, this is a way to partially share the cost of initial development with our customers.

If your organization can't afford to participate in the BETA, but might be interested after the BETA period is over, please stay in touch!

What makes a good BETA participant?

Certainly, if you're interested, let us know! We're actively changing our plans based on the conversations we're having, and so even if your organization doesn't match our current criteria, we could change our criteria based on talking to you. :-)

In any case, we think that a good BETA candidate is an organization that:

  • Uses a CRM or desperately needs to start using one. CiviCRM will play a big role and so we want to work with organizations that will actively use it and get something out of it. Signs that you desperately need a CRM include using some imperfect and painful system to track your members or constituents (like spreadsheets, Microsoft Access, paper, etc) but you do it anyway because it's important to your operations.
  • Has users (volunteer or staff) with the time to use it and give feedback. Of course, no one has an abundance of time, but we need to actively engage with the BETA participants in order to build a good product. If you spend some amount of time updating your site or doing outreach to constituents on a regular basis (say, weekly or monthly), and are excited about this idea enough to complain when things could be improved, then that's exactly what we're looking for. :-)

If that sounds like your organization, please get in touch!

But if we can't find 10 nonprofits for the BETA, we're not doing it

Basically, we don't want to build something that people don't really want.

If we can't find 10 nonprofits who will take the leap with us... well, either the need must not be that great, or our plan is seriously flawed in some way.

But if there's atleast 10 nonprofits willing to join despite the risks this early, there's probably many more who'd be interested later. And if we build something that works for at least 10 customers AND it's good enough to pay for, well, we probably made something pretty good.

If you're interested, please click the big green button below to...

Join the BETA or get progress updates

We'll be posting more as the project progresses, so please stay tuned!

Think this a great idea? Or, even better - think we got something terribly wrong? Leave a comment below! We're listening :-)

Aug 10 2017
Aug 10

Last week, I published a super long article called Drupal 8 has left small non-profits behind... How can we fix that? which details the many issues Drupal 8 is having and their chilling affect on usage among nonprofit organizations.

It also proposes a possible path for fixing it: building an Open Source platform for nonprofit websites built on Drupal 8 and CiviCRM, available as a SaaS with hosting and support included.

We're looking for 10 nonprofits who are willing to participate in the BETA and help build it (in exchange for a FREE migration to Drupal 8 & CiviCRM).

Next week, we're planning to talk more details about how that BETA process will work!

However, this week, I wanted to take a little break from that, and talk more about CiviCRM in Drupal 8.

So, in this article, we're goning to:

  1. Walk through how to install CiviCRM on Drupal 8. It's quite complicated now, but we're helping to improve that.
  2. Talk about why we're betting on CiviCRM and not a CRM built in Drupal. There's a couple of great, pure Drupal solutions to CRM, like RedHen or CRM Core - but we've chosen to go with CiviCRM. Why?

Read more to find out!

CiviCRM works on Drupal 8!

Contrary to popular belief, CiviCRM mostly just works on Drupal 8 :-)

The CiviCRM team did a push (with the help of some fundraising) to do most of the big work needed. However, there are a couple of small (but very hard) problems remaining around installation. But once you get it installed, you're golden!

The main problematic piece of this is handling composer.

Composer is tool for installing PHP code into applications, like Drupal. It handles the difficult problem of getting all the dependencies (and their dependencies) at a mix of versions that will work together. It's becoming adopted pretty widely in the PHP world, but is still relatively new. Drupal 8 is built on it.

Both Drupal 8 and CiviCRM use Symfony and a couple other shared dependencies. So, the core CiviCRM code needs to be installed into your Drupal 8 site with composer, in order to combine everything together in a way that works. CiviCRM does use composer, but it's pretty early days.

Over the last several weeks, we've been helping to improve CiviCRM's composer support so it could be correctly installed into a Drupal 8.3 or 8.4 site.

Not much of this work has been merged yet, but we have a reproducible set of steps for getting CiviCRM installed that you can use today!

Getting started the easy way

In the next section, we're going to describe the manual process to add CiviCRM to an existing CiviCRM site.

However, if you just want to launch a new site with all the CiviCRM stuff already there, we have a "easy way" for you!

We made a project on GitLab with all the composer stuff already done and the Drupal module included and patched! Here's the process:

  1. Download the ZIP or TAR.BZ2 file (linked version is Drupal 8.3.6 + CiviCRM 4.7.22)
  2. Install just like vanilla Drupal 8
  3. Go to the "Extend" page (at /admin/modules) and install the CiviCRM module
  4. Log out and log back in again per CRM-19878

I don't know how long we'll maintain this specific repo, but I'll try to keep it up-to-date until we have some code publicly available from the BETA of our Drupal 8 & CiviCRM platform which will replace this.

The full, manual process

If you want to add CiviCRM to an existing Drupal 8 site, you'll have to follow the manual process.

Once all these little (but very hard!) problems are fixed, and the fixes are merged into CiviCRM and related libraries, it'll be a single composer command to get CiviCRM added to your existing Drupal 8 site.

However, right now, the manual process is not so easy.

But if you wanted to do it, we have a reproducible process that you can follow!

  1. Download and install Drupal 8.3.6 (or the latest dev of Drupal 8.4.x!)
  2. Go into the root directory in the shell and run these commands to install CiviCRM via composer (one day this will just be composer require civicrm/civicrm-core). Assuming you have composer, bower, git and wget, you should be able to just copy-and-paste those commands into the command-line.
  3. If you use Apache, remove the 'vendor/.htacess' file. This is a security measure from Drupal, which prevents resources like CSS/JS being loaded. This will need some collaboration with the Drupal project to figure out a proper solution for because removing this file altogether is a bad idea on production. See: https://www.drupal.org/node/2896308
  4. Go into the /modules directory and do: git clone https://github.com/dsnopek/civicrm-drupal.git --branch composer-library
  5. Go to the "Extend" page (at /admin/modules) and install the CiviCRM module
  6. Log out and log back in again per CRM-19878
  7. CiviCRM works!

As we've been making progress on the changes for CiviCRM to better support composer, I've been removing commands from the Gist with the special process in step #2, which I plan to continue doing until it's not necessary.

If you have problems (or succeed), I'd really appreciate the feedback!

(And if you post those problems or successes on the PR on GitHub, it'll help move forward the process of committing those changes!)

Why CiviCRM and not RedHen (or other pure Drupal solution)

So, with all that trouble to get CiviCRM working, why even use it?

Drupal is a powerful framework for building awesome things. Why not make some new entity types for CRM-y things like Contacts and Activities, throw some fields on there and make a pure Drupal CRM? There's even some great pre-existing Drupal modules like RedHen and CRM Core to build on.

Drupal can do anything, why not a do a CRM? ;-)

We fell into CiviCRM sort of by accident. A strong plurality of our customers are nonprofits and many of them use CiviCRM, so, we had to start supporting it!

We found that, for many of them, their CiviCRM was actually more important to their daily lives and the operation of their organization than the website.

After spending some time with CiviCRM, we're doubling down on it for our new nonprofit Drupal 8 platform. Here's why...

CiviCRM community is larger than any Drupal CRM module

The CiviCRM community is much smaller than the Drupal community, but much larger than the community around any of the Drupal CRM modules.

The core CiviCRM team is only 4 people, but they work on CiviCRM full-time. (And they don't do CiviCRM installations or paid support or anything like that - they only work on core issues that benefit the whole community.)

There are regional CiviCon's and CiviCamps and monthly meetups - all over the world.

There are multiple books written about CiviCRM.

There are 67 partner/contributor organizations listed on civicrm.org, who provide any number of services: setting up CiviCRM installations, doing trainings, providing support & maintenance, SaaS hosted versions of CiviCRM, etc. And there's probably even more commercial companies out there!

While it would be really cool, I can't really imagine there being four RedHenCon's held in the UK, US, Australia and Germany in a single year, like the 4 CiviCon's scheduled in 2017. :-)

CiviCRM is a complete product

Most Drupal modules are legos, not complete products.

Of course, there are exceptions, but usually you're expected to assemble a set of modules into a thing, rather than a module being a thing.

CRM Core and RedHen are a set of tools in order to build a CRM. They are not complete CRM's on their own.

We could certainly make a CRM as complete as CiviCRM by combining Drupal modules. But none that are out there are quite as complete as CiviCRM, especially, with regard to nonprofits...

CiviCRM is really well suited to nonprofits

The best CRM is one built specifcally to the needs of your organization. For this reason, all CRM's are customizable to some degree, but most CRM's are closer to the needs of certain organizations.

For example, at myDropWizard, we use HubSpot for our CRM. We're a commercial support & maintenance company, so the most useful feature in HubSpot for us is configurable "deal workflows" and seeing all active deals in a workflow-specific kanban board.

We wouldn't be able to use CiviCRM because it's completely missing this feature. But nonprofits don't miss it because their businesses don't depend on deal flow. By the same token, a nonprofit would be missing the pledge, fundraising, grant and volunteer management features that are present in CiviCRM if they tried to use HubSpot.

By focusing only on the needs of nonprofits, CiviCRM has been able to grow into a really killer piece of software for nonprofits.

RedHen and CRM Core are also slanted to towards nonprofits, but seem to leave the door open to being more general, and haven't grown to support as many use cases that are important to nonprofits.

CiviCRM has less "vendor lock-in"

Since Drupal is Open Source, there really isn't true "vendor lock-in" - there are loads of Drupal shops who can help you and you're free to switch.

But we've seen how hard it can be to move from Drupal 6 or 7 to Drupal 8, where people can get stranded in an old version.

The same version of CiviCRM can work in Wordpress, Joomla, Backdrop or Drupal 6, 7 & 8.

If you have a Drupal 6 site using the latest CiviCRM, you can move the core CRM piece to either Wordpress or Drupal 8, basically unchanged. CiviCRM has it's own extension system, which allows the same extension to be used in any supported CMS.

Of course, if you're using Drupal modules that interact with CiviCRM, those would need to be ported just like any Drupal module.

But I think just knowing there is this extra freedom to migrate is good for users who may be concerned about the long-term prospects of Drupal 8.

Join our BETA!

Like I said in the intro we're building an Open Source platform for nonprofit websites built on Drupal 8 and CiviCRM, and looking for nonprofits to be a part of the BETA.

If you're interested, please click the big green button below to...

Join the BETA or get progress updates

We're going to be announcing more details about the BETA next week, but you can read what we're already said about it in last week's article.

Have any experience with CiviCRM? Good or bad? Tried installing it in Drupal 8? Please leave a comment below!

Aug 09 2017
Aug 09

by David Snopek on August 9, 2017 - 12:34pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for the Facebook Like Button module to fix an Cross Site Scripting (XSS) vulnerability.

The module provides a Facebook Like button on node pages and blocks.

The module doesn't sufficiently sanitize certain configuration fields.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the Facebook Like Button module, we recommend you update immediately.

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web