Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 5 hours 6 min ago

Freelock : Book 3: Metrics to success and selecting a vendor

23 February 2017 - 2:10pm

When thinking about ways to measure your website’s effectiveness, you may also want to think about the metrics you use to gauge the success of the website in accomplishing your business goals. How else do you measure success?

Categories: Drupal

DrupalCon News: Level up your Drupal skills with our training courses, now available for sign-ups

23 February 2017 - 1:34pm

Thirsty for Drupal knowledge? Want to dive deep into a topic and learn from the best in the field? Like to get hands-on with your learning material? We are excited to offer 10 full-day training classes at DrupalCon Baltimore that will turn you into a Drupal superhero. No matter if you are an absolute beginner or Drupal expert, our classes cover all experience levels.

Categories: Drupal

DrupalCon News: Drupal Association Welcomes 17 Grant and Scholarship Recipients

23 February 2017 - 9:42am

Our community is made up of incredible members from across the globe who continue to grow the Drupal project and create communities. DrupalCon is a place where community leaders and key contributors come together to meet, learn, and collaborate. The Drupal Association's Grant and Scholarship Program makes attending possible for many community members who may not have been otherwise able to join us.  

Categories: Drupal

Drupal Association blog: Doing our part for the community

23 February 2017 - 9:25am

The Drupal Association Engineering Team delivers value to all who are using, building, and developing Drupal. The team is tasked with keeping Drupal.org and all of the 20 subsites and services up and running. Their work would not be possible without the community and the project would not thrive without close collaboration. This is why we are running a membership campaign all about the engineering team. These are a few of the recent projects where engineering team + community = win!

Want to hear more about the work of the team, rather than read about it? Check out this video from 11:15-22:00 where Tim Lehnen (@hestenet) talks about the team's recent and current work.

Leading the Documentation System migration

We now have a new system for Documentation. These are guides Drupal developers and users need to effectively build and use Drupal. The new system replaces the book outline structure with a guides system, where a collection of pages with their own menu are maintained by the people who volunteer to keep the guides updated, focused, and relevant. Three years of work from the engineering team and community collaborators paid off. Content strategy, design, user research, implementation, usability testing and migration have brought this project to life.


Pages include code 'call-outs' for point-version specific information or warnings.

Thanks to the collaborators: 46 have signed up to be guide maintainers, the Documentation Working Group members (batigolix, LeeHunter, ifrik, eojthebrave), to tvn, and the many community members who write the docs!

Enabling Drupal contribution everywhere

Helping contributors is what we do best. Here are some recent highlights from the work we're doing to help the community:

Our project to help contributors currently in development is revamping the project applications process. More on this soon on our blog.

When a community need doesn't match our roadmap

We have a process for prioritizing community initiatives so we can still help contributors. Thanks to volunteers who have proposed and helped work on initiatives recently, we've supported the launch of the Drupal 8 User guide and the ongoing effort to bring Dreditor features into Drupal.org itself.  

Thanks to the collaborators: jhodgdon, eojthebrave, and the contributors to the user guide. Thanks also to markcarver for the Dreditor effort.

How to stay informed and support our work.

The change list and the Drupal.org roadmap help you to see what the board and staff have prioritized out of the many needs of the community.

You can help sustain the work of the Drupal Association by joining as a member. Thank you!

Categories: Drupal

Zhilevan Blog: REST Authentication in Decoupled Drupal

22 February 2017 - 11:22pm
In the traditional Drupal site, you don’t need to handle authentication, because Drupal handle everything by itself, gets a cookie, set session, error handling etc. But what about decoupled(headless drupal) sites? How can we authenticate the user on decoupled? Before diving into this, we need to understand the authentication types provided by RESTful:
Categories: Drupal

Gbyte blog: precore.net - a plattform for artists and design students

22 February 2017 - 6:00pm
Since its relaunch in 2015, the Drupal 7 powered precore.net has been gaining popularity among artists and design students to become their go-to platform. Until today, design students have uploaded over 700 portfolios providing guidance to enrolling candidates. These portfolios are linked to over 500 art faculties of hundreds of universities. Before enrolling in a course, a candidate can research their local university and study other students' portfolios or enroll in their local design course to prepare for the entry tests - all of it on precore.net.
Categories: Drupal

