Planet Drupal

Subscribe to flux Planet Drupal
Drupal.org - aggregated feeds in category Planet Drupal
Mis à jour : il y a 5 min 23 sec

DrupalCon News: Share your Drupal Development Knowledge at DrupalCon

jeu, 28/05/2015 - 17:14

Barcelona is one of the most cosmopolitan cities in Europe and we want to infer the same spirit for the Coding and Development track. This is an exciting moment in the web development industry and we plan to take advantage of that. The DrupalCon Barcelona Coding and Development track is focused on preparing developers for the future of the web development universe.

Catégories: Elsewhere

InternetDevels: DrupalTour Rivne

jeu, 28/05/2015 - 16:55

Any morning starting with DrupalTour journey is great ;) Especially if the point of destination is only 70km away. This time we visited Rivne, welcome on board!

We decided to slightly change the concept of the event. It’s much more convenient to communicate with visitors in calm atmosphere of conference halls — we all can concentrate purely on reports and questions.

Read more
Catégories: Elsewhere

Drupal for Government: Step 4 - going the final mile with citizen politics and openspending.org

jeu, 28/05/2015 - 16:52

In the past three posts we've looked at how the Charlottesville Expense Budget might be made more transparent through maps and visualizations.  The final stage in our process is getting the data we've collected added to a larger data set - in this case we're going to use openspending.org as a repository for our work.   This means that even if this site fails (gasp) the work we do will not be lost, and may contribute to a larger and greater good (perhaps a stretch right now, whatev).

Using views data export we can create a CSV file that has all the needed fields for openspending.org - they're a pretty flexible group Amount and Date are the only required fields, we've added Merchant (thanks to the SCC data for that) as well as categories and locations (thanks to John Pfaltz for that).

Catégories: Elsewhere

VM(doh): Drupal cache_form Table Eating Disk Space? Here's a Fix.

jeu, 28/05/2015 - 15:30

A problem we hear about quite often is a huge cache_form table. Drupal by default caches all form data (typically for 6 hours). During peak traffic times, that can be a lot of form data being cached. When the form cache is cleared during Drupal's cron, the following DELETE query is used:

DELETE FROM cache_form WHERE (expire <> 0) AND (expire < UNIX_TIMESTAMP(NOW()));

However, InnoDB does not release disk space back to the file system on DELETE queries, and that can easily lead to a very large .ibd file for that table.

The three most common "fixes" we see being discussed are:

  1. mysqldump - Many people recommend exporting the table via mysqldump and then importing it again. While this does reclaim the disk space, your cache_form table will be locked during the dump and the import, and any users who filled out forms during that small time gap in between the dump and the import will have their form data lost.
  2. OPTIMIZE TABLE (or ALTER TABLE "Engine=InnoDB") - Another recommendation often seen is to run OPTIMIZE TABLE on the cache_form table. However, this will also negatively impact your users by locking the cache_form table during the process. The ALTER TABLE is also mentioned here because it essentially does the same thing on InnoDB.
  3. TRUNCATE - Probably the most common recommendation we see is to simply TRUNCATE the cache_form table. That will instantly free up all of the disk space that table is using, but it will also delete ALL cached form data.

Fortunately, Percona Toolkit contains a great tool to do online schema changes, and it even works if you are running a cluster. We have a client whose cache_form table legitimately grows to ~20GB during peak traffic times, but their site has almost no form usage outside of normal business hours. Running the following as a maintenance task just before the start of the day when there is the least amount of data that legitimately resides in cache_form typically results in a shrinkage down to less than 50MB:

pt-online-schema-change --host 127.0.0.1 --port 3306 --user bender --alter "ENGINE=InnoDB" D=database,t=cache_form --execute

This runs an ALTER TABLE, but with a few extra things going on under the hood. Instead of simply copying the table, it also creates triggers on the original table so that any new data being written to the original table are also written to the new table. When the process is done, it then atomically renames the tables and drops the original.

Catégories: Elsewhere

ThinkShout: DrupalCon LA - A Designer's Perspective

jeu, 28/05/2015 - 15:00

Oh, man. After coming back from DrupalCon Los Angeles with my team at ThinkShout, my brain still hurts... but in a good way. You know, in that same way you feel after binge watching Dr. Who on Netflix leading up to the season finale where The Doctor and Clara… oops. No spoilers. Point being: it’s a feeling of intense brain explosion followed by inspiration and motivation to get up and kick some ass.

Besides attending some fantastic design and UX sessions, I also presented my own session about designing on a budget and led a BoF about design and prototyping in Drupal. I made a lot of awesome new friends and reconnected with some old ones as well.

All in all, it was a great conference and LA was a fantastic host city. My team from ThinkShout and I covered a lot of ground - we found some great bars and restaurants, including my favorite stop, Grand Central Market (where I had an amazing octopus tostada from La Tostaderia).

But anyway, you’re not here to read about bars and restaurants in LA. Let’s talk Design at DrupalCon.

One thing that’s really impressed me about DrupalCon is just how much the breadth of UX and Design content has expanded over the last few years. This was my fourth DrupalCon: my first was 2011 in Chicago, followed by ‘13 in Portland and ‘14 in Austin. I was excited to see there were several sessions in the UX and Design track this year that were less technical, and more about design thinking and problem solving. Personally, I enjoy these kind of talks because I tend to walk away with some new insights into my own process. Design is not the same thing as Front End Development, and DrupalCon is finally realizing and embracing this.

Common Design Themes from DrupalCon LA

Attending DrupalCon is a great way to get your finger on the pulse of what’s happening in the Drupal community. I’ve noticed a lot of changing trends in the years since my first DrupalCon, starting with the prevalence of responsive design. In the first DrupalCon session I gave in Portland in 2013, only about half the room raised their hands when I asked how many had worked on a responsive Drupal site. This year, nearly everyone raised their hand when I asked the same question. At this point, responsive design is implicit when designing a new Drupal site.

