Feed aggregator

LevelTen Interactive: Choosing the Best CMS for Your Marketing Team

Planet Drupal -

Oftentimes, when we receive inbound leads from companies looking for a new website or new website redesign, we get a list of wants and needs and how fast and how much it will cost, but the potential client and we forget the people that will be using the platform the most.

WHO REALLY  USES THE WEBSITE?

It is no surprise that marketing teams own the internet site once it is completed. As I sit here and write this...Read more

Beyond Discovery: Designing a More Valuable Phase One

Lullabot -

If you’ve ever hired an agency to redesign, re-platform or otherwise do a bunch of work on your organization’s website, you’ve likely had to consider whether to pay for an initial phase of work some agencies refer to as “Discovery.” What follows are some reasons why you were right to be nervous about investing in something called discovery, but more importantly, what you should look for in a phase one with any agency to ensure that you lay the foundations for success and get a great return on your investment.

What is "Discovery" and where did it come from?

As far as I can tell, the use of the word “discovery” within professional services finds its origin in the practice of law. In legal practice,

[discovery] is the formal process of exchanging information between the parties about the witnesses and evidence they’ll present at trial. —the American Bar Association

I know what you’re thinking. Web designers and developers probably began using this term in the hopes of charging rates like attorneys. While there are definite corollaries between legal discoveries and the kinds of things that need to happen in any large digital project (e.g. the exchange of information to get everyone on the same page), it’s worth noting that our field is borrowing a term that describes a process for creating a fair fight. That isn't exactly the way I like to think about my client projects.

Also, the word discovery, based on its origins, alludes to simply an exchange of information, but not really the production of anything. It’s about finding things out so that you can then begin charting a course. It’s about input, not output.

Don’t get me wrong, discovery activities in and of themselves are valuable and necessary for most projects. The larger the undertaking, the more valuable they become. Discovery activities include things like:

  • The sharing and review of existing guiding documentation (e.g. style guides, personas, wikis, analytics)
  • Requirements gathering
  • Technical infrastructure review and analysis
  • The review of roles and responsibilities within a stakeholder group
  • The review and analysis of project repositories and assets
  • Inventories and audits of existing content, assets, resources, design patterns, etc.

These are all important things that you should want the vendor you’re working with to facilitate, but I’m guessing your team and your project sponsors may feel nervous, even disappointed if this is all they’re being promised in phase one.

Why agencies propose "discovery" phases and what's missing

If you’ve gotten a proposal that defines a discovery phase, in all likelihood, it provided a price for this initial phase that’s clear, but for the rest of your project is less clear. I know this because I’ve helped write many of these proposals. Often one of the “deliverables” of a discovery phase will be some sort of project plan that outlines a more narrowed cost estimate for the entire project. Prior to the discovery phase, the proposal may provide what’s referred to in the industry as a SWAG, or a ballpark range for the entire project to help you assess whether the vendor is at least within the ballpark of the budget you’re working with.

This is very typical for larger scale digital projects. If you’ve ever received a proposal like this, you may have been disappointed but not surprised to see that the proposal did not include an exact, fixed price for the entire project. It’s more important to feel confident that the vendor you’re choosing can be trusted to deliver something that’s successful within your budget. Ironically, at least at Lullabot, what we’re also looking for as we create project proposals is to feel confident that we can deliver success within your budget. However, if you’ve never worked with us and we’ve never worked with you, a mutual leap of faith is required.

Many agencies try to solve for the discomfort caused by discovery phase proposals by making the discovery phase as small and cheap as possible—the bare minimum needed to do just enough to feel somewhat confident in an estimate. Some even offer the discovery phase for free if the project itself is large enough to warrant the risk. I’m guessing if you’ve considered a proposal like this that you may have appreciated the cost consideration, but if the discovery phase did not appear to create anything particularly valuable for you and your team, you were probably still reluctant to invest the time in it. I’ve found that most of the clients we work with are just as busy as we are. If you’re hiring an agency right now to help you redesign or re-platform a large site, you likely don’t want your team to invest a bunch of time and energy in a discovery process, no matter how cheap, with a vendor you may not wind up working with, only to find yourself back reviewing proposals like this again. From day one, you want to find a partner you can trust to see you through to a successful launch.

So what’s the solution? If the lack of an exact estimate isn’t the biggest problem to solve, and making discovery phases smaller and cheaper also misses the needs and concerns prospective clients have, then what should we propose in these scenarios?

Moving beyond discovery and into design

A couple of years ago I was working with a prospective client to iron out an initial phase one engagement. They had a corporate intranet they were embarrassed by. Their organization was growing fast and needed to continue attracting top talent. Their existing intranet was terrible for onboarding new employees. It also looked like a historical artifact rather than an intranet for one of the world’s most innovative tech companies. After about three or four rounds of proposal revisions in which they kept saying this was not quite what they were looking for, I had the brilliant idea to just ask them “What are the things you need to have to get your team and the project sponsors excited and confident in the project by the end of phase one?”

What I discovered was that, as an organization, they understood that they needed a better understanding of the problems to be solved, and they understood that would require some research work, but our phase one proposal was essentially just research work. What was really valuable for their team was not just understanding all the problems more clearly, but rather seeing a vision for how to solve those problems. We did not need to simply understand things; we needed to make things based on that understanding. That would get their team excited and give them visual things to show their CEO and project sponsors who ultimately needed to get behind the investment in the project. That would even help them assess the value of the project and hence their budget. We were not certain exactly what we’d be designing and building, and therefore we did not feel confident providing a fixed estimate for the entire project. They did not know exactly what they needed, and therefore had no way to assess their budget based on value.

