Feed aggregator

OhTheHugeManatee: How to Build a New Source for Drupal Migrate 8

Planet Drupal -

This week I wanted to accomplish a task in Drupal 8 that would be simple in Drupal 7: Import several CSV files, each one related to the others by taxonomy terms. Most importantly, I wanted to do it with Migrate module.

Migrate in Drupal 7 is a fantastic piece of code. It is not designed to be used from the GUI, rather, it provides a framework of “source”, “destination”, and “migration” classes so that even the most convoluted migration is 90% written for you. To create a migration in Drupal 7, you create a custom module, declare your migrations in a hook_info, and then extend the built in “migration” class. You instantiate one of the given classes for the source material (is it a CSV? JSON? Direct connection to a custom DB?), then one of the classes for the destination (is it a content type? Taxonomy term?). Then you add one simple line of code mapping each field from source to destination. If you know what you’re doing, the task I had in mind shouldn’t take more than 15 minutes per source.

It’s not quite so easy in Drupal 8. First of all, with Migrate in core, we had to greatly simplify the goals for the module. The version of Migrate that is really functional and stable is specifically and only the basic framework. There is a separate migrate_drupal module to provide everything you need for migrating from Drupal 6 or 7. This has been a laser-tight focus on just the essentials, which means there’s no UI, very little drush support, and definitely no nice extras like the ability to read non-Drupal sources.

My task this week became to write the first CSV source for Drupal 8 Migrate.

Drupal 8 Migrate Overview

Drupal 8 Migrations, when you’re using classes that already exist, are actually even easier than Migrate 7. All you do is write a single YAML file for each kind of data you’re transferring, and put it in a custom module’s config/install directory. Your YAML file gives your migration a name and a group, tells us what the source is for data, maps source fields to destination fields, and tells us what the destination objects are. Here’s an example Migration definition file from core. See if you can understand what’s being migrated here.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 id: d6_system_site label: Drupal 6 site configuration migration_groups: - Drupal 6 source: plugin: variable variables: - site_name - site_mail - site_slogan - site_frontpage - site_403 - site_404 - drupal_weight_select_max - admin_compact_mode process: name: site_name mail: site_mail slogan: site_slogan 'page/front': site_frontpage 'page/403': site_403 'page/404': site_404 weight_select_max: drupal_weight_select_max admin_compact_mode: admin_compact_mode destination: plugin: config config_name: system.site

You probably figured it out: this migration takes the system settings (variables) from a Drupal 6 site, and puts them into the Drupal 7 configuration. Not terribly hard, right? You can even do data transformations from the source field value to the destination.

Unfortunately, the only sources we have so far are for Drupal 6 and 7 sites, pulling directly from the database. If you want to use Migrate 8 the way we used Migrate 7, as an easy way to pull in data from arbitrary sources, you’ll have to contribute.

Writing a source plugin in Migrate_plus

Enter Migrate Plus module. This is the place in contrib, where we can fill out all the rest of the behavior we want from Migrate, that’s not necessarily a core requirement. This is where we’ll be writing our source plugin.