Here are some other design and UX trends from this year’s DrupalCon:

  1. People are applying design thinking about much more than how a website looks. Megan Erin Miller, a designer at Stanford University, gave a fantastic talk about using Service Design to design end-to-end experiences. According to Erin, "designing a website is not just about designing good user experience. It’s about designing new processes, new identities, and new partnerships." I couldn’t agree more. Erin compared the process of building a website to designing a theme park. When you go to a theme park, your experience isn’t just about what happens when you ride the roller coaster. A good theme park experience starts when you see an ad on TV or get an email offer and book your trip online or over the phone. When you get to the theme park, your whole experience is planned and designed, from the moment you walk in the gate, to when you queue up in line for the roller coaster, and on to dining and buying souvenirs. As designers, we should be thinking of our websites as products and how our users interact with these products from all possible channels, and not just what browser they’re using on what device. I’m always looking for new perspectives for my personal design process, and I hope to use some service design techniques in my client work.

  2. Components, components, and more components! Just as the topic of "responsive design" dominated DrupalCon’s design sessions in years past, this year’s hot topic was component-based design. As websites and web apps get more complex and responsive, design needs to be streamlined and simplified. One way we can do that is to design modularly. Gone are the days of creating unique layouts for every page on a website (phew!). Instead, we need to be creating design systems that can be applied efficiently across the entire responsive website. Two great component-based design sessions from DrupalCon LA were, “The New Design Workflow,” and “To The Pattern Lab!” In addition to these sessions, I also attended a very informative BoF about CSS Style Guides lead by the one and only John Albin Wilkins. At ThinkShout, we already take a component-based approach to design, but I certainly learned some great new ideas and techniques!

  3. Longform Storytelling is the new black. As Drupal shifts its focus towards publishing and news, content creators are embracing rich longform articles and stories. According to Kristina Bjoran and Courtney Clark of Forum One, "People generally learn more and remember more when more of their senses are engaged by a story. Stories that include images get about twice the engagement as text-only stories. Stories told with visual elements are instantly captivating. The more senses that are engaged, the more emotions will be engaged and the more memorable the experience will be." We are including longform content features in many of our new client’s websites at ThinkShout, and it was really great to hear how other industry leaders do it successfully as well.

Design, Drupal, and the Future

Each year, the Drupal Association puts more thought into diversifying the session lineup, and it shows. There was a very conscious effort to get more design and UX content, as well as speakers from diverse experiences and backgrounds. To that, I say "Huzzah!" As someone who’s been designing Drupal sites for many years now, it’s great to see the design process being treated as more than just “making it look pretty.” Design and UX is now a core component of DrupalCon, and I’m proud to have helped along the way.

After a week of learning and sharing new ideas, meeting amazing people, and eating some darn good Mexican food, my brain is full and my heart is heavy. I can’t wait to see you all next year!

Catégories: Elsewhere

Annertech: 10 Top Drupal Modules to help increase SEO

jeu, 28/05/2015 - 14:04
10 Top Drupal Modules to help increase SEO "We want to rank number one on Google" - every client ever.
Catégories: Elsewhere

Zivtech: 6 Reasons Why Clutch is Awesome

jeu, 28/05/2015 - 13:00

It’s a challenge to locate a service provider who truly meets your business and procurement objectives. This can be especially challenging in the Drupal, & broader Open Source Software, ecosystems, where anybody can label themselves "experts." That’s the conundrum Clutch solves. By gathering user reviews and ratings, Clutch offers clarity for B2B companies looking for digital providers that run the gamut from development to marketing.

So what’s in it for providers? Clutch is a powerful marketing tool. When you sign up with Clutch, the company contacts your current and former clients and elicits feedback on parameters like quality, cost and timeliness. And they ask that big important Net Promoter Score question: would you refer the company to colleagues?

Over the past few months Zivtech has been getting excellent user reviews on Clutch, and as the feedback flows in, we've become big fans. Why we heart Clutch:

  1. It's hard to ask for public reviews. Who wants to appear desperate? That’s not a good look for individuals or businesses. But user reviews provide valuable social proof and make a huge difference when converting prospects to customers. Clutch gets reviews on your behalf.
  2. Reviewers don’t have to identify themselves. Some clients are uncomfortable using their names and company identifiers in public endorsements. Clutch gives reviewers the option to post anonymously, so there’s no risk to the client. The unbranded review still provides insight into client’s industry and company size.
  3. Clutch: your crystal ball. Clutch gives you insight on what your future relationship will look like. Prospective clients and partners get a good view on what it might be like to work together.
  4. Powerful branding tool. Clutch gives you great ideas for how to view and recalibrate your value proposition. You know what you do best, but how do you communicate your strengths to potential customers?
  5. Free promotion. Clutch promotes your brand and the positive reviews you get, and it’s a lot more powerful than paid ads. Social proof is one of the most powerful tools available to marketers.
  6. More Feedback=More Clients. Clutch regularly asks your permission to gather consistent feedback from your clients. The more feedback you get, the higher you rank, and that high rating looks good when your prospects come looking.

When potential clients can read verified feedback and reviews from current and former customers, they have decision-making confidence. That means increased sales for your business, because social proof creates trust. And that’s an ideal first step.

Don't forget to check out our clutch.co page.

Terms: Drupal Planetclutchsocial proofmarketingclient feedback
Catégories: Elsewhere

Jim Birch: Essential Drupal: The Style Guide Module

jeu, 28/05/2015 - 13:00

Site builders and front end themers rejoice at the greatness of the Drupal Style Guide module.  This module creates a page on your Drupal 6 or Drupal 7 site, displaying all the common html elements, and how your theme displays them.  It is a fantastic tool to work with your designer and client to show them the applied styles of your theme, and great for the themer to make sure you hit all the elements.

Hooking into the module is easy too.  If you have elements that you need to add, whether it be in a custom module or part of your theme, you can easily add more using hook_styleguide_alter().  You can also use the sub-module, Style guide palette to add colors to the style guide.  There is singular permission for whom can add those colors.

The only permission for Style Guide is to View theme style guides.  I've made this site's available to anonymous users, feel free to check it out at http://jimbir.ch/admin/appearance/styleguide

Read more

Catégories: Elsewhere

Drupal CMS Guides at Daymuse Studios: Utilizing the Power of the Play Button with Drupal

jeu, 28/05/2015 - 04:46

I'll show you how to add media overlays or watermarks with Drupal's ImageCache Actions module to create a call to action on image previews in this tutorial.

Catégories: Elsewhere

Drupal Easy: Drupal Career Online Students Getting Ready to Graduate

mer, 27/05/2015 - 22:48

In just a few short weeks, the latest class of DrupalEasy career training students will complete their course work and will be ready for an opportunity to prove themselves through internships, entry- or junior-level Drupal development positions! If your organization is looking to build its talent pipeline, this is your opportunity to bring on a highly-trained individual with the passion and desire for building Drupal sites.