Joachim's blog: Dorgflow: a tool to automate your drupal.org patch workflow

22 February 2017 - 3:14pm

I’ve written previously about git workflow for working on drupal.org patches, and about how we don’t necessarily need to move to a github-style system on drupal.org, we just maybe need better tools for our existing workflow. It’s true that much of it is repetitive, but then repetitive tasks are ripe for automation. In the two years since I released Dorgpatch, a shell script that handles the making of patches for drupal.org issues, I’ve been thinking of how much more of the drupal.org patch workflow could be automated.

Now, I have released a new script, Dorgflow, and the answer is just about everything. The only thing that Dorgflow doesn’t automate is uploading the patch to drupal.org (and that’s because drupal.org’s REST API is read-only). Oh, and writing the code to actually fix bugs or create new features. You still have to do that yourself, along with your cup of coffee.

So assuming you’ve made your own hot beverage of choice, how does Dorgflow work?

Simply! To start with, you need to have an up to date git clone of the project you want to work on, be it Drupal core or a contrib project.

To start work on an issue, just do:

$ dorgflow https://www.drupal.org/node/123456

You can copy and paste the URL from your browser. It doesn’t matter if it has an anchor link on the end, so if you followed a link from your issue tracker and it has ‘#new’ at the end, or clicked down to a comment and it has ‘#comment-1234’ that’s all fine.

The first thing this comment does it make a new git branch for you, using the issue number and the name. It then also downloads and applies all the patch files from the issue node, and makes a commit for each one. Your local git now shows you the history of the work on the issue. (Note though that if a patch no longer applies against the main branch, then it’s skipped, and if a patch has been set to not be displayed on the issue’s file list, then it’s skipped too.)

Let’s see how this works with an actual issue. Today I wanted to review the patch on an issue for Token module. The issue URL is https://www.drupal.org/node/2782605. So I did:

$ dorgflow https://www.drupal.org/node/2782605

That got me a git history like this:

* 6d07524 (2782605-Move-list-of-available-tokens-from-Help-to-Reports) Patch from Drupal.org. Comment: 35; URL: https://www.drupal.org/node/2782605#comment-11934790; file: token-move-list-of-available-tokens-2782605-34.patch; fid 5784728. Automatic commit by dorgflow. * 6f8f6e0 Patch from Drupal.org. Comment: 15; URL: https://www.drupal.org/node/2782605#comment-11666939; file: 2782605-13.patch; fid 5710235. Automatic commit by dorgflow. / * a3b68cc (8.x-1.x) Issue #2833328 by Berdir: Handle bubbleable metadata for block title token replacements * [older commits…]

What we can see here is:

  • Git is now on a feature branch, called ‘2782605-Move-list-of-available-tokens-from-Help-to-Reports’. The first part is the issue number, and the rest is from the title of the issue node on drupal.org.
  • Two patches were found on the issue, and a commit was made for each one. Each patch’s commit message gives the comment index where the patch was posted, the URL to the comment, the patch filename, and the patch file entity ID (these last two are less interesting, but are used by Dorgflow when you update a feature branch with newer patches from an issue).

The commit for patch 35 will obviously only show the difference between it and patch 15, an interdiff effectively. To see what the patch actually contains, take a diff from the master branch, 8.x-1.x.

(As an aside, the trick to applying a patch that’s against 8.x-1.x to a feature branch that already has commit for a patch is that there is a way to check out files from any git commit while still keeping git’s HEAD on the current branch. So the patch applies, because the files look like 8.x-1.x, but when you make a commit, you’re on the feature branch. Details are on this Stack Overflow question.)

At this point, the feature branch is ready for work. You can make as many commits as you want. (You can rename the branch if you like, provided the ‘2782605-’ part stays at the beginning.) To make your own patch with your work, just run the Dorgflow script without any argument:

$ dorgflow

