Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 55 min 18 sec ago

DrupalCon News: Share your Drupal Development Knowledge at DrupalCon

2 hours 37 min ago

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.

Categories: Elsewhere

Annertech: 10 Top Drupal Modules to help increase SEO

5 hours 46 min ago
10 Top Drupal Modules to help increase SEO "We want to rank number one on Google" - every client ever.
Categories: Elsewhere

Jim Birch: Essential Drupal: The Style Guide Module

6 hours 51 min ago

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

Categories: Elsewhere

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

15 hours 5 min ago

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.

Categories: Elsewhere

LevelTen Interactive: DrupalCon LA 2015: Roundtable Interviews

Wed, 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

Categories: Elsewhere

Lullabot: Making The Most Of Mobilegeddon

Wed, 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.

Categories: Elsewhere

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

Wed, 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.

Categories: Elsewhere

OpenConcept: Best practices for generating patches and interdiffs

Wed, 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: 
Categories: Elsewhere

Chromatic: Testing Recurly Webhooks with ngrok

Wed, 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.

Categories: Elsewhere

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

Wed, 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.

Categories: Elsewhere

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

Wed, 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:
Categories: Elsewhere

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

Wed, 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
Categories: Elsewhere

Pixelite: How to profile PHP memory with Drupal

Wed, 27/05/2015 - 02:00
Why is this important

How to size the PHP setting max_memory is actually really important for the health of your Drupal application. Size this too small, and you risk getting PHP fatals due to not enough memory allocated. Size this too large, and you are essentially under-utilising your hardware, which in turn can lead to more cost.

How to record every Drupal requests PHP max memory usage

Tim Hillard created this really nice module called Memory profiler, which probably wins some sort of award for being around one of the smallest modules on drupal.org. Essentially this module registers a shutdown function that gets called at the end of every normal Drupal request.

The module is lightweight enough to run on production and only produces an extra syslog line per request.

Analyse the data

The data for memory profiler flows into watchdog, so if you run syslog (which you should), you can use CLI tools to analyse the data.

What does a single request look like $ grep "memory profiler" drupal-watchdog.log | head -n 1 May 26 06:25:21 10.212.4.16 sitename: https://www.sitename.com|1432621521|memory profiler|1.152.97.17|https://www.sitename.com/|https://www.sitename.com/home|0||4.75 MB - home request_id="v-fc9573dc-036f-11e5-a8c0-22000af91462"

This comes from your syslog format (which can be changed on a per site basis):

$ drush vget syslog_format syslog_format: '!base_url|!timestamp|!type|!ip|!request_uri|!referer|!uid|!link|!message' Extract the data from syslog

From here you can tokenise the parts you actually care about, in other words the:

  • URL requested (part 5)
  • PHP max memory (part 9)

Using more bash foo

$ grep "memory profiler" drupal-watchdog.log | head -n 1 | awk -F'|' -v OFS=',' '{print $5, $9}' https://www.sitename.com/,4.75 MB - home request_id="v-fc9573dc-036f-11e5-a8c0-22000af91462"

On Acquia Cloud a request ID is added to all requests, we don’t need this. Also having the string ‘MB’ there is superfluous.

$ grep "memory profiler" drupal-watchdog.log | head -n 1 | awk -F'|' -v OFS=',' '{print $5, $9}' | sed 's/ MB.*//' https://www.presto.com.au/,4.75

Perfect.

So in order to create a CSV for analysing in a spreadsheet you could do:

$ echo "request_uri,max_memory" > /tmp/memory.csv && grep "memory profiler" drupal-watchdog.log | awk -F'|' -v OFS=',' '{print $5, $9}' | sed 's/ MB.*//' >> /tmp/memory.csv

And then you can make pretty graphs if you want:

Or if you just want to find the top requests to your application by memory you can do

$ grep "memory profiler" drupal-watchdog.log | awk -F'|' -v OFS=',' '{print $5, $9}' | sed 's/ MB.*//' | sort -t, -k+2 -n -r | head -n 20 Conclusions

Based on your findings in the logs, you should be able to come up with:

  • A better understanding of your request memory profile
  • Better max memory settings for your Drupal application
  • Potentially identify poor performing pages (memory wise) and can look to optimise them
Gotchas

This module will only work if:

  • hook_boot() is called (which might not be the case if you run custom lightweight PHP scripts that do not bootstrap Drupal)
  • The Drupal request is not terminated with a SIGTERM or SIGKILL signal
Comments

Let me know if you found this helpful, or if you have any changes to my bash foo. If you have profiled your Drupal application recently, what methods and tools did you use?

Categories: Elsewhere

DrupalCon News: Talking Business and Strategy in Barcelona

Wed, 27/05/2015 - 00:32

This year, the Business and Strategy track in Barcelona will be about growth and change. The Drupal market is expanding as companies are growing, being founded or merging. Both growth and change present Drupal businesses with various challenges which is why we will focus on how we grow and how we sustain a strong culture in the midst of it, while sharing proven processes and tools.