We’ve set up a program to match graduate skills with potential employer needs with our Work Experience (WE) Drupal program, and it is once again open for new host applicants. WE Drupal hosts are under no obligation by applying - we're just looking for some information on what type of person you're looking for (developer, site-builder, front-end, QA, PM, etc…) and an idea of the types of projects you have in mind for the graduate. We'll share all of the student profiles with you, and share your information with our students.

-->

read more

Catégories: Elsewhere

LevelTen Interactive: DrupalCon LA 2015: Roundtable Interviews

mer, 27/05/2015 - 22:33

A few weeks ago, the team was in Los Angeles for DrupalCon 2015. Our very own Kyle Taylor took his iPad and mic and interviewed developers, freelancers, and some of the top Drupal Agencies that attend the week long event. ... Read more

Catégories: Elsewhere

Lullabot: Making The Most Of Mobilegeddon

mer, 27/05/2015 - 22:30

On April 21, 2015, Google rolled out a set of changes to its search algorithm so sweeping it dubbed them "Mobilegeddon." Together, these updates dramatically boosted the impact of a site’s "mobile-friendliness" on its search rankings. Google says the changes will have "significant impact in our search results", though at least for now it only affects search results on mobile devices.

Catégories: Elsewhere

DrupalCon News: The Content Strategy Track: the Content Management System meets its purpose!

mer, 27/05/2015 - 20:08

This year, DrupalCon Europe will include a dedicated track on Content Strategy. Let me explain why this is exciting news and a unique opportunity!

Content Strategy has been around for several years now. It defines how we create, manage and maintain quality content that is used to obtain our project goals or answer user needs.

If you’re reading this, you are likely very familiar with Drupal as the leading professional Content Management System and framework.

Catégories: Elsewhere

OpenConcept: Best practices for generating patches and interdiffs

mer, 27/05/2015 - 17:27

I've often been asked how I generate both patches and interdiffs at the same time, because the instructions on drupal.org currently detail the two processes separately, and different documentation pages give different instructions.

So, I thought I'd share the process that works for me, providing real-world examples from an issue that I've worked on.

If you find a better process, please blog about it and post a link in the comments!

This tutorial assumes that:

  • You know what patchfiles are,
  • You know how to use the command-line (the instructions should work in both *NIX and Windows), and,
  • You have a beginner-level knowledge about Git.
High-level workflow overview

My patching workflow works roughly like this:

  1. Before you make a patch, make an issue to post it to.
  2. Make your patch in an environment that makes as few assumptions as possible. I use a fresh Drupal site installed with the Minimal install profile, and I only install the bare minimum set of modules that I need to make the module I want to patch work.
  3. To make the first patch in an issue:
    1. Before making any changes, make a new branch named after the NID of the issue and the comment number you intend to post the patch to.
    2. Make your changes and commit them to the new branch. If you make more than one commit, squash them down to a single commit when you feel that you're ready to post the patch.
    3. Generate a patchfile with git format-patch — this will add extra metadata to help Git and other humans in the future.
  4. If there are already patches in the issue, and the most-recent patch no longer applies, re-roll the old patch first and upload it, then make your changes in a separate patch.
  5. If there are already patches in the issue:
    1. Download the most-recent patch and commit its changes to a branch named after the NID of the issue and the comment number that you got the patchfile from.
      • If it no longer applies, re-roll and upload it first, then make your changes in a separate patch.
    2. Checkout the starting branch again.
    3. Make a new branch named after the NID of the issue and the comment number you intend to post the patch to.
    4. Apply the most-recent patch to the new branch but don't commit it yet.
    5. Make your changes in the new branch and commit them to the new branch. If you make more than one commit, squash them down to a single commit when you feel that you're ready to post the patch.
    6. Generate a patchfile with git format-patch — this will add extra metadata to help Git and other humans in the future.
    7. Generate an interdiff by git diff-ing against the branch from step 5a.

... if none of this makes sense yet, don't worry: I'll explain it below. Hopefully once you've run through it a couple of times, you can use this high-level overview as a reference.

Detailed workflow 1. Making a new issue