The script detects the current branch, and from that, the issue number, and then fetches the issue node from drupal.org to get the number of the next comment to use in the patch filename. All you now have to do is upload the patch, and post a comment explaining your changes.

Alternatively, if you’re a maintainer for the project, and the latest patch is ready to be committed, you can do the following to put git into a state where the patch is applied to the main development branch:

$ dorgflow commit

At that point, you just need to obtain the git commit command from the issue node. (Remember the drupal standard git message format, and to check the attribution for the work on the issue is correct!)

What if you’ve previously reviewed a patch, and now there’s a new one? Dorgflow can download new patches with this command:

$ dorgflow update

This compares your feature branch to the issue node’s patches, and any patches you don’t yet have get new commits.

If you’ve made commits for your own work as well, then effectively there’s a fork in play, as your development in your commits and the other person’s patch are divergent lines of development. Appropriately, Dorgflow creates a separate branch. Your commits are moved onto this branch, while the feature branch is rewound to the last patch that was already there, and then has the new patches applied to it, so that it now reflects work on the issue. It’s then up to you to do a git merge of these two branches in order to combine the two lines of development back into one.

Dorgflow is still being developed. There are a few ideas for further features in the issue queue on github (not to mention a couple of bugs for some of the various possible cases the update command can encounter). I’m also pondering whether it’s worth the effort to convert the script to use Symfony Console; feel free to chime in with any opinions on the issue for that.

There are tests too, as it’s pretty important that a script that does things to your git repository does what it’s supposed to (though the only command that does anything destructive is ‘dorgflow cleanup’, which of course asks for confirmation). Having now written this, I’m obviously embarking upon cleaning it up and to some extent rewriting it, though I do have the excuse that the early weeks of working on this were the days after the late nights awake with my newborn daughter, and so the early versions of the code were written in a haze of sleep deprivation. If you’d like to submit a pull request, please do check in with me first on an issue to ensure it’s not going to clash with something I’m partway through changing.

Finally, if you find this as useful as I do (this was definitely an itch I’ve been wanting to scratch for a long time, as well as being a prime case of condiment-passing), please tell other Drupal developers about it. Let’s all spend less time downloading, applying, and rolling patches, and more time writing Drupal code!

Categories: Drupal

Jeff Geerling's Blog: Thoughts on the Acquia Certified Back end Specialist - Drupal 8 Exam

22 February 2017 - 1:37pm

Continuing along with my series of reviews of Acquia Developer Certification exams (see the previous one: Drupal 8 Site Builder Exam, I recently took the Back End Specialist – Drupal 8 Exam, so I'll post some brief thoughts on the exam below.


I didn't get a badge with this exam, just a cert... so here's the previous exam's badge!

Categories: Drupal

myDropWizard.com: Drupal 6 security update for Views

22 February 2017 - 1:12pm

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

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

The Views module allows site builders to create listings of various data in the Drupal database.

The Views module fails to call db_rewrite_sql() on queries that list Taxonomy Terms, which could cause private data stored on Taxonomy Terms to be leaked to users without permision to view it.

This is mitigated by the fact that a View must exist that lists Taxonomy Terms which contain private data. If all the data on Taxonomy Terms is public or there are no applicable Views, then your site is unaffected.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

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

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

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

Categories: Drupal

Amazee Labs: This was Drupal Mountain Camp

22 February 2017 - 5:14am
This was Drupal Mountain Camp

From 16-19 February, the first Drupal Mountain Camp took place in Davos, Switzerland. A very diverse crowd of 135 attendees from, 17 different countries, came together to share the latest and greatest in Drupal 8 development, as well as case studies from Swiss Drupal vendors.

Josef Dabernig Wed, 02/22/2017 - 14:14

When we started organizing Drupal Mountain Camp in the summer of 2016, it was hard to predict how much interest it would attract and how many people would join for the camp. By reaching out to the local and international Drupal ecosystem we were excited to get so many people to attend from all around the world including Australia, India, and the US.

As a team of a dozen organizers; we split up the tasks, like setting up the venue, registration, social media, room monitoring and much more. It was great seeing that we were able to split the workload across the entire team and keep it well balanced.

We are very thankful for 30 different speakers who travelled from afar and worked hard to share their expertise with the crowd. As a program organizer I might be biased, but I truly believe that the schedule was packed with great content :)