This is one of those things that seems so obvious in hindsight. As designers, it’s easy to know the amazing insights and game-changing ideas that can come out of initial research and forget that, while that’s all great and true, it’s the actual designs that solve the problems (even the problems we just feel but don’t clearly understand) that get people excited. As designers, we get excited about these insights because they’re the eureka moments that lead to the designs our clients rave about. Our clients want those designs that they’ll rave about.

The good news in the situation I just described was that the client was not saying they needed us to do the whole project as phase one. Nor were they saying they saw no value in the research and discovery-oriented activities we needed to do at the outset. They realized that the project was large enough that we couldn’t really describe and estimate it accurately without starting somewhere.

What we did was to simply end phase one at the point where we had produced what they were all eager to see; the initial designs for what their intranet should be like. We went from proposing a phase one that was just user research and discovery activities to a phase one that also included workshopping that produced wireframes and initial visual design ideas for a few key page types. Our early research and workshopping helped establish what page types were actually most important to success (e.g. Their employee dashboard at login and a couple other highly used content types and tools). Phase one got bigger by one or two weeks but produced things that were really valuable for our client.

Since that project, we’ve taken this approach to designing engagements with every new client. When a project warrants a phase one, our proposal process tries to establish the earliest things that are hugely valuable to the client team (usually via collaboration with that team). It’s not always the same things, but most phase one engagements seem to include the following kinds of things now:

  • Discovery activities (see above)
  • Lightweight research (user-research: both internal and external, market research, etc.)
  • Design workshopping to produce a plan in the form of models, diagrams, wireframes, and Zoom Mocks (see below)
Design workshopping: producing value quickly To achieve great things, two things are needed: a plan, and not quite enough time. — Leonard Bernstein

We try to keep phase one as brief as possible, but ensure that by the end we've produced the initial designs for what we’re planning to create together. One of the huge benefits of including some actual design work in an intentionally-brief phase one is that the time constraint can provide amazing focus and clarity. It will force your team to quickly zero in on the things that are most important to your site’s users and your business.

While our initial research and discovery activities provide hugely valuable insights, they also typically raise questions. Decisions (or the lack of them) are what most often slow down design projects. There are teams of people involved, each with their own areas of focus and concerns. While user research and testing can certainly help guide decisions, even with these tools there are often several directions a given product or interface can go in. If you hire a professional design team, you may be thinking they will simply answer all these questions for you, but that’s not typically how it works. We’ve found that one of the keys to a successful project is the ability to arrive quickly at the early, foundational decisions together. We achieve this through design workshopping.

The concept of design workshopping is not something we invented. Our team has been doing this for years, and we’ve refined a lot over the years by learning from others. Kevin Hoffman has shared a lot over the years, and the book GameStorming has also been helpful. Recently Google Ventures’ book Sprint seems to articulate a slightly more formal, start-up focused version of the kinds of things we’ve been doing as well.

At its heart, design workshopping is about getting all the various roles and perspectives together in one place for collaborative exercises aimed at making initial design decisions together. Though we’re a fully distributed team at Lullabot, we almost always do these design workshops in-person. We fly a few of our people to wherever our client is and spend two to three days on-site together workshopping. We design the workshopping agenda together with our clients in the weeks leading up so that it fits with the various schedules of the client team we’re working with. Each day is divided up into workshopping sessions. The sessions are pretty brief (thirty minutes to an hour each), and no one stakeholder or team member needs to be in all of them (which would be impossible for most of our client teams). While no two projects are identical in their needs, some of the common things we focus on in our workshops include:

  • The existing pain points and problems to be solved as your team and users see them
  • Reframing those problems into prioritized goals and how to measure them
  • Your project and product’s constraints: political, technical, staff, resources and assets, brand, etc.
  • The competitive landscape for your product or brand
  • Your audience and its various segments, scenarios, needs, and priorities
  • Your content and its model, priorities, creation/editorial processes and governance
  • Your site and its IA, interface, patterns, page types, layouts and their respective priorities
  • Your brand and its characteristics, visual style, values and personality
  • The project process and your team's needs and values regarding phases, artifacts, deliverables, cadence, communication, etc.
  • Possible layouts and interface approaches to solve the problems and achieve the goals

Our workshops aren’t just conversations about these topics. We use a combination of methods and exercises to help elicit insights and drive decision making. Some of the more common methods we employ include:

  • Card sorts (often multi-axis)
  • Sticker voting (often in combination with a card sort)
  • Metaphor games
  • Gut checks
  • Design Studio sketching exercises

In one of Tom Wujec’s Ted Talks, he shares stories from an exercise he’s done with lots of business people where he has them draw how to make toast. At about five minutes into the talk he shares what he found when he began having groups do this exercise together, and he mentions a fascinating thing. When he had groups do the exercise together in complete silence they did it “much better and much more quickly!”

It never ceases to amaze me how you can get 5-10 people from an organization in a room and spend hours in conversation about challenges and goals for a project and still not arrive at a clear decision. However, when you apply the constraints of a “game” and give people set time limits, letting them work both individually and collaboratively, moving things physically in space to express things like importance, potential impact, level of effort required, etc., you can get that entire group to arrive at decisions together in less than an hour. Turning things from purely verbal, mental work into something physical and visual is hugely powerful!

Likewise, it can be incredibly difficult to articulate in words exactly what you don’t like about your existing site, or how you want your new site to feel. Instead, walking teams through metaphors with visuals and letting them describe why they think their sign-up process should feel like checking in at a W hotel rather than a Marriott, or why their non-profit organization’s brand is actually more like a Volvo than a Mercedes, can unlock so many more useful descriptive words and ideas to define what we need to create together.