Before you make a patch, you should have an issue to post it to.

  1. Create a ticket on Drupal.org, and propose your changes.
    • Use the Issue summary template.
      • If you're reporting a bug, add a section with Steps to Reproduce the bug. This will help module maintainers see the need for your patch!
      • Especially for bug reports, it's helpful to compare what the module does now with what you want it to do. This also helps module maintainers see the problem.
    • Good metadata is important! I usually need to spend a bit of time finding a succinct Title, choosing the most-appropriate Category and Component, re-reading the guidelines for setting a Priority, and choosing good issue tags.
      • Since this is a new issue, and you haven't attached a patch yet, leave the issue status set to Active.
      • If you intend to provide a patch right away, you may assign the issue to yourself.
    • Take note of the node ID in the URL of the issue (e.g.: for https://www.drupal.org/node/2290031 the Node ID is 2290031) — you'll need it when patching.
2. Set up your environment for patching

Accidentally making assumptions about the Drupal site you're working on increases the risk that your patch will break other people's work, won't get accepted, will take a long time to be accepted, or will be rolled back later on. So, it's important to write your patch on an environment that makes as few assumptions as possible.

In some cases, trying to reproduce a problem (or adding a feature) in a clean environment will also help you to identify future problems, or see a solution that doesn't require patching.

  1. Set up a fresh Drupal site to write your patch on.
    • Use the Minimal install profile.
  2. Enable only the bare minimum set of modules that you need to make the module you want to patch work (e.g.: the Facet API module requires ctools and a search module, like core's search).
  3. Clone the module you want to patch (e.g.: git clone --branch 7.x-1.x http://git.drupal.org/project/facetapi.git).
    • You can copy and paste the Git command from the project page's Version control tab (e.g.: https://www.drupal.org/project/facetapi/git-instructions).
    • Take note of the branch you start from.
3. Making the first patch in an issue

The first patch to an issue does not need an interdiff.txt, but generating your first patch as follows makes generating interdiffs easier in the future.

  1. From the starting branch, create a new branch named after the Node ID of the issue and the comment number you intend to post it to (e.g.: 2290031-3 — git checkout -b 2290031-3).
    • The Node ID is in the URL of the issue (e.g.: for https://www.drupal.org/node/2290031 the Node ID is 2290031).
    • Note that if you're logged into Drupal.org, the "Add comment" section title shows the next comment number (e.g. Add comment #10).
  2. Make your changes in this branch, add them, and commit them.
    • If you make more than one commit, you'll need to squash it down to a single commit using git-rebase.
    • The commit message you enter here will be seen by others, but it will not be used as the final commit message. I simply enter the name of the branch (e.g.: git commit -m "2290031-3").
  3. Run git format-patch $starting_branch (e.g.: git format-patch 7.x-1.x).
    • This generates a patch file and places it in the repository.
    • Alternately, you could generate a patch with git diff $starting_branch, but I like git-format-patch better because it adds a bit of metadata that will help Git to apply your patch without someone having to re-roll it as often.
  4. Move the patch file out of the git repository to prevent you accidentally committing it later.
    • This is a good time to rename your patch.
    • Note that if you use Dreditor, you can use it to generate a patch name for you by clicking the Patchname suggestion button in the Files fieldset.
  5. Check out the starting branch, to prevent you from accidentally branching off it later.
  6. Upload the patch to the issue.
    • Don't forget to un-assign the issue! Many maintainers ignore assigned issues, regardless of what the issue's Status is, because they assume assigned issues have someone actively working on it right now.
    • Don't forget to set the Status to Needs review. This helps others to know there's a patch attached and that patch is ready for someone else to look at.
4. Re-rolling a patch

If the maintainer(s) have been making a lot of commits to the starting branch, git(1) or patch(1) may not be able to figure out how to apply the patch file any longer. If this happens, the patch will need to be rerolled.

If you're making a subsequent patch to an issue, and the previous patch doesn't apply, re-roll the patch first, then make your changes in a separate patch. Doing so makes it easier for both you to generate interdiffs; and it makes it easier for the maintainer(s) (and anyone else following the issue) to understand what's going on.

  1. Make sure your repository is up-to-date (git pull).
  2. Download the most-recent patch.
  3. Double-check whether it is necessary to re-roll the patch (git apply --check /path/to/most-recent.patch).
    • If you see nothing, then the patch does not need to be re-rolled and you can skip this section entirely.
    • If you see error: patch failed, then you will need to re-roll the patch.
  4. Find when the most-recent patch was made.
    • If the most-recent patch was made with git-format-patch, the first line of the patchfile (From $commit_id $date) will tell you everything you need to know. Take note of the commit ID and jump down to step 6.
    • If the commit ID or date is not available in the patchfile, you can get a rough guess by looking at the date-stamp on the comment that the most-recent patch was uploaded in will work instead.
      • Sometimes Drupal.org displays the time since the comment was posted (e.g.: "yesterday"). Double-click to change to an exact date.
    • Take note of how to write the date in ISO 8601 format (yyyy-mm-dd, e.g.: 2014-06-20).
  5. Search git log to find a commit from that day or earlier (git log --before=$iso_8601_date e.g.: git log --before=2014-06-20).
    • Take note of the commit ID (e.g.: 9e26034949aac609bb8537ef5a189033a3665baa).
  6. Check out the commit ID (e.g.: git checkout 9e26034949aac609bb8537ef5a189033a3665baa).
    • Git will tell you that You are in 'detached HEAD' state. This is okay.
  7. Create a new branch named after the Node ID of the issue and the comment number you intend to post it to (e.g.: 2290031-6 — git checkout -b 2290031-6).
  8. Apply the patch (git apply --index /path/to/most-recent.patch e.g.: git apply --index make_inactive_active-2290031-4.patch).
  9. Commit the patch.
    • The commit message you enter here will be seen by others, but it will not be used as the final commit message. I simply enter the name of the branch (e.g.: git commit -m "2290031-6").
  10. Rebase the branch onto the most-recent commit of the starting branch: git rebase --onto $starting_branch (e.g.: git rebase --onto 7.x-1.x).
    • You might get merge conflicts. If you do, fix them, taking notes on what you did, and follow Git's instructions for finishing the rebase.
    • In rare cases, if you get merge conflicts, it's because the maintainer(s) significantly changed how the code works. If this is the case, you might have to about the rebase and start the patch fresh (see 3. Making the first patch in an issue). Make sure to very clearly state in the comment where you post the patch that you tried re-rolling but the code had changed too much and you were forced to start from scratch.
  11. If and only if the rebase completed successfully, run git format-patch $starting_branch (e.g.: git format-patch 7.x-1.x).
    • This generates a patch file and places it in the repository.
    • Alternately, you could generate a patch with git diff $starting_branch, but I like git-format-patch better because it adds a bit of metadata that will help Git to apply your patch without someone having to re-roll it as often.
  12. Move the patch file out of the git repository to prevent you accidentally committing it later.
    • This is a good time to rename your patch.
    • Note that if you use Dreditor, you can use it to generate a patch name for you by clicking the Patchname suggestion button in the Files fieldset.
  13. Check out the starting branch, to prevent you from accidentally branching off it later (git checkout $starting_branch, e.g.: git checkout 7.x-1.x).
  14. Upload the patch to the issue.
    • Don't forget to un-assign the issue! Many maintainers ignore assigned issues, regardless of what the issue's Status is, because they assume assigned issues have someone actively working on it right now.
    • Don't forget to set the Status to Needs review. This helps others to know there's a patch attached and that patch is ready for someone else to look at.
    • Make sure you very clearly state that you are just re-rolling and there are no changes (or, if you got merge conflicts, state how you resolved them and why).
5. Making a subsequent patch in an issue

If there's already a patch in an issue, and you want to change it, you will need to generate an interdiff to help the maintainer(s) understand what you're changing.

  1. Make sure your repository is up-to-date (git pull).
  2. Download the most-recent patch.
  3. Create a new branch named after the Node ID of the issue and the comment number of the most-recent patch (e.g.: 2290031-6 — git checkout -b 2290031-6).
    • If you generated the last patch and the branch is still in your repository, you can skip down to step 7.
  4. Apply the patch (git apply --index /path/to/most-recent.patch e.g.: git apply --index make_inactive_active-2290031-6.patch).
  5. Commit the patch.
    • I simply enter the name of the branch (e.g.: git commit -m "2290031-6").
  6. Checkout the starting branch (git checkout $starting_branch, e.g.: git checkout 7.x-1.x).
  7. Create a new branch named after the Node ID of the issue and the comment number you intend to post it to (e.g.: 2290031-7 — git checkout -b 2290031-7).
  8. Apply the patch again (git apply --index /path/to/most-recent.patch e.g.: git apply --index make_inactive_active-2290031-6.patch).
    • If you want to take the patch in an entirely new direction, you can skip this step, but you should have a really good reason for throwing away other people's work (which they might have volunteered), and you should very clearly state those reasons in the comment you post in step 15. Make sure you follow the Drupal Code of Conduct.
  9. Make your changes in this branch, add them, and commit them.
    • If you make more than one commit, you'll need to squash it down to a single commit using git-rebase.
    • The commit message you enter here will be seen by others, but it will not be used as the final commit message. I simply enter the name of the branch (e.g.: git commit -m "2290031-7").
  10. Run git format-patch $starting_branch (e.g.: git format-patch 7.x-1.x).
    • This generates a patch file and places it in the repository.
    • Alternately, you could generate a patch with git diff $starting_branch, but I like git-format-patch better because it adds a bit of metadata that will help Git to apply your patch without someone having to re-roll it as often.
  11. Move the patch file out of the git repository to prevent you accidentally committing it later.
    • This is a good time to rename your patch.
    • Note that if you use Dreditor, you can use it to generate a patch name for you by clicking the Patchname suggestion button in the Files fieldset.
  12. Generate an interdiff (git diff $previous_patch_branch > interdiff.txt e.g.: git diff 2290031-6).
  13. Move the interdiff out of the git repository to prevent you accidentally committing it later.
    • Interdiffs are usually just named interdiff.txt, regardless of what issue number or comments they relate to, so take careful note of where you move it to so that you don't confuse it with another interdiff later.
  14. Check out the starting branch, to prevent you from accidentally branching off it later (git checkout $starting_branch, e.g.: git checkout 7.x-1.x).
  15. Upload both the patch and the interdiff to the issue.
    • Don't forget to un-assign the issue! Many maintainers ignore assigned issues, regardless of what the issue's Status is, because they assume assigned issues have someone actively working on it right now.
    • Don't forget to set the Status to Needs review. This helps others to know there's a patch attached and that patch is ready for someone else to look at.
    • Make sure you upload the correct interdiff! Interdiffs are usually just named interdiff.txt, regardless of what issue number or comments they relate to, so make sure you upload the right one!
  16. Delete the interdiff.txt so you don't get confused and upload an old interdiff later.
Conclusion

I'm posting this in the hopes that it will help others in the future. If you have questions, ask them in the comments and I'll try to answer them and update the blog post with corrections, so you can refer to this post in the future without digging through the comments as well.

Topic: 
Catégories: Elsewhere

Chromatic: Testing Recurly Webhooks with ngrok

mer, 27/05/2015 - 16:31

In our last post about Recurly, we gave you a primer on setting up the Recurly module in Drupal. However, if you need to thoroughly test your Recurly integration on a local environment, you’ll want to test the webhooks as well. Webhooks in Recurly are interchangeably called "push notifications." From the Recurly documentation:

Recurly can send webhooks to any publicly accessible server. When an event in Recurly triggers a webhook (e.g., an account is opened), Recurly will attempt to send this notification to the endpoint you specify.

We’ve used a service called ngrok to help set this up. Ngrok is a service which allows you to create secure tunnels to your localhost.

You’ll need:

Setting up ngrok
  1. Create an ngrok account: https://ngrok.com/

  2. Download ngrok: you can download and extract it (https://ngrok.com/download) or use a package manager. On Mac OSX, brew cask install ngrok worked for me. This installed it into my applications folder, so I could just use ngrok as the command instead of ./ngrok. See this post for details on brew cask.

  3. Once you can run it per the instructions on the download page, you’ll need to do a one-time setup with your auth token. Here’s where we do things a little differently. We need ngrok to receive our webhooks from Recurly.

  4. Start the ngrok public tunnel with HTTP AUTH and Host header rewrite set to your local development instance name:

./ngrok http -host-header=yourlocalinstance.dev -auth="username:password" -subdomain=your-recurly-subdomain 80

a. yourlocalinstance.dev is the path to your local instance.

b. the username:password is made up by you to authenticate webhooks.

c. your-recurly-subdomain is easiest to find in the address bar when logged into Recurly, you also need this to set up the Recurly module.

  1. You should now see something like this in your shell:
Setting up Drupal
  1. Now we need to get the Drupal side of Recurly set up to receive the webhook notifications. Go to config/services/recurly in your local instance.

  2. Under "Push Notification Settings," you’ll see the Listener URL key. It’ll be something like yourlocalinstance.dev/recurly/listener/USD. Take note of this if you change it from this default.

Connecting ngrok to Recurly
  1. Now that we have ngrok set up, we need to set up the Recurly side to send the webhook notifications to the right place. Log into Recurly, and head to Developer>Webhooks on the left hand side, or configuration/notifications/configure.

  2. Your Webhook URL should be the url you generated in your shell with the ngrok command, with the Listener URL Key you noted in your Drupal settings appended to it.

  3. The HTTP username and password are the username:password combination you used to start ngrok.

You should be all set up now. All webhooks will be sent to Webhook URL, which is using ngrok. ngrok is forwarding those requests to your local instance. Go ahead and make a change to a user’s subscription (or somewhere else you’re using Recurly’s webhooks) and take a look. You should see the requests coming through your shell:

And you can also inspect them in your browser at http://localhost:4040/inspect/http:

That’s it! While ngrok is running, your local instance and Recurly can now communicate through webhooks, so you can test everything as though it were on your production server.

Catégories: Elsewhere

ThinkShout: Committing to D8 Core - A Little Bit Goes a Long Way

mer, 27/05/2015 - 16:00

It was the last day of DrupalCon LA and after a long week of sessions, getting to know fellow Drupalistas, and partying until the wee hours, I mustered what little brainpower I had left and made my way to the "First Timer’s Sprint." Joined by my ThinkShout colleagues, Joe and Nancy, we arrived with beautiful visions of giving back to our community by contributing in some capacity to Drupal 8 core. And so it begins…

We arrived just in time to set our development environment up with a couple hundred other hopeful contributors, and were pleasantly surprised by how quickly that process went and how helpful the mentors were. As soon as we were all set up, the conference staff sent us on our merry way into the next room.

As you may or may not know, Drupal core is enormous! It can be a big, daunting pile of directories and folders that can go down several levels. For a newer developer (and even more seasoned ones, I hear) it takes a great deal of time to navigate this powerful platform. As a result, I was faced with too many possible issues to work on and very little background for how the contributing process works. I’m willing to bet most engineers have been in a similar situation at one time or another and can likely relate. This experience has a name - it’s called "decision fatigue," where one is faced with so many possibilities to choose from that they become overwhelmed and may even check out entirely. I was there.

Having recognized this feeling before, I piped up and explained to our mentor that we would work more effectively if we were given a single focus or direction. This seemed to work well, and he provided us with a handful of suggestions. That was all fine and good, but after looking at the "Novice" queue, I felt my deer-in-headlights gaze only worsen. Still hungry for a way to gain some practical experience, I reflected back on the options our mentor suggested. He mentioned that “rerolls are easy,” and that seemed like a good place for me to start.

Seizing the moment, I nabbed the nearest mentor and asked him if he could spare a few minutes to help walk me through a reroll. Fortunately, he had a moment to spare, and pointed me to the documentation. Interestingly, this mentor happened to identify with me as a site-builder with little coding experience, yet he was knowledgeable and knew enough Git tricks to be an active participant in the Drupal issue queues.

With this mentor by my side, we dove into the oldest D8 "needs reroll" issue and went to town. Much to my surprise, this issue didn’t take long, but it also helped that another contributor had already rerolled the patch. No problem! I made a comment stating that the patch had been rerolled, how old the issue was (seven years, in this case), and removed the “needs reroll” tag from the issue. Though it felt like a negligible change, my mentor reassured me that I’d spared another developer from having to go through the same process and reach the same conclusion. Consequently, the issue had moved on to a more progressive state, and there was much rejoicing.

After that was said and done, I went back to the issue queue feeling a tad more confident. Just moments later, our original mentor rushed excitedly back to our table. "Who wants to commit to core?" he asked. We all looked around at each other, not quite sure what to make of it, and responded with a cautiously optimistic “sure, we can help!"

Everything happened rather quickly, which was surprising considering how long it takes to get an average issue through the complete process. Here’s how it went down: There was an issue. A dev in another sprinting room was asked to write a patch. Another dev revised the patch by improving it slightly, and it was then passed to our table to go through the review process. A dev evaluation was put forth, then the issue was passed back for additional review. Finally, it was submitted to be pushed into core.

This was my first DrupalCon and, little did I know, they have a very important tradition - every DrupalCon sprint ends with a live commit by Dries, the founder of Drupal. Our team was lucky enough to be part of this ritual! So, after a full week of delightful Drupal-related shenanigans, I found myself on stage pressing the enter key on Dries’ computer to push our commit to D8 core. The button was pushed and the explosion of celebration and cheers from the audience was nearly deafening.

In this moment, I truly witnessed the heart of the Drupal community in action - this amazing tool could not exist without a number of developers carefully crafting code in accordance with Drupal best practices, and countless generous individuals attentively reviewing the proposed changes. It really does take a village, and the good news is that it doesn’t require being a coding genius to help out.

Catégories: Elsewhere

Wellnet Blog: Drupal Weekly Module Review - #12 Honeypot

mer, 27/05/2015 - 15:07

Welcome back on Drupal Weekly Module Review, the weekly column where we find out and learn how to use the most interesting modules we find on drupal.org.

This week I’d like to introduce you a module inserted on the Must Have article, in other words Honeypot...

Catégories: Elsewhere

CiviCRM Blog: Give CiviCRM on Drupal 8 a test out

mer, 27/05/2015 - 11:17

Thanks to generous contributions from Fuzion and Beat Schnyder from basx GmbH, I was able to put in a few days work over the last month into the Drupal 8 integration module, allowing Drupal 8 and CiviCRM to interoperate.

I had done a large chunk of work of the initial work for this during Google Summer of Code last year but as Drupal 8 has been under heavy development, so much had changed that the module needed to be carefully picked over to bring back into a working state. Over the several days of funding I had, I managed to get both the module and install working against the latest Drupal 8 beta (at the time, beta-9 but now 10 too) and Civicrm 4.6.3 in time for the Denver CiviCon sprint.

You can check out the current state of things (along with all the bugs and so on) here: https://drupal8.fudev.co.nz/ (login: demo password: demo). If you would like to explore deeper, such as testing how it works with Views, and later on with other Drupal goodies that aren't yet available in D8, then just ask us for a user account with more permissions. Fuzion is asking for contributions to help support this work - they are encouraged but not compulsory. Funds will go towards Drupal 8 support.

Any bugs you come across, please feel welcome to open an issue on JIRA and assign to me (Torrance).

For the adventurous at heart, I’ve documented the installation procedure, so you can have a go at installing a local copy to play with (and I will update this if it's not clear enough or there are issues in the process).

There’s still plenty of work to do, but the more eyes looking, the shallower the bugs. :)

 
Catégories: Elsewhere

Hook 42: DrupalCon LA - A Few of Our Favorite Things

mer, 27/05/2015 - 07:38

DrupalCon is a wonderful experience (even if it's in downtown LA!). We come together as a community to learn and share and have a fun time. The Hook 42 team grew a bit from last year and was fortunate to have 8 team members in LA. We had a great time and wanted to share some of our highlights with you.

drupalcon_la_great_view_from_airbnb_roof.jpg

Downtown LA from rooftop. Photo credit: Kristen Pol.

Session/BoF/Sprints

As usual, there were tons of great keynotes, sessions, BoFs, and sprints. The keynotes and sessions were recorded so check those out.

drupalcon_la_dries_qa_laughing.jpg

Having fun at the Dries Q&A. Photo credit: Paul Johnson.

Aimee's Favorite Session/BoF

So many… but basically all things Drupal 8. :) Schnitzel’s application of Drupal 8 in production, Matt Cheney’s review of the D8 CMI in a managed workflow was informative and thought provoking, and of course MortenDK’s Drupal 8 Theming with <3. I did love the Princess Cruises case study since it is a wonderfully complex but elegantly deployed combination of multilingual workflow, services, and content syncing. Their team did an amazing job!

Kristen's Favorite Session/BoF

The "hallway track" was strong at this 'con for me. I only went to two BoFs (one was Aimee's D8 multilingual workshop and the other one was multilingual therapy) and one session (my own multilingual D7 talk). So… I guess my favorite organized non-party thing was helping at the sprints on Friday! :)

Tom's Favorite Session/BoF
  1. Estimation - A science not an art
  2. Building Your (Drupal-based) Business: Or... What Keeps You Up At Night?
K2's Favorite Session/BoF

My favorite session was MortenDK’s Drupal 8 Theming with <3. He’s fun to watch and got me really jazzed to use twig in Drupal 8.

Darryl's Favorite Session/BoF

I really enjoyed Jeff Eaton’s Battle for the Body Field, but I cheated by watching it after I got home. I learned about Entity Embed module, for which I think I’m going to find a lot of use!

Lindsay's Favorite Session/BoF

The winner is … CI for CSS: Creating a Visual Regression Testing Workflow. Wow, that’s a mouthful of a title, but quite an informative session. Lots of great things to know that were presented clearly. Thanks for the great session by Kate Kligman.

Patrick's Favorite Session/BoF

I greatly enjoyed the “I Survived Drupalgeddon” session by Matt Korostoff. It was a fun personal story of how hackers invaded his site, what happened after they did, and how one can prevent it from happening to their site.

Genevieve's Favorite Session/BoF

My two unrelated favorites were - 1) Designing for Brains: The Psychology of User Experience & 2) How to Run a Drupal Agency.

Tshirt/Swag

There were some really fun tshirts and swag in LA. We brought two new designs of our own (California Drupalin' and It Takes a Village), thanks to the very talented artist, Joe To, along with some previous favorites including Drup Oil, Features Reaper (happy version), and Multilingual Drupal to fill out our growing number of awesome doodles. Going to camp or con and want some swag? Ping us to see if we'll be there. ;)

drupalcon_la_monkey_swag.jpg

DrupalCon LA monkey hats from Mailchimp were a big hit. Photo credit: Paul Johnson.

Aimee's Favorite Tshirt/Swag

Four Kittens v2! Backdrop DRAGON! Pantheon’s I BUILD THE INTERNET, LA edition! Hangover helper survival kits!

Kristen's Favorite Tshirt/Swag

Monkey hat is super cute and the Backdrop dragon but I think my kids liked the backscratcher the best… makes for a good extra hand.

aaron_with_backscratcher_hand.jpg

Mom… I can scratch your back! Photo credit: Kristen Pol.

Tom's Favorite Tshirt/Swag

I BUILD THE INTERNET!

K2's Favorite Tshirt/Swag

My favorite T-Shirt was the monkey hats from Mailchimp, wa hoo! I just wish I had gotten a picture of Lindsay in it!

Darryl's Favorite Tshirt/Swag

What am I supposed to do with a hockey stick? I did get another Jet Brains PHPStorm yo-yo, which I do play with.

Lindsay's Favorite Tshirt/Swag

Definitely the Backdrop sticker. I mean, seriously, look at this dragon. So cool.

drop_final_black.png

Backdrop's Dragon Drop is pretty darn cute. Image credit: Backdrop Press Kit.

Patrick's Favorite Tshirt/Swag

My favorite shirt was the Golden State Warriors Tshirt that had Pantheon’s logo on the back. Apparently they bought the Golden State Warriors Tshirt right down the street of their SF office and just added their logo to the back!

Food

Not sure if great food is what comes to mind when going to LA like it did for Portland or Austin but we still managed to get in some good eats.

drupalcon_la_pantheon_dinner.jpg

Pantheon partner dinner at the Palm. Image credit: Kristen Pol.

Aimee's Favorite Food

The Original Pantry for the early-risers breakfast with Darryl and the 2 am post-party breakfast for the night owls. Yay for 24 hour comfort food!

Kristen's Favorite Food

Who needs words? This was my dessert at Local Table.

drupalcon_la_yum_desserts.jpg

Local Table has pastry chef who makes masterpieces. Image credit: Kristen Pol.

Tom's Favorite Food

Grand Central Market

K2's Favorite Food

My favorite meal was the Hook 42 dinner at what I will refer to as “the home cooked hipster joint in Hollywood.” So much fun to just be us all together - it felt like family.

Darryl's Favorite Food

I had breakfast 3 times at The Original Pantry. It was right on the way, and I was always there a bit ahead of the crowd, so I never had to wait. I think that’s one more time than I ever ate there in the 33 years I lived in LA (well, in The Valley, so, not very convenient).

Lindsay's Favorite Food

That filet mignon at the Pantheon dinner. Like butta.

Patrick's Favorite Food

My favorite food was the Guinness vanilla ice cream float I received at the Hook 42 dinner because it was an efficient way to drink and eat at the same time.

Genevieve's Favorite Food

What K2 said. So tasty.

Person

DrupalCon is all about the people! We love seeing our old friends and meeting new ones. We <3 the community. :)