In addition to the sessions, we also provided free workshop trainings to help spread some more Drupal love.

We took all the speakers up to the mountain for Switzerland's most popular dish, cheese fondue, to say thank you for their sessions and inputs.

With Drupal Mountain Camp we wanted to set a theme that would not only excite attendees with Swiss quality sessions but also create a welcoming experience for everyone. On top of our Code of Conduct, we organized various social activities that would allow attendees to experience Switzerland, snow and the mountains.  

Sprints are an essential way to get started with contributing to Drupal. At Drupal Mountain Camp, we organized a First-time sprinter workshop and had Sprint rooms from Thursday until Sunday with many sprinters collaborating.

For our hosting company amazee.io, Drupal Mountain Camp was a great opportunity to demonstrate our docker based development environment and scalable cluster stack using a set of raspberry pies.

And of course, we ended the conference with skiing and snowboarding at the Swiss mountains :)

Pictures from the camp: selection and all. Curious about the next Drupal Mountain Camp? Follow us on twitter to stay on top and see you at the next event.

Categories: Drupal

Third & Grove: Seniorlink Drupal Case Study

22 February 2017 - 12:00am
Seniorlink Drupal Case Study antonella Wed, 02/22/2017 - 03:00
Categories: Drupal

Flocon de toile | Freelance Drupal: Introduction to Protected file module on Drupal 8

21 February 2017 - 2:30pm

Drupal 8 has several solutions and methods to manage access rights on each elements included in a content, and this in a very granular way. Enabling view or edit access on some field included in a content type can be achieved very simply, with a few lines of code, or with the Field Permissions module. We can use this module to allow certain roles to view or update a particular field.

Categories: Drupal

OhTheHugeManatee: What Crell Doesn't Want You to Know: How to Automate Letsencrypt on platform.sh

21 February 2017 - 1:33pm

If you believe the docs and the twitters, there is no way to automate letsencrypt certificates updates on platform.sh. You have to create the certificates manually, upload them manually, and maintain them manually.

But as readers of this blog know, the docs are only the start of the story. I’ve really enjoyed working with platform.sh with one of my private clients, and I couldn’t believe that with all the flexibility – all the POWER – letsencrypt was really out of reach. I found a few attempts to script it, and one really great snippet on gitlab. But no one had ever really synthesized this stuff into an easy howto. So here we go.

1) Add some writeable directories where platform.sh CLI and letsencrypt need them.

Normally when Platform deploys your application, it puts it all in a read-only filesystem. We’re going to mount some special directories read-write so all the letsencrypt/platform magic can work.

Edit your application’s .platform.app.yaml file, and find the mounts: section. At the bottom, add these three lines. Make sure to match the indents with everything else under the mounts: section!

1 2 3 "/web/.well-known": "shared:files/.well-known" "/keys": "shared:files/keys" "/.platformsh": "shared:files/.platformsh"

Let’s walk through each of these:

  • /web/.well-known: In order to confirm that you actually control example.com, letsencrypt drops a file somewhere on your website, and then tries to fetch it. This directory is where it’s going to do the drop and fetch. My webroot is web, you should change this to match your own environment. You might use public or www or something.
  • /keys: You have to store your keyfiles SOMEWHERE. This is that place.
  • /.platformsh: Your master environment needs a bit of configuration to be able to login to platform and update the certs on your account. This is where that will go.
2) Expose the .well-known directory to the Internet

I mentioned above that letsencrypt test your control over a domain by creating a file which it tries to fetch over the Internet. We already created the writeable directory where the scripts can drop the file, but platform.sh (wisely) defaults to hide your directories from the Internet. We’re going to add some configuration to the “web” app section to expose this .well-known directory. Find the web: section of your .platform.app.yaml file, and the locations: section under that. At the bottom of that section, add this:

1 2 3 4 5 6 7 8 '/.well-known': # Allow access to all files in the public files directory. allow: true expires: 5m passthru: false root: 'web/.well-known' # Do not execute PHP scripts. scripts: false

Make sure you match the indents of the other location entries! In my (default) .platform.app.yaml file, I have 8 spaces before that '/.well-known': line. Also note that the root: parameter there also uses my webroot directory, so adjust that to fit your environment.

3) Download the binaries you need during the application “build” phase

In order to do this, we’re going to need to have the platform.sh CLI tool, and a let’s encrypt CLI tool called lego. We’ll download them during the “build” phase of your application. Still in the platform.app.yaml file, find the hooks: section, and the build: section under that. Add these steps to the bottom of the build:

1 2 3 cd ~ curl -sL https://github.com/xenolf/lego/releases/download/v0.3.1/lego_linux_amd64.tar.xz | tar -C .global/bin -xJ --strip-components=1 lego/lego curl -sfSL -o .global/bin/platform.phar https://github.com/platformsh/platformsh-cli/releases/download/v3.12.1/platform.phar

We’re just downloading reasonably recent releases of our two tools. If anyone has a better way to get the latest release of either tool, please let me know. Otherwise we’re stuck keeping this up to date manually.

4) Configure the platform.sh CLI

In order to configure the platform.sh CLI on your server, we have to deploy the changes from steps 1-3. Go ahead and do that now. I’ll wait.

Now connect to your platform environment via SSH (platform ssh -e master for most of us). First we’ll add a config file for platform. Edit a file in .platformsh/config.yaml with the editor of choice. You don’t have to use vi, but it will win you some points with me. Here are the contents for that file:

1 2 3 4 updates: check: false api: token_file: token

Pretty straightforward: this tells platform not to bother updating the CLI tool automatically (it can’t – read-only filesystem, remember?). It then tells it to login using an API token, which it can find in the file .platformsh/token. Let’s create that file next.

Log into the platform.sh web UI (you can launch it with platform web if you’re feeling sassy), and navigate to your account settings > api tokens. That’s at https://accounts.platform.sh/user/12345/api-tokens (with your own user ID of course). Add an API token, and copy its value into .platformsh/token on the environment we’re working on. The token should be the only contents of that file.

Now let’s test it by running php /app/.global/bin/platform.phar auth:info. If you see your account information, congratulations! You have a working platform.sh CLI installed.

5) Request your first certificate by hand

Still SSH’ed into that environment, let’s see if everything works.

1 2 3 lego --email="support@example.com" --domains="www.example.com" --webroot=/app/public/ --path=/app/keys/ -a run csplit -f /app/keys/certificates/www.example.com.crt- /app/keys/certificates/www.example.com.crt '/-----BEGIN CERTIFICATE-----/' '{1}' -z -s php /app/.global/bin/platform.phar domain:update -p $PLATFORM_PROJECT --no-wait --yes --cert /app/keys/certificates/www.example.com.crt-00 --chain /app/keys/certificates/www.example.com.crt-01 --key /app/keys/certificates/www.example.com.key example.com

This is three commands: register the cert with letsencrypt, then split the resulting file into it’s components, then register those components with platform.sh. If you didn’t get any errors, go ahead and test your site – it’s got a certificate! (yay)

6) Set up automatic renewals on cron

Back to .platform.app.yaml, look for the crons: section. If you’re running drupal, you probably have a drupal cronjob in there already. Add this one at the bottom, matching indents as always.

1 2 3 letsencrypt: spec: '0 0 1 * *' cmd: '/bin/sh /app/scripts/letsencrypt.sh'