Categories: Elsewhere

DrupalCon News: How Session Selection Works

Tue, 26/05/2015 - 22:31

Once you’ve submitted a stellar session proposal, you'll probably wonder what the process for session selection looks like from the other side. We are happy to pull back the veil on this community-led selection process for you to better understand the bells and whistles of session selection.

Categories: Elsewhere

DrupalCon News: Train with us in Barcelona

Tue, 26/05/2015 - 21:06

Want to help us make DrupalCon Barcelona the best event it can be? Get training! We’re currently accepting training proposals for DrupalCon Barcelona, so if you want to share your Drupal knowledge and get a little cash doing it, submit your great training idea to our team.

Categories: Elsewhere

Drupal Association News: Please help us welcome Mark and Gener

Tue, 26/05/2015 - 19:13

The Drupal Association is thrilled to announce the start of two new employees. Many of you may have met Mark and Gener at DrupalCon Los Angeles, but for those of you who were unable to make it, or who didn’t run into them, here’s the info about our newest additions to the team.

Mark Brandstetter, Account Manager for Technology and Hosting, Revenue Team

Mark Brandstetter is helping to take over Don Page's role as one of the new Account Manager's for technology and hosting based out of the Portland office. Mark is originally from the Midwest, but most recently spent 5 years living in Brooklyn, New York. Previously, Mark worked at Yelp and AdRoll, and his background in digital marketing and strategy will prove helpful to the team! In his free time, Mark enjoys cooking, hiking and hopes to one day join his his fellow Portland-Druplers at the DA in owning his very own urban chicken(s). Fingers crossed!!

Gener Umali, Drupal.org Advertising, Revenue Team

Gener Umali will be focused on Drupal.org Advertising, with an emphasis on thoughtfully creating connections between the right people and products. Prior to joining the Drupal Association, Gener worked as a Director of Advertising Sales. In a ten-year advertising career ranging from startups to big-names like CNET, Gener has worked with Mac and Linux Developers, but has never encountered a group as passionate as Drupal developers. He is humbled and inspired by their dedication. In his free time, Gener enjoys tinkering with cars, motorcycles, or anything with a motor. He enjoys travel, and has been to more than thirty countries. He also enjoys snowboarding, skiing, fitness, photography, and collecting old mechanical watches.

Please help us give a warm welcome to Mark and Gener. They’ll be working hard to generate funding for the project we all love, and are already proving to be fantastic additions to the Drupal Association team.

Welcome, Mark and Gener!

Categories: Elsewhere

Drupal Watchdog: Version Control Workflow Strategies

Tue, 26/05/2015 - 17:28
Article

As a longtime lover of source control, I've been known to have a few opinions on how to use it. I've generally taken the approach that the tool I use needs to work for me, not against me. Unfortunately with the flexibility of a distributed version control system, such as Git, the right answer isn't always obvious. Taking the time to impose some arbitrary constraints on your workflow will make your daily tasks more predictable, and therefore easier to complete. One of the biggest wins you can make is using a standardized branching pattern for your work. If your team hasn't already "unvented" its own best practices, this article will help you choose an effective workflow for your team.

The different workflows really break down into two simple categories: the first is best described as a scheduled release pattern; the second as continuous deployment. Of course there are a spectrum of options in between, but let's look at the polar opposites for now.

The first option, the scheduled release, is typically used for products which have launch dates and different versions available at any one point in time. For example, Drupal uses a major.minor syntax for its releases. In some scheduled releases, you will also have a smaller “hotfix” release which adds a third set of numbers to the released version. From a branch perspective, this means you have a number of parallel development branches at work. Each time you begin new work, you need to carefully consider your starting point. This branching pattern was popularized by the 2010 blog post describing what is now referred to as the Gitflow Branching Model.

Categories: Elsewhere

Drupal Easy: DrupalEasy Podcast 155: Feel 66% Better (Ben Jeavons - Drupal.org Two-Factor Authentication)

Tue, 26/05/2015 - 17:06
Download podcast 155

Ben Jeavons, coltrane on Drupal.org, member of the Drupal security team, joins Ted Bowman, Ryan Price, and Mike Anello on the first post-DrupalCon Los Angeles podcast. Ben gets us up-to-speed on two-factor authentication and the modules he helped write as well as their implementation on Drupal.org. We also wrap up our coverage of DrupalCon Los Angeles, practice using Ted's new nickname, and assign homework to listeners.

read more

Categories: Elsewhere

Cheeky Monkey Media: 4 Easy steps to configure Drupal to send html emails

Tue, 26/05/2015 - 16:00

Do you know drupal can be config to send out html mails, which you can add images, colours to email in order to enhance your users experience.

We are going to use mail system and mime mail in this tutorial. I will try to keep things simple.

Step 1: Install required modules and update configuration
  1. https://www.drupal.org/project/mailsystem
  2. https://www.drupal.org/project/mimemail

Here is a tutorial of how to install modules for drupal...

Categories: Elsewhere

Pages