drupalcon_la_mentor_group_photo.jpg

DrupalCon LA mentors. Photo credit: amber_is_i.

Aimee's Favorite Person

ALL THE PEOPLE! It is wonderful to see the extended family of community members. Schnitzel, Ryan Weal, YesCT, and more! Patrick Storey and Lindsay Gaudinier were two shining examples of a successful second DrupalCon. Patrick was heavily engaged with mentoring and volunteering and Lindsay dove in deeply to the front end technical sessions. Austin + community + practice + LA is a great springboard for success.

drupalcon_la_patrick_mentoring.jpg

Patrick mentoring the new recruits. Last DrupalCon he was a recruit! Photo credit: Kristen Pol.

Kristen's Favorite Person

Tough one! Was nice to finally meet Damien McKenna in person and see his rabbit ears.

drupalcon_la_sprints_damien_ears.jpg

Gotta love them ears! Photo credit: Kristen Pol.

Tom's Favorite Person

Were there people there?!?

K2's Favorite Person

I didn’t have a standout favorite, but I can note that I feel like this time I really knew a lot more people and felt like part of the Drupal community. Wave to all!

Darryl's Favorite Person

I had a great time playing “Germanic Ping Pong” with the Amazee Labs folks at their party! (Yes, I know they’re Swiss, but I learned this game in Germany…)