Now let’s create the script. Add the file scripts/letsencrypt.sh to your repo, with this content:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 #!/usr/bin/env bash # Checks and updates the letsencrypt HTTPS cert. set -e if [ "$PLATFORM_ENVIRONMENT" = "master-7rqtwti" ] then # Renew the certificate lego --email="example@example.org" --domains="example.org" --webroot=/app/web/ --path=/app/keys/ -a renew # Split the certificate from any intermediate chain csplit -f /app/keys/certificates/example.org.crt- /app/keys/certificates/example.org.crt '/-----BEGIN CERTIFICATE-----/' '{1}' -z -s # Update the certificates on the domain php /app/.global/bin/platform.phar domain:update -p $PLATFORM_PROJECT --no-wait --yes --cert /app/keys/certificates/example.org.crt-00 --chain /app/keys/certificates/example.org.crt-01 --key /app/keys/certificates/example.org.key example.org fi

Obviously you should replace all those example.orgs and email addresses with your own domain. Make the file executable with chmod u+x scripts/letsencrypt.sh, commit it, and push it up to your platform.sh environment.

7) Send a bragging email to Crell

Technically this isn’t supposed to be possible, but YOU DID IT! Make sure to rub it in.

Good luck!

PS – I’m just gonna link one more time to the guy whose snippet made this all possible: Ariel Barreiro did the hardest part of this. I’m grateful that he made his notes public!

Categories: Drupal

Palantir: The Coolest Camp Ever

21 February 2017 - 8:31am
The Coolest Camp Ever brandt Tue, 02/21/2017 - 10:31 Alex Brandt Feb 21, 2017

We’re heading to Iceland February 24 - 26!

In this post we will cover...
  • Why we’re excited for this new event

  • Who from Palantir will be speaking

  • Some fun facts about Iceland

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.

Besides being the recent desired destination for Instagram #wanderlust-ers, Iceland is now home to an exciting new Drupal event: DrupalCamp Northern Lights. With twenty speakers, lots of coffee, and a planned sightseeing trip to see the Golden Circle and Northern Lights, it is sure to be an exciting inaugural event.

A small crew of Palantiri will be proudly representing, so if you are making the trek overseas, keep an eye out and say hi to Allison Manley, Michelle Jackson, and Megh Plunkett while you’re taking in the sessions and sights.

Check out the schedule and make sure to stop by our sessions.

 

Kickoff Meetings, by Allison Manley

  • Time: Saturday, 10:45 - 11:35
  • Location: Room ÞINGVELLIR

How do you make the most use of your face-to-face time with your client and lay the groundwork for a successful project?

Allison will outline how to get the most out of the kickoff meetings that initiate any project. She'll talk about pre-meeting preparation and how to keep organized, and also give some tips on agenda creation, how to keep meetings productive (and fun), and what steps need to be taken once the meetings adjourn.

 

Competitive Analysis: Your UX must-have on a budget, by Michelle Jackson

  • Time: Sunday, 14:15-15:00
  • Location: Room ÞINGVELLIR

A tight budget and time constraints can make dedicating time and resources to understanding audience needs challenging. Competitive analysis is an affordable way to evaluate how competitor sites are succeeding or failing to meet the needs of your audience.

Michelle will cover how competitive analysis can help you avoid competitor pitfalls, gain insight into what your users want, and lead to better decision-making before you invest in and implement new designs and technical features.

7 Facts You Might Not Have Known About Iceland
  • Iceland was one of the last places on earth to be settled by humans.
  • They are getting their first Costco in May.
  • 60% of the Icelandic population lives in Reykjavík.
  • Babies in Iceland are routinely left outside to nap.
  • Surprisingly, Iceland is not the birthplace of ice cream.
  • First names not previously used in Iceland must be approved by the Icelandic Naming Committee.
  • Owning a pet turtle is against the law. Sorry Rafael, Franklin, and this kid:

 

Fact Sources: http://www.portsmouth.co.uk/news/people/31-odd-facts-about-iceland-but-how-many-did-you-know-1-7445785, http://icelandreview.com/

We want to make your project a success.

Let's Chat.
Categories: Drupal

InternetDevels: Collection of some useful Drupal 8 modules in 2017

21 February 2017 - 8:01am

Our tradition of presenting you short overviews of several modules of the month continues with today’s article. Previously we offered you some great contributed Drupal 8 modules in June 2016 a collection of modules in May 2016. In 2017 we published some modules, with the latest available release for Drupal 8 scheduled for the beginning of this year.