While the decision making that happens in these workshops is often what blows away our clients initially, it’s the visual ideas that come out of our sketching exercises that put it all together. By the end of our workshops we have sketched wireframes for the key page or component types of a given site, and often our clients have helped produce these sketches. We’ve found that most project teams at the organizations we work with have at least some ideas for how to solve the problems on their site, and sketching is a great way to engage those ideas together.

undefined

Typically, within a week after our workshopping, we’ve gathered together more refined versions of the things that document and visualize all the decisions we made together; things like goals and metrics, site maps and phase diagrams, IA and content models, wireframes and even Zoom Mocks that increase the visual fidelity showing style ideas that reflect the brand feel we’ve described together with metaphors. We have things we’re ready to test with real users and then iterate on to create a successful end product. What's more, we've continued to find these briefs can radically ease the onboarding of new team members later in a project or even to a product team after launch.

What have you found?

We’re always learning and refining, looking for better ways to design engagements so that they provide the greatest value to our clients and lead to successful outcomes. We’ve found that turning phase one from being just an exchange of information, discovery process into a process that produces ready-to-test designs to be a big win for our clients and us. We’d love to hear from you. If you’ve hired a design and development team to work on your project, we’d love to hear about what worked well and what you’d like to change on your next engagement. Drop us a line and share your thoughts. We’d greatly appreciate it!

Tameesh Biswas | Blog: GSoC17 : Client Side File Crypto : week 8

Planet Drupal -

GSoC17 : Client Side File Crypto : week 8

This blog post summarises the eighth week of writing open-source code for Drupal with Google Summer of Code. 

This week I nearly completed the final encryption JS script and moved to the decryption part of the module that is the last major functional component.

tameeshb Wed, 07/26/2017 - 13:23 Tags GSoC Google Summer of Code 2017 Drupal Drupal Blog

Love Huria: Keeping It Clean: Coding Standards That Matter

Planet Drupal -

A year back, I was working on a project that taught me how to keep my code clean, modular, reusable, and all those terms that seem fancy, but are actually good for you in the long run. Interesting? Yeah a bit.

But what did I do after getting into those practices?

I made mistakes. Believe me, a lot of them. But with every mistake, I learnt a lot of stuff that I had never considered before. It helped me in my thinking process, on how we should build things, what steps we need to consider when we are developing/extending a...

Acquia Lightning Blog: Acquia Doctrine dependencies

Planet Drupal -

Acquia Doctrine dependencies Adam Balsam Tue, 07/25/2017 - 15:07

We started receiving reports of broken Lightning builds due to the release of doctrine/common:2.8.0 and/or doctrine/inflector:1.2.0 which require php ~7.1 and php ^7.0 respectively.

Lightning actually doesn't have a direct dependency on anything under the doctrine namespace. The dependencies come from drupal/core. So should drupal/core constrain doctrine/common to <=2.7.3 so that it continues to support php 5.6? No.

If you follow the dependency tree for what happens when you run composer update for a Lightning project in a php 5.6 environment, it looks like this:

  • acquia/lightning:2.1.7 requires:
  • drupal/core:~8.3.1, drupal/core:8.3.5 requires:
  • doctrine/common:^2.5, doctrine/common:2.8.0 requires php ~7.1, so it will resolve to 2.7.3, which requires:
  • doctrine/inflector:1.*, doctrine/inflector:1.2.0 requires php:^7.0, so it will resolve to 1.1.0, which simply requires php:>=5.3.2

So why are we getting reports of broken builds?

The problem arises when:

  1. Your project commits its composer.lock file (which it generally should)
  2. Your development environment has a different php version than your CI or production/test environment

If you have php 7.0 installed locally, the dependency resolution for doctrine/inflector will look like this:

  • acquia/lightning:2.1.7 requires:
  • drupal/core:~8.3.1, drupal/core:8.3.5 requires:
  • doctrine/common:^2.5, doctrine/common:2.8.0 requires php ~7.1, so it will resolve to 2.7.3, which requires:
  • doctrine/inflector:1.*, which will resolve to doctrine/inflector:1.2.0

Which will lock doctrine/inflector to v1.2.0; which requires php ^7.0. Then when you push to your php 5.6 CI environment, you'll get an error like this:

Problem 1
    - Installation request for doctrine/inflector v1.2.0 -> satisfiable by doctrine/inflector[v1.2.0].
    - doctrine/inflector v1.2.0 requires php ^7.0 -> your PHP version (5.6.24) does not satisfy that requirement.
Problem 2
    - doctrine/inflector v1.2.0 requires php ^7.0 -> your PHP version (5.6.24) does not satisfy that requirement.
    - doctrine/common v2.7.3 requires doctrine/inflector 1.* -> satisfiable by doctrine/inflector[v1.2.0].
    - Installation request for doctrine/common v2.7.3 -> satisfiable by doctrine/common[v2.7.3].

The solution, of course, is to run composer update in a dev environment that matches your CI/test/production environment.

Net Neutrality Day: Cloudflare + Fight for the Future

Cloudflare Blog -

For Net Neutrality Day on July 12, Fight for the Future (FFTF) launched a Cloudflare App installable for websites all over the world. Sites with it installed saw as many as 178 million page views prompting the users to write to their local congressional representative on the importance of Net Neutrality. All told, the FCC received over 2 million comments and Congress received millions of emails and phone calls.

Screenshot of App Page for FFTF’s Battle for the Net app. Source code for this app.

When our co-founders launched Cloudflare in 2011, it was with a firm belief that the Internet is a place where all voices should be heard. The ability for either an ISP or government to censor the Internet based on their opinions or a profit motive rather than law could pose a huge threat to free speech on the Internet.