Amazee Labs ping pong party including Germanic ping pong. Video credit: Kristen Pol.

Lindsay's Favorite Person

Ryan Weal. Him, K2 and I hung out in the coders lounge and it was tons of fun.

Patrick's Favorite Person

I’ll say Amy Vaillancourt-Sals. First off, great name! She came to the Mentor Core Sprint where I was mentoring and I showed her how to re-roll a patch. Then a couple hours later I saw her pushing the “return” button on Dries’ computer for the Live Commit! And I was able to think to myself “I knew her before she was famous”.

Genevieve's Favorite Person

It was my first DrupalCon - so everyone was new and interesting!

Social Event

The social event calendar was extra packed for LA. We couldn't get to everything but did what we could. Too many fun things, too little time! ;)

drupalcon_la_pantheon_party.jpg

Pantheon Party. Photo credit: Kristen Pol.

Aimee's Favorite Social Event

The Pantheon party. Hands down. Thank you, Pantheon!

Kristen's Favorite Social Event

Ok, this one was tough. You know bubble wrap? Addicting, right? Well… try one of these ping pong ball collectors when you have a room of crazy Drupalers hitting (or dumping!) balls to the floor at an amazing rate. OCD heaven! On a more relaxing note, I had a wonderful soak in a hot tub with K2 instead of going to trivia night (first one I've missed!)... that was a relaxing type of heaven (with lightning to boot).

drupalcon_la_kp_cleaning_up_ping_pong_balls.jpg

Kristen Pol on duty at the Amazee Labs ping pong party. Photo credit: Amazee Labs.

Tom's Favorite Social Event

Meh

K2's Favorite Social Event

Without a doubt the big outdoor party that Pantheon threw - amazing!

Darryl's Favorite Social Event

The Pantheon party and the Amazee Labs parties were both great!

Lindsay's Favorite Social Event

The outdoor Pantheon party. There was dancing and the nicest porta potties ever.

Patrick's Favorite Social Event

Definitely the L.A. Live Pantheon party. Shut down a street in one of the biggest cities in the world? Sure, why not!

Genevieve's Favorite Social Event

You can never forget Ping Pong!

drupalcon_la_k2_patrick_gno_amazee_labs.jpg

K2, Patrick & Genevieve at the Amazee Labs ping pong party. Photo credit: Amazee Labs.

Weird/Strange LA Thing

No matter where you go, there's gotta be something weird. Here's some interesting things we came across in Los Angeles.

drupalcon_la_octopus_thingy.jpg

Not sure really what this is but it was in Kristen & Kristin's airbnb. Photo credit: Kristen Pol.

Aimee's Favorite Weird/Strange LA Thing

On Google Maps, the “Urban Core” was called Skid Row. Every time I searched for directions, the late ‘80s metal music played in my head.

Kristen's Favorite Weird/Strange LA Thing

Our Airbnb was pretty eclectic. There were steampunky things adorning the surfaces and artsy things on the walls and even super heroes hanging from the bathroom ceiling.

drupalcon_la_airbnb_steampunk.jpg

This punk was protecting us from a good vantage point in our Airbnb. Photo credit: Kristen Pol.

Tom's Favorite Weird/Strange LA Thing

How could the LA downtown “Urban Core” have fewer cars than San Francisco? It’s LA. Car town.

K2's Favorite Weird/Strange LA Thing

Fruit on the street with chili and salt on it. Yum! Also the crazy amount of shutdown theaters in the area we stayed. Who knew LA had such beautiful architecture downtown.

Darryl's Favorite Weird/Strange LA Thing

The coded magnetic door lock keys to our AirBnB apartment were kind of weird. Insert the key into the lock, wait until the lock mechanism activates, then turn. And you had to turn it to the right to unlock the door.

Lindsay's Favorite Weird/Strange LA Thing

All of the dogs out for walks in the morning! I wanted to pet every single one! [Cue Oprah] You get a dog, and you get a dog, everyone gets a dog!

Patrick's Favorite Weird/Strange LA Thing

Apparently between 9-11pm it’s dog walk o’clock. You will not see any dogs all day, and all of a sudden everyone is walking dogs everywhere downtown.

That’s a wrap!

Thanks to the Drupal Association and all the volunteers for making DC LA a huge success. Please leave a comment with some of your favorite things! And… see you in L.A. again… this time as in Lousiana. :)