Read more
Categories: Drupal

Xeno Media: Xeno Media's Jim Birch presents at DrupalCamp Northern Lights 2017

21 February 2017 - 7:01am

Organized by the Icelandic Drupal community, the inaugural Northern Lights Drupal Camp will take place on the this weekend, February 24th - 26th, 2017 at the University of Iceland in Reykjavik. We are honored that our Digital Strategist, Jim Birch was invited to speak.

Jim will present his Holistic SEO and Drupal talk--which covers the modern state of Search Engine Optimization and how we at Xeno Media define best practices for technical SEO using Drupal.  It also presents ideas on how to guide and empower clients to create the best content to achieve their digital goals.

This presentation will review:

  • What Holistic SEO is, and some examples of modern search results explained.
  • The most common search engine ranking factors, and how to keep up to date.
  • An overview of Content strategy and how it can guide development.
  • An overview of technical SEO best practices in Drupal.

The presentation is:

  • Session time slot: Sunday 15:15 - 16:00
  • Session room: Room Eyjajallajökull

View the full schedule.

Categories: Drupal

J-P Stacey: Last of the Drupal 8 API blogposts... for now, anyway

21 February 2017 - 4:23am

I've been having tremendous fun writing tutorials about each of the Drupal 8 APIs in turn, and I hope people have been finding them useful. They've certainly been eye-openers for me, as I've always focussed on achieving a clear worked example, and doing that alone unearths all sorts of questions (and usually—but not always—answers) about how Drupal 8's core itself works.

Read more of "Last of the Drupal 8 API blogposts... for now, anyway"

Categories: Drupal

Wim Leers: OpenTracker

20 February 2017 - 1:26pm

This is an ode to Dirk Engling’s OpenTracker.

It’s a BitTorrent tracker.

It’s what powered The Pirate Bay in 2007–2009.

I’ve been using it to power the downloads on http://driverpacks.net since the end of November 2010. >6 years. It facilitated 9839566 downloads since December 1, 2010 until today. That’s almost 10 million downloads!

Stability

It’s one of the most stable pieces of software I ever encountered. I compiled it in 2010, it never once crashed.

wim@ajax:~$ ls -al /data/opentracker total 456 drwxr-xr-x 3 wim wim 4096 Feb 11 01:02 . drwxr-x--x 10 root wim 4096 Mar 8 2012 .. -rwxr-xr-x 1 wim wim 84824 Nov 29 2010 opentracker -rw-r--r-- 1 wim wim 3538 Nov 29 2010 opentracker.conf drwxr-xr-x 4 wim wim 4096 Nov 19 2010 src -rw-r--r-- 1 wim wim 243611 Nov 19 2010 src.tgz -rwxrwxrwx 1 wim wim 14022 Dec 24 2012 whitelist Simplicity

The simplicity is fantastic. Getting up and running is fantastically simple: git clone git://erdgeist.org/opentracker .; make; ./opentracker and you’re up and running. Let me quote a bit from its homepage, to show that it goes the extra mile to make users successful:

opentracker can be run by just typing ./opentracker. This will make opentracker bind to 0.0.0.0:6969 and happily serve all torrents presented to it. If ran as root, opentracker will immediately chroot to . and drop all priviliges after binding to whatever tcp or udp ports it is requested.

Emphasis mine. And I can’t emphasize my emphasis enough.

Performance & efficiency

All the while handling dozens of requests per second, opentracker causes less load than background processes of the OS. Let me again quote a bit from its homepage:

opentracker can easily serve multiple thousands of requests on a standard plastic WLAN-router, limited only by your kernels capabilities ;)

That’s also what it said in 2010. I didn’t test it on a “plastic WLAN-router”, but everything I’ve seen confirms it.

Flexibility

Its defaults are sane, but what if you want to have a whitelist?

  1. Uncomment the #FEATURES+=-DWANT_ACCESSLIST_WHITE line in the Makefile.
  2. Recompile.
  3. Create a file called whitelist, with one torrent hash per line.