Cloudflare is a staunch supporter of Net Neutrality and the work done by Fight for the Future, which shows how effective Internet civic campaigns can be.

To get a heads up on Fight for the Future campaigns in the future, sign up for their mailing list.

See source code for FFTF’s Battle for the Net Cloudflare App on Github.

To make your own app, see Cloudflare Apps docs.

Xeno Media: WordPress coding standards for the Drupal developer

Planet Drupal -

If you've been doing Drupal development for any amount of time, chances are that you have installed the Drupal Code to help you write clean, compliant code. Coder allows you to check your Drupal code against the Drupal coding standards and other best practices using PHP_CodeSniffer.  It can be configured to work in your IDE, and also works on the command line.

Writing code according to standards helps avoid common errors, and helps teams understand the code faster.

I installed Coder using Composer per the well written instructions.  Using this method installs it globally, so I can use it on all of my projects, and installs all the dependencies, including PHP_CodeSniffer.

I recently was tasked with working on a Wordpress site, and I started looking into the WordPress Coding Standards.  My setup didn't jive with the standard installation method since I already had PHP_CodeSniffer installed globally using composer.  I had to do a little digging to add these additional standards to my already installed setup.

Here is a quick recap on how to install Coder using composer.

Install Coder composer global require drupal/coder

To make the commands available globally, add this line to your .~/bash_profile, and that it is sourced (or restarted your terminal).

# Composer recommended PATH export PATH="$PATH:$HOME/.composer/vendor/bin"

Tell phpcs where the Drupal and DrupalPractice standards are located:

phpcs --config-set installed_paths ~/.composer/vendor/drupal/coder/coder_sniffer

Verify it worked with:

phpcs -i

You should see:

The installed coding standards are MySource, PEAR, PHPCS, PSR1, PSR2, Squiz, Zend, Drupal, and DrupalPractice

You can now navigate to your Drupal project and run the following command to use:

phpcs --standard=Drupal file.nameInstall Wordpress Coding Standards

Thanks to some help I found in the issue queue, here are the steps to install the Wordpress Coding Standards globally using composer.

composer global require wp-coding-standards/wpcs:dev-master

Again, to make these commands available globally, make sure you have this line in your ~/.bash_profile, and that it is sourced (or restarted your terminal).

# Composer recommended PATH export PATH="$PATH:$HOME/.composer/vendor/bin"

Like we did with Drupal, we need to tell phpcs where the Wordpress standards are located. We use the same installed_paths configuration set, and use a comma to list both the Drupal and Wordpress paths.

phpcs --config-set installed_paths $HOME/.composer/vendor/drupal/coder/coder_sniffer,$HOME/.composer/vendor/wp-coding-standards/wpcs

Verify it worked with:

phpcs -i

You should now see:

The installed coding standards are MySource, PEAR, PHPCS, PSR1, PSR2, Squiz, Zend, Drupal, DrupalPractice, WordPress, WordPress-Core, WordPress-Docs, WordPress-Extra and WordPress-VIP

You can now navigate to your Wordpress project and run the following command to use:

phpcs --standard=Wordpress file.nameAdd aliases

If you've worked with me, or read my posts before, you know I love aliases. They streamline your process and help make you more productive. Add these aliases into your .bash_profile, .bashrc, or wherever you keep your aliases, and source it, or restart your terminal.

alias drupalcs="phpcs --standard=Drupal --extensions='php,module,inc,install,test,profile,theme,css,info,txt,md'" alias wpcs="phpcs --standard=Wordpress"

After this you can simply type drupalcs folder_name or wpcs file.name and start writing better code!

Acknowledgements

Thanks to Micheal Porter, Albert Jankowski, and Mike Acklin for the technical review of this article, and to all the maintainers!

Photo by Ilya Pavlov on Unsplash

DrupalCon News: Reserve your room for DrupalCon Vienna

Planet Drupal -

For DrupalCon Vienna, our partner hotel, Courtyard Vienna Prater, is located in the Trabrennstraße area, where you can explore St. Stephen's Cathedral and Vienna's famous Prater park. And, the hotels we chose are perfect hubs for connecting you to a rewarding DrupalCon experience.

The fun is where the Drupalers are. Stay with us at a partner hotel to network and socialize after sessions end.

ARREA-Systems: Usage of ClamAV in Drupal 8

Planet Drupal -

Usage of ClamAV in Drupal 8 Tue, 07/25/2017 - 17:17

This is an example of anti-virus implementation with an Ubuntu server.

Our back office management solution allows users to upload files in various sections of the application for storage or file sharing. For this reason, checking of files for virus is an important advantage.

We use the ClamAV module integration from Drupal 8.

 

1) Install ClamAV on Ubuntu

Installation on Ubuntu server is straight forward.  However, it is better to install with clamav-daemon clamav-freshclam options for later settings

Agiledrop.com Blog: AGILEDROP: Top Drupal 8 Modules

Planet Drupal -

Last time, we have looked at the most popular Drupal modules. There are around 12 000 modules available for Drupal 7 and 3 000 for Drupal 8, of whom only 1 000 are in a stable version. Not so much as some would perhaps expect. However a lot of them make our lives easier each day, so this time we will look at the top Drupal 8 modules. Firstly, we must point out that modules that were already used in the blog post Most popular Drupal modules will be left out. Namely, we already presented, which are available for Drupal 8 and their popularity makes them useful for the newest version of Drupal… READ MORE

Freelock : How do you keep a high bar of quality on dozens of sites every day?

Planet Drupal -