Epilogue

In case you didn't see enough photos…

drupalcon_la_mentor_dinner.jpg

Mentor dinner at Local Table. Photo credit: Kristen Pol.

drupalcon_la_darryl_schnitzel_ping_pong.jpg

Darryl hanging out with Schnitzel. Photo credit: Amazee Labs.

drupalcon_la_aimee_k2_gno_bowling_party.jpg

Aten+Kalamuna+Four Kitchens bowling party. Photo credit: Kristen Pol.

drupalcon_la_pantheon_party_pinball.jpg

Pantheon pinball party. Photo credit: Kristen Pol.

drupalcon_la_pantheon_party_aimee_patrick_lindsay.jpg

Still smarting from pantheon party last night @getpantheon #DrupalConLA #hook42 @hook42inc pic.twitter.com/oUGT3zI61Z

— K2 (@K2Hook42) May 14, 2015 Tuesday, May 26, 2015 Hook 42 Topics:
Catégories: Elsewhere

Modules Unraveled: 136 Details on the NodeSquirrel Acquisition by Pantheon with Drew Gorton and Ronan Downling - Modules Unraveled Podcast

mer, 27/05/2015 - 07:00
Published: Wed, 05/27/15Download this episodeNodeSquirrel
  • What is NodeSquirrel?
    • Backup and Migrate (over 300,000 sites using it)
    • Only cloud backup-as-a-service for Drupal
    • Backup database and Files
    • Every site should have automatic off-site backups configured.
  • That leads great into the pantheon acquisition, because now everyone can create free off-site backups with NodeSquirrel.