Have a need to update this whitelist, for example a new release of your software to distribute? Of course you don’t want to reboot your opentracker instance and lose all current state. It’s got you covered:

  1. Append a line to whitelist.
  2. Send the SIGHUP UNIX signal to make opentracker reload its whitelist1.
Deployment

I’ve been in the process of moving off of my current (super reliable, but also expensive) hosting. There are plenty of specialized HTTP server hosts2 and even rsync hosts3. Thanks to their standardization and consequent scale, they can offer very low prices.

But I also needed to continue to run my own BitTorrent tracker. There are no hosts that offer that. I don’t want to rely on another tracker, because I want there to be zero affiliation with illegal files. This is a BitTorrent tracker that does not allow anything to be shared: it only allows the software releases made by http://driverpacks.net to be downloaded.

So, I found the cheapest VPS I could find, with the least amount of resources. For USD $13.504, I got a VPS with 128 MB RAM, 12 GB of storage and 500 GB of monthly traffic. Then I set it up:

  1. ssh‘d onto it.
  2. rsync‘d over the files from my current server (alternatively: git clone and make)
  3. added @reboot /data/opentracker/opentracker -f /data/opentracker/opentracker.conf to my crontab.
  4. removed the CNAME record for tracker.driverpacks.net, and instead made it an A record pointing to my new VPS.
  5. watched http://tracker.driverpacks.net:6969/stats?mode=tpbs&format=txt on both the new and the old server, to verify traffic was moving over to my new cheap opentracker VPS as the DNS changes propagated
Drupal module

Since driverpacks.net runs on Drupal, there of course is an OpenTracker Drupal module which I wrote. It provides an API to:

  • create .torrent files for certain files uploaded to Drupal
  • append to the OpenTracker whitelist file 5
  • parse the statistics provided by the OpenTracker instance

You can see the live stats at http://driverpacks.net/stats.

Conclusion

opentracker is the sort of simple, elegant software design that makes it a pleasure to use. And considering the low commit frequency over the past decade, with many of those commits being nitpick fixes, it also seems its simplicity also leads to excellent maintainability. It involves the HTTP and BitTorrent protocols, yet only relies on a single I/O library, and its source code is very readable. Not only that, but it’s also highly scalable.

It’s the sort of software many of us aspire to write.

Finally, its license. A glorious license indeed.

The beerware license is very open, close to public domain, but insists on honoring the original author by just not claiming that the code is yours. Instead assume that someone writing Open Source Software in the domain you’re obviously interested in would be a nice match for having a beer with.

So, just keep the name and contact details intact and if you ever meet the author in person, just have an appropriate brand of sparkling beverage choice together. The conversation will be worth the time for both of you.

Dirk, if you read this: I’d love to buy you sparkling beverages some time :)

  1. kill -s HUP pidof opentracker ↩︎

  2. I’m using Gandi’s Simple Hosting↩︎

  3. https://rsync.net ↩︎

  4. $16.34 including 21% Belgian VAT. ↩︎

  5. reload */10 * * * * kill -s HUP pidof opentracker ↩︎

  • DriverPacks.net
  • Drupal
  • deployment
  • open source
Categories: Drupal

Web Wash: How to Create Responsive Image Galleries using Juicebox in Drupal 8

20 February 2017 - 10:53am
There are a lot of image gallery libraries out there, but today I want to show you how to use Juicebox. Juicebox is an HTML5 responsive image gallery and it integrates with Drupal using the Juicebox module. Juicebox is not open source, instead it offers a free version which is fully useable but you are limited to 50 images per gallery. The pro version allows for unlimited images and more features. If you’re looking for an alternative solution look at Slick, which is open source, and it integrates with Drupal via the Slick module. I will cover this module in a future tutorial. In this tutorial, you’ll learn how to display an image gallery from an image field and how to display a gallery using Views.
Categories: Drupal

Chromatic: A Taco-Friendly Guide to Cache Metadata in Drupal 8

20 February 2017 - 6:30am

Explaining Drupal 8's cache metadata with the help of tacos.

Categories: Drupal

Pages