DevOps is the union of development, operations, and quality assurance -- but it's really the other way around. You start with the quality -- developing tests to ensure that things that have broken in the past don't break in the future, making sure the production environment is in a known, fully reproducible state, and setting protections in place so you can roll back to this state if anything goes wrong.

DevOpsBehavior Driven DevelopmentDrupalWordPressContinuous DeploymentContinuous IntegrationDrupal Planet

Lullabot: Merging Entities During a Migration to Drupal 8

Planet Drupal -

Migrations provide an excellent opportunity to take stock of your current content model. You’re already neck deep in the underlying structures when planning for data migrations, so while you’re in there, you might as well ensure the new destination content types will serve you going forward and not present the same problems. Smooth the edges. Fill in some gaps. Get as much benefit out of the migration as you can, because you don’t want to find yourself doing another one a year from now.

This article will walk through an example of migrating part of a Drupal 7 site to Drupal 8, with an eye toward cleaning up the content model a bit. You will learn:

  • To write a custom migrate source plugin for Drupal 8 that inherits from another source plugin.
  • To take advantage of OO inheritance to pull field values from other entities with minimal code.
  • To use the Drupal 8 migrate Row object to make more values available in your migration yaml configuration.
Scenario: A music site moving from Drupal 7 to Drupal 8

Let’s say we have a large music-oriented website. It grew organically in fits and starts, so the data model resembles a haphazard field full of weeds instead of a well-trimmed garden. We want to move this Drupal 7 site to Drupal 8, and clean things up in the process, focusing first on how we store artist information.

Currently, artist information is spread out:

  • Artist taxonomy term. Contains the name of the artist and some other relevant data, like references to albums that make up their discography. It started as a taxonomy term because editors wanted to tag artists they mentioned in an article. Relevant fields:

    • field_discography: references an album content type.
       
  • Artist bio node. More detailed information about the artist, with an attached photo gallery. This content type was implemented as the site grew, so there was something more tangible for visitors to see when they clicked on an artist name. Relevant fields:
     
    • field_artist: term reference that references a single artist taxonomy term.
    • field_artist_bio_body: a formatted text field.
    • field_artist_bio_photos: a multi-value file field that references image files.
    • field_is_deceased: a boolean field to mark whether the artist is deceased or not.
Choosing the Migration’s Primary Source

With the new D8 site, we want to merge these two into a single node type. Since we are moving from one version of Drupal to another, we get to draw on some great work already completed.

First, we need to decide which entity type will be our primary source. After some analysis, we determine that we can’t use the artist_bio node because not every Artist taxonomy term is referenced by an artist_bio node. A migration based on the artist_bio node type would leave out many artists, and we can’t live with those gaps.

So the taxonomy term becomes our primary source. We won’t have an individual migration at all for the artist_bio nodes, as that data will be merged in as part of the taxonomy migration.

In addition to the migration modules included in core (migrate and migrate_drupal), we’ll also be using the migrate_plus module and migrate_tools.

Let’s create our initial migration configuration in a custom module, config/install/migrate_plus.migration.artists.yml.

id: artists label: Artists source: plugin: d7_taxonomy_term bundle: artist destination: plugin: entity:node bundle: artist process: title: name type: plugin: default_value default_value: artist field_discography: plugin: iterator source: field_discography process: target_id: plugin: migration migration: albums source: nid

This takes care of the initial taxonomy migration. As a source, we are using the default d7_taxonomy_term plugin that comes with Drupal. Likewise, for the destination, we are using the default fieldable entity plugin.

The fields we have under “process” are the fields found on the Artist term, though we are just going to hard code the node type. The field_discography assumes we have another migration that is migrating the Album content type.

This will pull in all Artist taxonomy terms and create a node for each one. Nifty. But our needs are a bit more complicated than that. We also need to look up all the artist_bio nodes that reference Artist terms and get that data. That means we need to write our own Source plugin.

Extending the Default Taxonomy Source Plugin

Let’s create a custom source plugin, that extends the d7_taxonomy_term plugin.

use Drupal\taxonomy\Plugin\migrate\source\d7\Term; use Drupal\migrate\Row; /** * * @MigrateSource( * id = "artist" * ) */ class Artist extends Term { /** * [email protected]} */ public function prepareRow(Row $row) { if (parent::prepareRow($row)) { $term_id = $row->getSourceProperty('tid'); $query = $this->select('field_data_field_artist', 'fa'); $query->join('node', 'n', 'n.nid = fa.entity_id'); $query->condition('n.type', 'artist_bio') ->condition('n.status', 1) ->condition(fa.field_artist_tid, $term_id); $artist_bio = $query->fields('n', ['nid']) ->execute() ->fetchAll(); if (isset($artist_bio[0])) { foreach (array_keys($this->getFields('node', 'artist_bio')) as $field) { $row->setSourceProperty($field, $this->getFieldValues('node', $field, $artist_bio[0]['nid'])); } } } } }

Let’s break it down. First, we see if there is an artist_bio that references the artist term we are currently migrating.