To add a source plugin, just create a .php file in migrate_plus/src/Plugins/migrate/source . Drupal will discover the new plugin automatically the next time you rebuild the cache. The filename has to be the same as the name of the class, so choose carefully! My file is called CSV.php . Here’s the top of the file you need for a basic :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 <?php /** * @file * Contains \Drupal\migrate_plus\Plugin\migrate\source\csv. */ namespace Drupal\migrate_plus\Plugin\migrate\source; use Drupal\migrate\Plugin\migrate\source\SourcePluginBase; /** * Source for CSV files. * * @MigrateSource( * id = "csv" * ) */ class CSV extends SourcePluginBase {

I’m calling this out separately because for newbies to Drupal 8, this is the hard part. This is all the information that Drupal needs to be able to find your class when it needs it. The @file comment is important. That and the namespace below have to match the actual location of the .php file.

Then you declare any other classes that you need, with their full namespace. To start with all you need is SourcePluginBase.

Finally you have to annotate the class with that @MigrateSource(id=“csv”). This is how Migrate module knows that this is a MigrateSource, and the name of your Plugin. Don’t miss it!

Inside the class, you must have the following methods. I’ll explain a bit more about each afterwards.

  • initializeIterator() : Should return a valid Iterator object.
  • getIds() : Should return an array that defines the unique identifiers of your data source.
  • __toString() : Should return a simple, string representation of the source.
  • fields() : Should return a definitive list of fields in the source.
  • __construct() : You don’t NEED this method, but you probably will end up using it.
initializeIterator()

An Iterator is a complicated sounding word for an Object that contains everything you need to read from a data source, and go through it one line at a time. Maybe you’re used to fopen(‘path/to/file’, ‘r’) to open a file, and then you write code for every possible operation with that file. An iterator takes care of all that for you. In the case of most file-based sources, you can just use the SplFileObject class that comes with PHP.

Any arguments that were passed in the source: section of the YAML file will be available under $this->configuration. So if my YAML looks like this:

1 2 3 source: plugin: csv path: '/vagrant/import/ACS_13_1YR_B28002_with_ann.csv'

My initializeIterator( ) method can look like this:

1 2 3 4 5 6 public function initializeIterator() { // File handler using our custom header-rows-respecting extension of SPLFileObject. $file = new SplFileObject($this->configuration['path']); $file->setFlags(SplFileObject::READ_CSV); return $file; }

Not too complicated, right? This method is called right at the beginning of the migration, the first time Migrate wants to get any information out of your source. The iterator will be stored in $this->iterator.

getIds()

This method should return an array of all the unique keys for your source. A unique key is some value that’s unique for that row in the source material. Sometimes there’s more than one, which is why this is an array. Each key field name is also an array, with a child “type” declaration. This is hard to explain in English, but easy to show in code:

1 2 3 4 5 6 7 public function getIDs() { $ids = array(); foreach ($this->configuration['keys'] as $key) { $ids[$key]['type'] = 'string'; } return $ids; }

We rely on the YAML author to tell us the key fields in the CSV, and we just reformat them accordingly. Type can be ‘string’, ‘float’, ‘integer’, whatever makes sense.

__toString()

This method has to return a simple string explanation of the source query. In the case of a file-based source, it makes sense to print the path to the file, like this:

1 2 3 public function __toString() { return (string) $this->query; } fields()

This method returns an array of available fields on the source. The keys should be the machine names, the values are descriptive, human-readable names. In the case of the CSV source, we look for headers at the top of the CSV file and build the array that way.

__construct()

The constructor method is called whenever a class is instantiated. You don’t technically HAVE to have a constructor on your source class, but you’ll find it helpful. For the CSV source, I used the constructor to make sure we have all the configuration that we need. Then I try and set sane values for fields, based on any header in the file.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 public function __construct(array $configuration, $plugin_id, $plugin_definition, MigrationInterface $migration) { parent::__construct($configuration, $plugin_id, $plugin_definition, $migration); // Path is required. if (empty($this->configuration['path'])) { return new MigrateException('You must declare the "path" to the source CSV file in your source settings.'); } // Key field(s) are required if (empty($this->configuration['keys'])) { return new MigrateException('You must declare the "keys" the source CSV file in your source settings.'); } // Set header rows from the migrate configuration. $this->headerRows = !empty($this->configuration['header_rows']) ? $this->configuration['header_rows'] : 0; // Figure out what CSV columns we have. // One can either pass in an explicit list of column names to use, or if we have // a header row we can use the names from that if ($this->headerRows && empty($this->configuration['csvColumns'])) { $this->csvColumns = array(); // Skip all but the last header for ($i = 0; $i < $this->headerRows - 1; $i++) { $this->getNextLine(); } $row = $this->getNextLine(); foreach ($row as $key => $header) { $header = trim($header); $this->getIterator()->csvColumns[] = array($header, $header); } } elseif ($this->configuration['csvColumns']) { $this->getIterator()->csvColumns = $this->configuration['csvColumns']; } } Profit!

That’s it! Four simple methods, and you have a new source type for Drupal 8 Migrate. Of course, you will probably find complications that require a bit more work. For CSV, supporting a header row turned out to be a real pain. Any time Migrate tried to “rewind” the source back to the first line, it would try and migrate the header row! I ended up extending SplFileObject just to handle this issue.

Here’s the YAML file I used to test this, importing a list of states from some US Census data.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 id: states label: States migration_groups: - US Census source: plugin: csv path: '/vagrant/import/ACS_13_1YR_B28002_with_ann.csv' header_rows: 2 fields: - Id2 - Geography keys: - Id2 process: name: Geography vid: - plugin: default_value default_value: state destination: plugin: entity:taxonomy_term

You can see my CSV source and Iterator in the issue queue for migrate_plus. Good luck, and happy migrating!

Thanks

I learned a lot this week. Big thanks to the Migrate Documentation, but especially to chx, mikeryan, and the other good folks in #drupal-migrate who helped set me straight.

SitePoint PHP Drupal: Automated Testing of Drupal 8 Modules

Planet Drupal -

In this article we are going to look at automated testing in Drupal 8. More specifically, we are going to write a few integration tests for some of the business logic we wrote in the previous Sitepoint articles on Drupal 8 module development. You can find the latest version of that code in this repository along with the tests we write today.

But before doing that, we will talk a bit about what kinds of tests we can write in Drupal 8 and how they actually work.

Simpletest (Testing)

Simpletest is the Drupal specific testing framework. For Drupal 6 it was a contributed module but since Drupal 7 it has been part of the core package. Simpletest is now an integral part of Drupal core development, allowing for safe API modifications due to an extensive codebase test coverage.

Right off the bat I will mention the authoritative documentation page for Drupal testing with Simpletest. There you can find a hub of information related to how Simpletest works, how you can write tests for it, what API methods you can use, etc.

By default, the Simpletest module that comes with Drupal core is not enabled so we will have to do that ourselves if we want to run tests. It can be found on the Extend page named as Testing.

Once that is done, we can head to admin/config/development/testing and see all the tests currently available for the site. These include both core and contrib module tests. At the very bottom, there is also the Clean environment button that we can use if any of our tests quit unexpectedly and there are some remaining test tables in your database.

Continue reading %Automated Testing of Drupal 8 Modules%

Lullabot: Lullabot Named Top Development And Design Agency

Planet Drupal -

Clutch is a research firm that analyzes and reviews software and professional services agencies, covering more than 500 companies in over 50 different markets. Like a Consumer Reports for the agency sector, they do independent research. They publish their results at Clutch.co. Recently, they reviewed Lullabot, interviewing our clients; they created a profile of Lullabot with the results. Lullabot received top marks across the board.

In January, Clutch published a press release listing Lullabot first overall on its international list of web development agencies. We've always been very proud of our work, but it's really amazing to be recognized like this by an independent research firm. In March, Clutch sent out another press release that lists Lullabot as top in Boston-area web design and development agencies. We'll take it!

Clutch also provides matrix-based research results comparing agencies based on focus and ability to deliver. Lullabot floats to the top of both the Top Web Development Companies and the Top Web Design & Development Firms in Boston showing high-focus and the most proven ability to deliver of any agency in the listings.

Since 2006, we've built an incredible team at Lullabot and I'd like to thank all of our employees for their contributions. We've also partnered with scores of magnificant clients over the years. We'd like to thank them all for their trust and collaboration. Of course, Clutch's listings are dynamic and ongoing. We can't sit back and expect to remain in the top position. We will continue to strive to be the best agency we can be, providing superlative results for our clients while continuing to provide a rewarding work environment for our talented team of expert developers, designers, and strategists.

Lullabot Named Top Development And Design Agency

Lullabot -

Clutch is a research firm that analyzes and reviews software and professional services agencies, covering more than 500 companies in over 50 different markets. Like a Consumer Reports for the agency sector, they do independent research. They publish their results at Clutch.co. Recently, they reviewed Lullabot, interviewing our clients; they created a profile of Lullabot with the results. Lullabot received top marks across the board.

In January, Clutch published a press release listing Lullabot first overall on its international list of web development agencies. We've always been very proud of our work, but it's really amazing to be recognized like this by an independent research firm. In March, Clutch sent out another press release that lists Lullabot as top in Boston-area web design and development agencies. We'll take it!

Clutch also provides matrix-based research results comparing agencies based on focus and ability to deliver. Lullabot floats to the top of both the Top Web Development Companies and the Top Web Design & Development Firms in Boston showing high-focus and the most proven ability to deliver of any agency in the listings.

Since 2006, we've built an incredible team at Lullabot and I'd like to thank all of our employees for their contributions. We've also partnered with scores of magnificant clients over the years. We'd like to thank them all for their trust and collaboration. Of course, Clutch's listings are dynamic and ongoing. We can't sit back and expect to remain in the top position. We will continue to strive to be the best agency we can be, providing superlative results for our clients while continuing to provide a rewarding work environment for our talented team of expert developers, designers, and strategists.

Lullabot Named Top Development And Design Agency

Drupal Fire -

Lullabot (via DrupalFire)

Clutch is a research firm that analyzes and reviews software and professional services agencies, covering more than 500 companies in over 50 different markets. Like a Consumer Reports for the agency sector, they do independent research. They publish their results at Clutch.co. Recently, they reviewed Lullabot, interviewing our clients; they created a profile of Lullabot with the results. Lullabot received top marks across the board.

In January, Clutch published a press release listing Lullabot first overall on its international list of web development agencies. We've always been very proud of our work, but it's really amazing to be recognized like this by an independent research firm. In March, Clutch sent out another press release that lists Lullabot as top in Boston-area web design and development agencies. We'll take it!

Clutch also provides matrix-based research results comparing agencies based on focus and ability to deliver. Lullabot floats to the top of both the Top Web Development Companies and the Top Web Design & Development Firms in Boston showing high-focus and the most proven ability to deliver of any agency in the listings.

Since 2006, we've built an incredible team at Lullabot and I'd like to thank all of our employees for their contributions. We've also partnered with scores of magnificant clients over the years. We'd like to thank them all for their trust and collaboration. Of course, Clutch's listings are dynamic and ongoing. We can't sit back and expect to remain in the top position. We will continue to strive to be the best agency we can be, providing superlative results for our clients while continuing to provide a rewarding work environment for our talented team of expert developers, designers, and strategists.

Noz Urbina Explains Adaptive Content

Drupal Fire -

Lullabot (via DrupalFire)

In this episode, Jeff Eaton talks to Content Strategist Noz Urbina about Adaptive Content and the changing face of customer engagement. What does "omni-channel" mean? Is it more than a buzzword? What steps can organizations take to prepare for it? Spoiler Alert: It all relies on well-modeled content… Along the way, they discuss the storied history of structured content, the challenge of effective content personalization, and the existential horror of old-school WYSIWYG editors.

Noz Urbina Explains Adaptive Content

Lullabot -

In this episode, Jeff Eaton talks to Content Strategist Noz Urbina about Adaptive Content and the changing face of customer engagement. What does "omni-channel" mean? Is it more than a buzzword? What steps can organizations take to prepare for it? Spoiler Alert: It all relies on well-modeled content… Along the way, they discuss the storied history of structured content, the challenge of effective content personalization, and the existential horror of old-school WYSIWYG editors.

Drupal Association News: They’re back! Personalized membership certificates are here.

Planet Drupal -

We all like to show our love for Drupal, and over the past few years, we’ve let Drupal show it loves you! Due to popular demand, we are bringing back a fun gift to Drupal Association members -- personalized certificates of membership. In 2014, we delivered these downloadable certificates to over 600 members and we hope to break this record during the months of May and June this year.

Join as a member or renew your current membership anytime before June 30 and you’ll receive a personalized certificate of membership.

Sign me up

This is a token of our gratitude for your support of Drupal and the community. Thanks for everything you do for Drupal.

Personal blog tags: Membership

BlackMesh: DrupalCon LA has 5 dedicated sprint days. Should you be there? YES!

Planet Drupal -

What is a Sprint? Sprints are times dedicated to focused work on a project or topic. People in the same location (physical space, IRC, certain issue pages) work together to make progress, remove barriers to completion, and try to get things to "done". The goal is to get an issue to Reviewed and Tested By the Community (RTBC), and keep it there. (Keeping it there means quickly addressing feedback, like when a someone moves an issue back from RTBC to Needs Work, or Needs Review.)

Instead of a person working by themselves on many things, we work together, with others, on a few things to get them done. We do not measure success by the number of patches posted. We measure success by the reviews we do, issue summaries we update, change records we post, and the number of issues we get to RTBC.

DrupalCon is a supportive environment to begin contributing Though sprints might sound intimidating, the sprints at DrupalCon have a history of both informal and formal ways for integrating new contributors in this process. If you have experience with Drupal, then you have the skills we need to help with contribution to the Drupal project. And, DrupalCon is the most supportive environment to start your contribution journey. Who? We welcome project managers, bug reporters, site builders, themers, QA testers, writers to help with documentation, accessibility specialists, usability specialists, developers, and contributors to other open source projects to help fix upstream bugs. When?
  • Extended sprints begin Saturday, May 9 and Sunday, May 10 at an off-site location: IndieDesk.
  • Monday, May 11, sprints at the conference venue in room Room 408AB run concurrently with the community summit and other trainings.
  • There is a lounge for work all throughout the event at the venue in Room 408AB, and off-site which is open 24 hours at the Westin Bonaventure Hotel in the Ballroom on 3rd floor.
  • Then Friday, May 15 is the most awesome sprint day which you should not miss an hour of.
  • Followed by more extended sprints at IndieDesk Saturday, May 16 and Sunday, May 17.
Why should you sprint? Sprinting with others allows barriers to contributing to be removed in real time. You will learn a lot just by sitting at a table with others and seeing how they work. Having others see how you work, might result in them giving you time saving tips that will help you contribute and... might also help when you return to your regular routine after the sprint. It is fun. You will get to network and meet the real human people who work on Drupal itself. Sprints include some down time. We have to eat! Conversations at lunch and dinner can be both enjoyable and eye opening. Finally, trust that you do have skills that will be appreciated at the sprints. We are really good and finding ways for everyone to contribute. Topics In addition to generally "contributing", there are some specific topics in Core, Contrib modules, themes, and infrastructure with people organizing work in those areas and gathering others to collaborate with them. Core Some of the focus for Core during the DrupalCon sprints will be:
  • Getting D8 done
  • Multilingual
  • Front-end United
Getting D8 done For getting D8 done, there are different ways of being involved. One way, is working on D8 criticals. Read the page on helping with Drupal 8. Angie Byron (webchick) is also giving a session to update people on the status of the current criticals. We are also looking for experienced contributors join a group of people who will triage issues with the priority of Major. (We are still working on instructions for doing the major triage. Join us at the event!) Multilingual The best way to get involved with the Drupal 8 Multilingual Initiative (D8MI) is to start on the D8MI website. And then look at the issues we are currently focusing on. Jump right in, or come by our weekly meeting in IRC in the #drupal-i18n channel. The next meeting is May 6th at 4pm UTC. Front-end United Front-end United people will be working on: CSS, JavaScript, Twig, UX, themes, the theme system, markup, and stuff! Contrib Some of the focus for Contrib during the DrupalCon sprints will be:
  • Content Staging in D8
  • Media in D8
Content Staging in D8 Information about content staging in Drupal 8 is on the deploy project page. Media in D8 Current focus for media is on entity_embed, entity_browser, media_entity and fallback_formatter. Work is happening in the drupal-media project on github. The presentation by Chandan Singh has a recent update. Drupal.org Drupal.org is running on Drupal 7. If you are familiar with Drupal 7 and do notwant to dive into Drupal 8 yet, you can still really help with the release of Drupal 8, by working on Drupal.org itself. Drupal.org has a lot of projects where it tracks issues. There are 42 Drupal.org related projects which each have their own issue queue. searching for the d.o hitlist tag (across all projects) yields a list of issues that are relevant for the sprint. Infrastructure The big push for infrastructure right now, includes blockers to Drupal 8. Issue: [meta] Drupal.org (websites/infra) blockers to a Drupal 8 release has lots of details, but can be a little overwhelming to dive into. Confersations happen in IRC in the #drupal-infrastructure channel. One of the blockers is the new testbot Continuous Integration system (testbot CI 2.0). There are 7 projects related to DrupalCI. DrupalCI: Modernizing Testbot Initiative is the main overall project. And updates and confersations happen in the Drupal.org Testing Infrastructure groups.drupal.org group and in IRC in the #drupal-testing channel. Sign-up Signup to help with a topic, or lead a topic in the DrupalCon LA sprint spreadsheet.

Photo credit: Jeremy Thorson

DrupalSprints

Redesigning CloudFlare

Cloudflare Blog -

CloudFlare’s original interface grew at an amazing speed. Visually, it hadn't changed much since CloudFlare’s launch in 2010. After several years of new features, settings, and ancillary UIs buried beneath clicks, it became clear that the user experience was lacking and would only get worse as we continued to add features. The question became: How could we make a UI that was versatile, scalable, and consistent?
If you haven’t yet, make sure you read Matthew’s post about the philosophy behind our new interface. This post will go into the details and the thought process behind designing our new dashboard.

Why a redesign? We needed versatility for a growing variety of users and devices

As CloudFlare has grown, we now have a large variety of customers spanning four very different plan levels. We needed an interface that would work well for both the casual owner of a single blog, an agency managing many client sites, and enterprise customers that demand ultimate control. Also, the rise of responsive design was something we wanted to take seriously — the dashboard should be versatile enough to work just as well on every device.

We needed a platform that we could build upon

We couldn’t shove new features into a ‘gear menu’ forever. We needed a navigation metaphor that would be scalable, as well as a consistent visual framework to make the development of new features easier, faster, and more easily understood by the user. We had big plans for new features when we started out; I’ll go into some of them below.

We needed consistency with a more mature brand

The CloudFlare brand has grown and evolved in the past several years. During the redesign process, we updated our visual identity system with new fonts, color palettes, and imagery for our business cards, printed items, booth displays, and videos. Our new dashboard is another step toward a newer, cleaner look.

The process A new concept

Starting with a clean slate, we had the ability to completely rethink the information architecture and visual hierarchy of the interface. Keeping years of user feedback in mind, it was time to sketch out some ideas. Below is a small sampling of many sketches that were made early in the process:

Apps

With a layout framework started, the concept of categorizing our settings and features started to take shape. These categories evolved into ‘apps' as we noticed the visual similarity of the navigation row to today’s smartphones. It also fit with the concept of adding third party apps (something we’re going to be implementing soon) to apps provided by CloudFlare. Using apps as the beginning of our framework, we had a hierarchy: a user would select a website, have a clear list of CloudFlare and third party apps, and whichever app was selected, specific settings and features would be displayed.

Modules

As our navigation solidified around the idea of apps, we got down to the smaller pieces. Within apps we put ‘modules’ that encapsulate each setting. As the name implies, these modules are modular — they’re made of several pieces that lock together creating a consistent look across the UI, even when used in a variety of ways. We decided that each module would contain a name and description, as well as a collapsible panel at the bottom. Some modules would feature a “control area” on the right side. Other more complicated modules could contain data tables, or even be a combination of both data tables and controls. Take a look at the dashboard the next time you log in and you’ll see them in their many variations.

One of the biggest improvements we wanted to integrate was inline help content. No more going off to other tabs to learn more about a setting. Help content is contained in a collapsible panel that can be expanded for further reading. We also plan on using this collapsible panel for other module-specific content, like API information, in the future.

Responsive design

We started this design process with a goal of making every CloudFlare feature adjustable from your phone. The modules mentioned above were designed to resize and reflow to your device size, allowing you to easily control CloudFlare settings for your websites. Checking the performance of your web site should be possible from a desktop machine and while running between meetings. And while it might be a bit crazy to set up an SSL certificate via your phone, but we definitely don’t want to stop you!

The new look

We established a new style guide for the dashboard with new fonts, colors, and interface elements like buttons, toggles, and select menus. When trying to make everything fully responsive, high-density display ready, and overall more performant, we decided to throw out all images with lots of drop shadows, gradients, and noise that made up our old buttons and controls and focused on making everything out of CSS. The results are a crisper, cleaner look, and a faster load.

We also created a custom icon set to use for our app icons and buttons, as well as in some new illustrations that we use to introduce a little fun here and there.

Just the beginning

This new dashboard gives us a platform to deliver more features to users while continually evolving the UI itself with greater ease. What you see today is only a fraction of what we hope to do going forward, and this isn’t the only thing getting a refresh. As Matthew hinted, our old marketing site will be getting a facelift, and a new support site is in the works. Stay tuned!

If you think our design process is something you'd like to take part in, we’re hiring.

Code Karate: More control over your Drupal Admin menu with Administration Menu Source

Planet Drupal -

Episode Number: 205

Sometimes you have a situations where your normal Drupal administration menu just won’t cut it. Maybe you have someone that needs to perform some administrative tasks on your site such as managing content and comments, or perhaps something more complex such as managing the Drupal blocks. This person might be a technical wizard, but there is also a good chance that they might not be. In fact, they might be the person in the office that calls you when their “computer is broke”.

Tags: DrupalDrupal 7Site BuildingDrupal PlanetSite Administration

The Connectivity Atlas

Drupal Fire -

Development Seed (via DrupalFire)

We have recently launched the first iteration of the Connectivity Altas, a project that centers around mapping infrastructures on a global scale. From roads and rivers to internet and electricity lines, these intricate and vast networks exist everywhere we are. Considering that infrastructure is a broad classification, mapping out the different systems provides a unique insight into how these systems are dispersed onto the globe. Since this was our first significant dive into Mapbox GL, We wanted to share some notes about our experience.

The problem

During our initial work on the project, we encountered a number of challenges associated with our workflow. I originally designed the map in Mapbox Studio importing each layer into Studio as a separate data source and styling them using Catro CSS. This workflow worked fine for a while, but overtime might have led to hundreds of sources and styles pushing the limit of our Mapbox account and our organizational skills.

The solution

We began to consider alternative workflows. Ultimately, we decided to move the project into Mapbox GL for various reasons.

  • We like vector tiles (super crisp)
  • We like rendering styles in the browser (it makes for faster styling / instant results)
  • Better organization, we used a jekyll collection to add styles into a master JSON
  • CartoCSS allows for more precise styling as well as other features that came in handy.

What we learned

Vector tile platorms (like GL) are the future of maps on the web. There are some limitations right now, but we’re looking forward to using GL for other projects. For example, we had to write our own tooltip functionality to expose the meta inforamtion in each layer, but we know the Mapbox GL folks are cooking up some code to help with that in future releases.

A collaborative effort

All of the data on the Connectivity Atlas is open and available for reuse. The intention is for this to be a collaborative project where you can help by sharing and suggesting data to add. This way we can produce a map of profound inter-connectedness as well as an oddly beautiful web of global infrastructure.

DrupalCon News: Join us for Trivia Night Sponsored by Palantir.net

Planet Drupal -

For us, DrupalCon is the most fun time of the year. There’s nothing better than getting together with our friends, colleagues, and community to work and celebrate together.   While the sessions, BOFs, and other work-focused moments are indelibly important, the bonds we build and the friendships we make are just as critical to the continued growth and success of the project. That’s why we'd like to invite you out to Trivia Night sponsored by Palantir.net.  

Matthew Tift: What I Learned about Drupal at a Go/Rust User Group

Planet Drupal -

What I Learned about Drupal at a Go/Rust User Group

Last night I had the pleasure of attending the first joint meeting of Minnesota Go and Rust users, and arrived home inspired -- not just by Go and Rust, but also about Drupal and its community.

Attending a wide variety of local meetups is something I really enjoy. Since I moved back to the Twin Cities area nearly seven years ago, I have attended meetings related to PHP, Linux, Concrete5, NodeJS, .NET, JavaScript, Flash, and more. Each of these groups has a unique community and way of doing things, although just about every one of them involves pizza, beer, and predominantly white, male participants.

Given the fact that Rust and Go are both C-like low-level languages, it might not come as a surprise that this Go/Rust user group meeting was quite technical. There were three presentations and lots of terminals on the big screen. The first speaker introduced Rust by illustrating the process for generating the Fibonacci sequence. The end result looked something like this:

struct Fibonacci { curr: u32, next: u32, } impl Iterator for Fibonacci { type Item = u32; fn next(&mut self) -> Option { let new_next = self.curr + self.next; self.curr = self.next; self.next = new_next; Some(self.curr) } } fn fibonacci() -> Fibonacci { Fibonacci { curr: 1, next: 1 } } fn main() { for i in fibonacci().take(30) { println!("{}", i); } }

At other local meetups I have attended, this could have made for a dry, boring talk. However, at this Go/Rust meetup, each aspect of this Fibonacci program was followed by remarkably sophisticated audience questions and answers about language architecture, Rust's underlying assumptions, and frequent references to how Rust compared to C, Python, Go, and other languages. I learned a lot and found it very entertaining. (Incidentally, while I personally prefer Go, I think this is a great article comparing Go and Rust -- the author likes Rust).

I have attended a lot of DrupalCon and DrupalCamp sessions over the past five years or so, and I don't recall any of them feeling like this Go/Rust meetup. Perhaps there are a lot of more technical sessions and I just avoided them. Perhaps sessions like the (Drupal) Core Conversations are very technical, but I just don't notice it as much. Whatever the case, these Rust and Go talks got me thinking about Drupal and its community.

Drupal meetings, especially in the Twin Cities, tend to be focused on bringing in new users and not leaving anyone out of the conversations. That often means less technical presentations. Furthermore, every year at the Twin Cities DrupalCamp we have made it an explicit goal to welcome new users into our community.

Getting off the Drupal island to go to this Go/Rust group was a nice reminder of just how much Drupal lets me do without ever having to think about these low-level issues. For comparison, in PHP (Drupal is written in PHP), we might do something more simpler looking to create the Fibonacci series:

$fib = [1,0]; for ($i = 0; $i < 30; $i++) { $next = array_sum($fib); array_shift($fib); array_push($fib,$next); echo $next.', '; }

Or perhaps more relevant is the fact that I can just spin up a Drupal blog for one of my friends or one of my kids, easily download themes to radically change the appearance, and quickly add sophisticated integrations without writing code. And at that point get on with my hacking, or not. My code, my data, my content. Sometimes I lose track of that when I'm working on a project with teams of people I've never met, testing my code in ways I never would have anticipated, making spectacularly complex, cool websites.

The Go/Rust meetup had the unexpected effect of reminding me that Drupal can be very laid-back and non-technical, and that the web can be the same. Not all websites will need the sophistication of Drupal 8's fancy new configuration system, and its ability to facilitate development, testing, and production environments. Drupal allows me to come home, emboldened by a meetup, and quickly jot down my unfiltered, half-baked thoughts for all the world to see, without having to think about the complexities of immutable references or garbage collection. This Drupal site lets me spill out these ideas in short order.

As Drupal becomes an increasingly capable and accommodating entrance onto the wonderfully diverse information superhighway, it's nice to be reminded once in a while of the fact that Drupal also can do a darn good job of hiding complexity and letting us get on with creating and managing our content of all shapes, sizes, and qualities.

Tags: drupaldrupal planetgorustcommunity

Beyond Decoupling: The Inherent Virtues of an API

Lullabot -

Fellow Lullabot Andrew Berry has written an article on why to decouple. If you do go this route, it’s because you’ve thought a lot about how to separate concerns. Content consumers are separated from content producers. Front-end developers are freed from the dictates of a back-end CMS. This article isn't about the separation of concerns, but rather what lies at the middle of all of these concerns— your HTTP API.

Beyond Decoupling: The Inherent Virtues of an API

Drupal Fire -

Lullabot (via DrupalFire)

Fellow Lullabot Andrew Berry has written an article on why to decouple. If you do go this route, it’s because you’ve thought a lot about how to separate concerns. Content consumers are separated from content producers. Front-end developers are freed from the dictates of a back-end CMS. This article isn't about the separation of concerns, but rather what lies at the middle of all of these concerns— your HTTP API.

Lullabot: Beyond Decoupling: The Inherent Virtues of an API

Planet Drupal -

Fellow Lullabot Andrew Berry has written an article on why to decouple. If you do go this route, it’s because you’ve thought a lot about how to separate concerns. Content consumers are separated from content producers. Front-end developers are freed from the dictates of a back-end CMS. This article isn't about the separation of concerns, but rather what lies at the middle of all of these concerns— your HTTP API.

Pages

Subscribe to Cruiskeen Consulting LLC aggregator