Pantheon Acquisition
  • How did the aqcuisition come about?
    • Drew - BadCamp October 2014. Sitting at a Pantheon party, ended up talking to Zack about running a services firm and product at the same time. The excitement, issues etc. involved with that. And it happened.
  • Did you pitch it to him? Did he pitch it to you?
    • Me.
  • So, what’s in it for them? Why did Pantheon buy NodeSquirrel?
    • They want to build great tools that developers can love and trust and use.
  • What’s new now that it’s been acquired by Pantheon?
    • It’s FREE! (There’s a new free tier)
    • It’s not a trial. It’s always free.
    • It’s not just for Pantheon customers.
    • We have access to Pantheon’s resources to further the development and continue improving support.
    • It’s been a side project from the start, but now that it’s backed by a real product company, we’re officially here for the long-haul. So, if you’ve been holding off because you didn’t want to risk storing your backups with something that might not be there in a year, you can rest assured that we’ll be here.
    • (Ronan) Now I’m able to dedicate more time and effort to the Backup and Migrate module (instead of only using my free time), which helps the community as a whole.
  • What happens to current users?
    • Higher storage limits
    • Might even be able to downgrade and pay less.
    • Won’t lose any features. Still use local backup, etc. (except maybe email)
  • What’s in the future?
    • Drupal 8
    • Wordpress
    • More features for both Backup and Migrate and NodeSquirrel
    • Bringing Pantheon features to NodeSquirrel and NodeSquirrel features to Pantheon (Notes)
Episode Links: Ronan on drupal.orgRonan on TwitterDrew on drupal.orgDrew on TwitterNodeSquirrel on TwitterNodeSquirrelBackup and Migrate ModulePantheonZack’s post about the acquisitionDrew’s post about the acquisitionTags: BackupsNodeSquirrelplanet-drupal
Catégories: Elsewhere

Pages