$query = $this->select('field_data_field_artist', 'fa'); $query->join('node', 'n', 'n.nid = fa.entity_id'); $query->condition('n.type', 'artist_bio') ->condition('n.status', 1) ->condition(fa.field_artist_tid', $term_id);

All major D7 entity sources extend the FieldableEntity class, which gives us access to some great helper functions so we don’t have to write our own queries. We utilize them here to pull the extra data for each row.

if (isset($artist_bio[0])) { foreach (array_keys($this->getFields('node', 'artist_bio')) as $field) { $row->setSourceProperty($field, $this->getFieldValues('node', $field, $artist_bio[0]['nid'])); } }

First, if we found an artist_bio that needs to be merged, we are going to loop over all the field names of that artist_bio. We can get a list of all fields with the FieldableEntity::getFields method.

We then use the FieldableEntity::getFieldValues method to grab the values of a particular field from the artist_bio.

These field names and values are passed into the row object we are given. To do this, we use Row::setSourceProperty. We can use this method to add any arbitrary value (or set of values) to the row that we want. This has many potential uses, but for our purposes, the artist_bio field values are all we need.

Using the New Field Values in the Configuration File

We can now use the field names from the artist_bio node to finish up our migration configuration file. We add the following to our config/install/migrate_plus.migration.artists.yml:

field_photos: plugin: iterator source: field_artist_bio_photos process: target_id: plugin: migration migration: files source: fid 'body/value': field_artist_bio_body 'body/format': plugin: default_value default_value: plain_text field_is_deceased: field_is_deceased

The full config file:

id: artists label: Artists source: plugin: d7_taxonomy_term bundle: artist destination: plugin: entity:node bundle: artist process: title: name type: plugin: default_value default_value: artist field_discography: plugin: iterator source: field_discography process: target_id: plugin: migration migration: albums source: nid field_photos: plugin: iterator source: field_artist_bio_photos process: target_id: plugin: migration migration: files source: fid 'body/value': 'field_artist_bio_body/value' 'body/format': plugin: default_value default_value: plain_text field_is_deceased: field_is_deceased Final Tip

When developing custom migrations with the Migrate Plus module, configuration is stored in the config/install of a module. This means it will only get reloaded if the module is uninstalled and then installed again. The config_devel module can help with this. It gives you a drush command to reload a module’s install configuration.

Merging Entities During a Migration to Drupal 8

Lullabot -

Migrations provide an excellent opportunity to take stock of your current content model. You’re already neck deep in the underlying structures when planning for data migrations, so while you’re in there, you might as well ensure the new destination content types will serve you going forward and not present the same problems. Smooth the edges. Fill in some gaps. Get as much benefit out of the migration as you can, because you don’t want to find yourself doing another one a year from now.

This article will walk through an example of migrating part of a Drupal 7 site to Drupal 8, with an eye toward cleaning up the content model a bit. You will learn:

  • To write a custom migrate source plugin for Drupal 8 that inherits from another source plugin.
  • To take advantage of OO inheritance to pull field values from other entities with minimal code.
  • To use the Drupal 8 migrate Row object to make more values available in your migration yaml configuration.
Scenario: A music site moving from Drupal 7 to Drupal 8

Let’s say we have a large music-oriented website. It grew organically in fits and starts, so the data model resembles a haphazard field full of weeds instead of a well-trimmed garden. We want to move this Drupal 7 site to Drupal 8, and clean things up in the process, focusing first on how we store artist information.

Currently, artist information is spread out:

  • Artist taxonomy term. Contains the name of the artist and some other relevant data, like references to albums that make up their discography. It started as a taxonomy term because editors wanted to tag artists they mentioned in an article. Relevant fields:

    • field_discography: references an album content type.
       
  • Artist bio node. More detailed information about the artist, with an attached photo gallery. This content type was implemented as the site grew, so there was something more tangible for visitors to see when they clicked on an artist name. Relevant fields:
     
    • field_artist: term reference that references a single artist taxonomy term.
    • field_artist_bio_body: a formatted text field.
    • field_artist_bio_photos: a multi-value file field that references image files.
    • field_is_deceased: a boolean field to mark whether the artist is deceased or not.
Choosing the Migration’s Primary Source

With the new D8 site, we want to merge these two into a single node type. Since we are moving from one version of Drupal to another, we get to draw on some great work already completed.

First, we need to decide which entity type will be our primary source. After some analysis, we determine that we can’t use the artist_bio node because not every Artist taxonomy term is referenced by an artist_bio node. A migration based on the artist_bio node type would leave out many artists, and we can’t live with those gaps.

So the taxonomy term becomes our primary source. We won’t have an individual migration at all for the artist_bio nodes, as that data will be merged in as part of the taxonomy migration.

In addition to the migration modules included in core (migrate and migrate_drupal), we’ll also be using the migrate_plus module and migrate_tools.

Let’s create our initial migration configuration in a custom module, config/install/migrate_plus.migration.artists.yml.

id: artists label: Artists source: plugin: d7_taxonomy_term bundle: artist destination: plugin: entity:node bundle: artist process: title: name type: plugin: default_value default_value: artist field_discography: plugin: iterator source: field_discography process: target_id: plugin: migration migration: albums source: nid

This takes care of the initial taxonomy migration. As a source, we are using the default d7_taxonomy_term plugin that comes with Drupal. Likewise, for the destination, we are using the default fieldable entity plugin.

The fields we have under “process” are the fields found on the Artist term, though we are just going to hard code the node type. The field_discography assumes we have another migration that is migrating the Album content type.

This will pull in all Artist taxonomy terms and create a node for each one. Nifty. But our needs are a bit more complicated than that. We also need to look up all the artist_bio nodes that reference Artist terms and get that data. That means we need to write our own Source plugin.

Extending the Default Taxonomy Source Plugin

Let’s create a custom source plugin, that extends the d7_taxonomy_term plugin.

use Drupal\taxonomy\Plugin\migrate\source\d7\Term; use Drupal\migrate\Row; /** * * @MigrateSource( * id = "artist" * ) */ class Artist extends Term { /** * [email protected]} */ public function prepareRow(Row $row) { if (parent::prepareRow($row)) { $term_id = $row->getSourceProperty('tid'); $query = $this->select('field_data_field_artist', 'fa'); $query->join('node', 'n', 'n.nid = fa.entity_id'); $query->condition('n.type', 'artist_bio') ->condition('n.status', 1) ->condition(fa.field_artist_tid, $term_id); $artist_bio = $query->fields('n', ['nid']) ->execute() ->fetchAll(); if (isset($artist_bio[0])) { foreach (array_keys($this->getFields('node', 'artist_bio')) as $field) { $row->setSourceProperty($field, $this->getFieldValues('node', $field, $artist_bio[0]['nid'])); } } } } }

Let’s break it down. First, we see if there is an artist_bio that references the artist term we are currently migrating.

$query = $this->select('field_data_field_artist', 'fa'); $query->join('node', 'n', 'n.nid = fa.entity_id'); $query->condition('n.type', 'artist_bio') ->condition('n.status', 1) ->condition(fa.field_artist_tid', $term_id);

All major D7 entity sources extend the FieldableEntity class, which gives us access to some great helper functions so we don’t have to write our own queries. We utilize them here to pull the extra data for each row.

if (isset($artist_bio[0])) { foreach (array_keys($this->getFields('node', 'artist_bio')) as $field) { $row->setSourceProperty($field, $this->getFieldValues('node', $field, $artist_bio[0]['nid'])); } }

First, if we found an artist_bio that needs to be merged, we are going to loop over all the field names of that artist_bio. We can get a list of all fields with the FieldableEntity::getFields method.

We then use the FieldableEntity::getFieldValues method to grab the values of a particular field from the artist_bio.

These field names and values are passed into the row object we are given. To do this, we use Row::setSourceProperty. We can use this method to add any arbitrary value (or set of values) to the row that we want. This has many potential uses, but for our purposes, the artist_bio field values are all we need.

Using the New Field Values in the Configuration File

We can now use the field names from the artist_bio node to finish up our migration configuration file. We add the following to our config/install/migrate_plus.migration.artists.yml:

field_photos: plugin: iterator source: field_artist_bio_photos process: target_id: plugin: migration migration: files source: fid 'body/value': field_artist_bio_body 'body/format': plugin: default_value default_value: plain_text field_is_deceased: field_is_deceased

The full config file:

id: artists label: Artists source: plugin: d7_taxonomy_term bundle: artist destination: plugin: entity:node bundle: artist process: title: name type: plugin: default_value default_value: artist field_discography: plugin: iterator source: field_discography process: target_id: plugin: migration migration: albums source: nid field_photos: plugin: iterator source: field_artist_bio_photos process: target_id: plugin: migration migration: files source: fid 'body/value': 'field_artist_bio_body/value' 'body/format': plugin: default_value default_value: plain_text field_is_deceased: field_is_deceased Final Tip

When developing custom migrations with the Migrate Plus module, configuration is stored in the config/install of a module. This means it will only get reloaded if the module is uninstalled and then installed again. The config_devel module can help with this. It gives you a drush command to reload a module’s install configuration.

Vardot: Top 10 Free Drupal Themes

Planet Drupal -

Top 10 Free Drupal Themes Dmitrii Susloparov Mon, 07/24/2017 - 11:57

As of July 2017, there are 1500+ themes registered with the Drupal project. The sheer number of choices makes the selection of a theme difficult for most newcomers to Drupal. Some Drupal themes are free while the rest are known as being premium, i.e., they are available for a fee. Sometimes you can save more money by investing in a paid theme, but this topic we’ll cover in another article. This one lists the top 10 free Drupal themes, each of them in our opinion is a great choice for a beginning sitebuilder.

Are you a Drupal newcomer? Use our learning guide to become a guru!

Best Free Drupal Themes: Selection criteria

The main question when compiling the list of our proposed themes was how to make the comparison fair and objective. After much discussion, we decided that a theme must satisfy the following basic criteria for it to be considered in the list of top 10 Drupal themes:

 

  1. It must be free.

  2. It must run on either Drupal 7 or Drupal 8 (or better, both).

  3. It must be actively maintained and developed.

  4. It must be covered by the Drupal security advisory policy.
    Coverage under the policy does not guarantee that a theme is free of vulnerabilities. Rather, it means that the theme has been reviewed for any publicly known vulnerabilities by the Drupal security team.

  5. It must be for general purpose.
    Some Drupal themes are designed for specific industries, e.g., restaurant. For the purpose of this list, only general purpose themes are considered.

  6. It must be responsive.

A responsive theme adjusts its layout to accommodate different screen sizes and resolutions. This is a basic requirement for today's mobile platforms.

  1. It must run out-of-the-box.

There are themes, and there are theme frameworks (also known as base themes). A theme framework is like a blank canvas with tools which a theme developer uses to build a custom theme. The top 10 list only contains Drupal themes which one can use out-of-the-box as feature-complete themes.

 

In the course of conducting this study, it was observed that a small number of organizations have each generated a relatively large number of themes, albeit good ones, that are only marginally different. If an organization makes multiple but similar quality Drupal themes, only representative themes may be selected for inclusion in the following theme set. The individual or organization responsible for a theme is identified below in brackets.

 

Anyway, we have kept you in suspense for too long already. Based on the above criteria, the top 10 free Drupal themes are:

 

  • BlueMasters (by More than Themes)

  • Corporate Clean (by More than Themes)

  • Danland (by DanPros)

  • Business (by Devsaran)

  • Nexus (by Devsaran)

  • Zircon (by WeebPal)

  • Business Responsive Theme (by Zymphonies)

  • Drupal8 Zymphonies (by Zymphonies)

  • Fontfolio (by Marios Lublinski)

  • Integrity (by knackforge)

 

Below, we discuss each theme in more detail.

BlueMasters

 

BlueMasters is a popular WordPress theme that has been ported to the Drupal platform by More Than Themes. We recommend this theme, not just on its features only, but that it is maintained by More Than Themes, a solid well-reputed organization in the Drupal community. The theme supports a maximum layout of 12 regions. A region is the primary layout unit to which a component block can be placed. Therefore, the more regions a theme supports, the more customizable it is. With this Drupal theme, you can display a slideshow on the front page, and partition information into either 2 or 3 columns on a web page. In addition, you can organize and access your contents via multi-level dropdown menus. BlueMasters, however, is only available on Drupal 7.

Corporate Clean

 

Like BlueMasters, Corporate Clean is a theme ported to Drupal by More Than Themes. We recommend this theme because it offers a unique feature that is missing in many free Drupal themes, namely, a color scheme selector. Most free themes have a fixed color scheme which means that you cannot change the color of a button or the page background. With Corporate Clean, you can adjust the color of some screen elements. This theme supports 1-column, 2-column as well as 3-column layout. Multi-level drop-down menus and slideshows are also supported. The Corporate Clean theme only runs on Drupal 7.

Danland

 

We recommend Danland because, among the Drupal themes on this top 10 list, it gives you the most flexibility to fine tune the layout of your web page. Specifically, it supports a maximum of 26 regions, the highest number on the list. The layout can have 1, 2, or 3 columns. Danland runs on Drupal 6, 7, and 8.

Business

 

In terms of the major features, the Business theme is at par with other themes on the list. We recommend the theme because of the finer feature details. For example, the slideshow feature allows the display of up to 5 images. Note that some free Drupal themes only allow a maximum of 3. Also, the Business theme has a color module, which is missing in most free themes. You can specify one of 6 fixed colors for web components. The Business theme is available for Drupal 7 and 8. However, the Drupal 7 version is not responsive, and is currently in maintenance mode only. The Drupal 8 version, on the other hand, is being actively developed, and is fully responsive.

Nexus

 

Nexus is arguably the most visually appealing theme on the top 10 list. The clean design together with the solid support by Devsaran, its maintainer organization, put Nexus on the list. The theme runs on both Drupal 7 and 8 with the Drupal 8 version being a pre-release version only. The layout can have a maximum of 15 regions, which is average on the top 10 list. You can specify a 1-column or 2-column design on the layout. The slideshow feature supports a maximum of 3 images.

Zircon

 

If your Drupal website is rich in images, then you should definitely consider using Zircon as the theme. You will be delighted by its slideshow, slider, as well as carousel features. You can run Zircon on both Drupal 7 and 8. However, the current Drupal 8 version has remained as a release candidate since November 2015. The Zircon layout supports 18 regions in 3 columns.

Business Responsive

Not all themes on the top 10 list support Drupal 8. Even for those which do, some are in pre-release status only. If you are looking for a stable Drupal 8 theme, you should consider the Business Responsive theme which has reached the 1.0 stable release status. This theme supports 17 regions in 1-column, 2-column, or 3-column layouts. It also has a slider feature, but installing the feature requires some manual steps after installing the theme. This theme supports the use of social media icons for popular platforms such as Facebook, Twitter, Google+, LinkedIn, and Pinterest. You can install this theme on both Drupal 7 and 8.

Drupal8 Zymphonies

 

 

If you want a stable Drupal 8 theme that offers more bells and whistles than the Business Responsive theme, Drupal8 Zymphonies comes highly recommended. This theme is, fittingly, only available on Drupal 8. It shares many features with other themes on the top 10 list, such as multi-level menus and 1/2/3-column layout. It distinguishes itself by offering 22 regions for placing blocks, the second highest on the theme list. Also, you can customize the Zymphonies credit link, all supported social media links, and the title and description fields in the main banner.

Fontfolio

 

If your website is multilingual, you should definitely consider Fontfolio because it offers easy setup for links to webpages in all supported languages. Like BlueMasters, this theme is a popular WordPress theme that has been ported to Drupal. Fontfolio can run on both Drupal 7 and 8. Note that some existing features of the Drupal 7 version are still under development for the Drupal 8 version. Fontfolio supports a maximum of only 8 regions in its layout, the fewest on the list. Yet, overall, it is a simple but elegant Drupal theme that includes a 2-column responsive design.

Integrity

 

If you want a simple no-frills theme that just works out-of-the-box, Integrity may be your choice. It is a Drupal 8 only theme. Its feature set is, in general, at par with the rest of the themes. Integrity supports multi-level menus and slideshows that display up to 5 images. The layout includes a 3-column design. The theme has defined 17 regions into which Drupal blocks can be placed.

Summary & Conclusion

Drupal has a wealth of good free themes. Each of them is ideal for Drupal users who have relatively simple requirements and want to try something other than the default theme. If a free theme cannot fully satisfy your particular requirements, then you may want to use its premium alternative or even to hire a professional Drupal agency that can assist you with your needs.

 

Which theme do you like the most among our top 10 choices? Perhaps, you have your own favourite theme that is not on our list. What are the goals of your project and what kind of theme are you looking for? Share with us your thoughts in the comments section below!

Glassdimly tech Blog: Config Management Roundup

Planet Drupal -

Quite the problem—Drupal config management on local and prod.

Drupal 8 can be quite punctilious: it will simply refuse to work if there's a mismatch between database and config objects on the filesystem.

So... how do we manage two sets of configurations—one for local, and one for production?

The Problem

I have modules like varnish installed on production that shouldn't be enabled on local, and modules that are enabled on local that shouldn't be enabled on production.

Pages

Subscribe to Cruiskeen Consulting LLC aggregator