Aug 24 2019
Aug 24

Greg Anderson, Open Source Contributions Engineer at Pantheon joins Mike Anello to talk about the Drupal Community's Composer Support in Core Initiative.

Discussion

DrupalEasy News

Upcoming Events

Sponsors

  • Drupal Aid - Drupal support and maintenance services. Get unlimited support, monthly maintenance, and unlimited small jobs starting at $99/mo.
  • WebEnabled.com - devPanel.

Follow us on Twitter

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Jul 12 2019
Jul 12

If you build Drupal 8 sites using the Drupal Composer/Drupal Project Composer template (DCDP), then you've likely noticed the development dependency webflo/drupal-core-require-dev. If you're like me, you probably didn't give it much thought the first 20 or 30 times you used the template. 

After a while though, I started to dig deeper into the details of DCDP, wanting to be able to understand exactly how it worked and what customizations I may want to make. DCDP was really my first real exposure to Composer, and the more I learned, the more I wanted to learn (as is often the case). My curiosity led me to this drupal-core-require-dev rabbit hole.

Some background

First, let's level-set ourselves - when you run either "composer install" or "composer create-project" (which is actually calling "composer install" as well) without the "--no-dev" switch, Composer will install all dependencies listed in your composer.json file in both the "require" and "require-dev" sections (as well as dependencies of dependencies). If you take a look at DCDP, you'll notice that in the "require-dev" section, there is one entry: webflo/drupal-core-require-dev. 

So, as most folks who start Drupal 8 projects using the recommended DCDP command listed in the README (composer create-project drupal-composer/drupal-project:8.x-dev some-dir --no-interaction), Composer is installing everything in the "require" and "require-dev" sections - including webflo/drupal-core-require-dev.

What exactly is webflo/drupal-core-require-dev? Well, it is a "virtual" dependency - meaning it doesn't include any code, rather it just includes a composer.json file that specifies the specific versions of Drupal core development ("require-dev") dependencies that are used to run Drupal core tests. The interesting (and sometimes problematic bit) is that webflo/drupal-core-require-dev doesn't specify any versions for non-development ("require") dependencies. If you take a look at Drupal core's composer.json file, you'll see that for the most part, specific versions of dependencies aren't specified - rather a range is. 

This leads to the situation where a project built with webflo/drupal-core-require-dev could have different dependency versions (as long as they adhere to the version constraints is Drupal core's composer.json) than what comes with Drupal core if you had just downloaded it from drupal.org.

For example, if on the date version 8.7.0 of Drupal core was released one of the development dependencies was at version 1.3.1, then that is the version that is provided with Drupal core 8.7.0 downloaded from drupal.org regardless of when you download it. But, when using the DCDP as-is, if since the release of Drupal core 8.7.0 the development dependency was updated to 1.3.2, then when the project is installed using "composer create-project", your project will be using version 1.3.2 of the dependency. While this seems minor, it has led to some issues

Also - be aware that there are different versions of webflo/drupal-core-require-dev for every minor version of Drupal core. So, if you're updating your site from Drupal core 8.6.x to 8.7.x, then you must also update to webflo/drupal-core-require-dev to 8.7 as well. This is the reason the update command for DCDP includes webflo/drupal-core-require-dev:composer update drupal/core webflo/drupal-core-require-dev "symfony/*" --with-dependencies

After learning this, I had an obvious question: what's the advantage of having Composer install updated versions of Drupal core dependencies? The only thing I found was that if you're a core or contrib developer, then it would be useful to know if your code breaks using updated dependencies. I'm hard-pressed to think of another reason when this makes sense. For most Drupal 8 projects, I think it would be beneficial to use the exact dependencies that the particular version of Drupal core ships with. This way, we can be 100% certain that our project has the same dependency versions that the community's testing infrastructure has validated for the particular version. Luckily, that's what webflo/drupal-core-strict is for. 

It works almost the exact same way as webflo/drupal-core-require-dev except that it includes exact versions for all dependencies of Drupal core - for both development ("require-dev") and non-development ("require") packages. The exact versions are the ones that have been tested and are included in the "official" version of Drupal core (for each minor version) downloadable from drupal.org. Like webflo/drupal-core-require-dev, there is a minor version of webflo/drupal-core-strict for each minor version of Drupal core.

So, why does DCDP use webflo/drupal-core-require-dev? Well, there's some debate about if it should or not. 

As a side-note, if you host on Pantheon, and use their Pantheon-flavored version of DCDP, then you're probably already using webflo/drupal-core-strict.

Starting a project with DCDP using webflo/drupal-core-strict

First, the bad news - if you want to start a new project using webflo/drupal-core-strict, you can't use DCDP out-of-the-(virtual)-box. But, there's a couple of possibilities. At first glance, it seems that you could fork DCDP, make the relevant change to webflo/drupal-core-strict in the composer.json file, then use "composer create-project" on your fork. But, this would also require posting your fork on Packagist (which is discouraged), updating your fork's README (for the create-project and update commands) as well as keeping your fork up-to-date with any DCDP updates. I wouldn't recommend this method.

A better option is to use the "--no-install" option of Composer's "create-project" command:

1.  Use the recommended command on the DCDP page, but add a "--no-install" at the end of it:

composer create-project drupal-composer/drupal-project:8.x-dev some-dir --no-interaction --no-install

This will download DCDP to your local, but not install dependencies. 

2.  Edit the composer.json file with:

  • New project name
  • New project description
  • Remove "webflo/drupal-core-require-dev" from the "require-dev" section
  • Add "webflo/drupal-core-strict": "^8.7.0", to the "require" section (ensure the version matches drupal/core).
  • Change the version requirement for drupal/console to: "drupal/console": "^1.0", (to avoid version conflicts)
  • Change the version requirement for drush/drush to: "drush/drush": "^9.0", (to avoid version conflicts)
  • Remove "composer/installers" from the "require" section (it is already specified in webflo/drupal-core-strict). 

3.  Run "composer install". 

You'll need to remember that when you want to update Drupal core, you'll want to use the following command (instead of what is in the DCDP README):

composer update drupal/core webflo/drupal-core-strict "symfony/*" --with-dependencies

If you're not crazy about either of these two options, there is a third (future?) - leave a comment on this issue and ask for webflo/drupal-core-strict to be used in DCDP. 

Change an existing project from webflo/drupal-core-require-dev to webflo/drupal-core-strict

What if you already have a project based on DCDP and you want to change it from using webflo/drupal-core-require-dev to webflo/drupal-core-strict? Here's some possible ways of doing it:

As always, to be safe, please test things like this on a copy of your project.

Method one: manually downgrade dependencies

This is definitely a tedious process. It involves first removing webflo/drupal-core-require-dev using:

composer remove webflo/drupal-core-require-dev

Then, attempt to require drupal-core-strict:

composer require webflo/drupal-core-strict:^8.7.0

Depending on a number of factors you're likely to get a bunch of "Your requirements could not be resolved to an installable set of packages." messages. How many you get is mostly a result of the length of time since the previous minor release of Drupal core - the longer it has been, the more dependencies have probably been updated. For each dependency listed, you'll need to downgrade it using something like:

composer require symfony/yaml:3.4.26

What is happening is that webflo/drupal-core-require-dev allows dependencies to get upgraded outside of the Drupal core release timeline, while webflo/drupal-core-strict does not. So, you'll need to downgrade dependencies that have been updated. You'll have to do it one-at-a-time - try requiring webflo/drupal-core-strict, see the error message, downgrade the offending dependency, then repeat. In some cases, it isn't immediately obvious which dependency needs to be downgraded, or which version it needs to be downgraded to, so be prepared to use the "composer depends" command a few times. 

Eventually, requiring webflo/drupal-core-strict will succeed and you'll know that you're done.

There is one major downside to this method though - by requiring specific versions of each dependency, the versions are effectively pinned in the composer.json file. So, the next time you update Drupal core (and webflo/drupal-core-strict), these specific version constraints will conflict with the updated webflo/drupal-core-strict. One solution would be to remove all of these dependencies from the "require" section of your composer.json file. 

Method two: rebuilding your codebase

If Method one is tedious and precise, then this method is more of a (less tedious) big hammer. Depending on the complexity of your codebase, this might be a better option for simpler projects. In short, make a copy of your composer.json (for reference), then use "composer remove" to remove dependencies on drupal/core, webflo/drupal-core-require-dev, and anything that depends on them. Then, use "composer require" to add back drupal/core and webflo/drupal-core-strict: 

composer require webflo/drupal-core-strict:^8.7.0 drupal/core:^8.7.0

Then, add back (composer require) all the dependencies you had to remove. Be sure to add back the same versions of each dependency (this includes Drupal profiles, modules, and themes!) to end up where you were when you started. Once everything is back, then you'll probably want to "relax" the version constraints of your dependencies in your composer.json by adding a "^". For example, if you re-add a contrib module using:

composer require drupal/pathauto:8.1.3

Then in the "require section" of your composer.json you'll have:

"drupal/pathauto": "8.1.3",

This will prevent drupal/pathauto from being updated. So, you'll want to change this to:

"drupal/pathauto": "^8.1.3",

Method three: delete and update

While researching this topic, I posted an issue in the webflow/drupal-core-require-dev queue and Greg Anderson was kind enough to offer another method:

[One] solution is to modify your composer.json file, attach the same version limit to drupal/core and drupal-core-strict (e.g. ^8.7.3) to limit what [composer update] needs to look at, and then [delete] both your composer.lock and your vendor directory and run "composer update".

One caveat about this method is that it will update everything. Any outstanding dependency updates (including Drupal profiles, modules, and themes) will be applied (unless you constrain them in your composer.json). Here's what Greg suggests:

  • Pin your contrib modules that are not updated to an exact version in composer.json.
  • Remove vendor and composer.lock, add webflo/drupal-core-strict [to your composer.json], and generate a new lock file [with "composer update"].
  • Remove the pins of your contrib modules in your composer.json by adding ^ [similar to the example in the previous method.]
  • Run composer update --lock

Method four: ???

Is there an easier way to do this? If so, I'd love to hear about it. Let me know in a comment below.

Which to use?

So which one should you use? If all your contrib projects are up-to-date, then I'd go with Method 3. If not, then I'd recommend Method 2 or 3 depending on which you're more comfortable with.

The future

Of course, in the future, much of this may be moot (for new projects, at least), as there is an active effort to bring an official version of DCDP to Drupal, including a new scaffolding dependency (committed to drupal/core on July 10, 2019!) and something akin to drupal-core-require-dev and drupal-core-strict. To find out more, check out the Composer Support in Core Initiative

Thanks to Greg Anderson, one of the Composer in Core Initiative coordinators, for his input and review of this article.

Jul 09 2019
Jul 09

AmyJune HinelineFrom Nursing to Open Source

It’s difficult to describe the amazing AmyJune Hineline’s impressive three year old Drupal Career without using a slew of adoring adjectives, since she really does embody everything great about Open Source technologies and the communities that support them. 

It’s also difficult to concede that, as much as we’d like to take credit for her remarkable commitment, expertise and all of the goodness and light she brings to Drupal; Drupal Career Online (DCO) was indeed just a well leveraged tool that this very smart, insightful woman chose to help her along her path.

This path and her passion has led her to become the Open Source Community Ambassador for Kanopi Studios. She ensures that the Kanopi team maintains an active connection to the communities it serves, which include Drupal and Wordpress. "...This focus enables others to forge deep community connections that benefit the whole. I help communities discover how they can contribute back in more ways than code," she explains.

Kanopi designs, builds, and supports websites for clients that want to make a positive impact on the world: A great fit for the former hospice nurse and mother of two young adults. Part of her responsibilities also include creating dashboards for data visualization and performing accessibility audits, which also feeds her passion in the accessibility realm. 

AmyJune helps to organizes events, is on the Drupal Core mentoring team and leads first time contributor workshops at regional and local DrupalCamps, and helps mentor attendees in general contribution spaces. It’s an impressive list of responsibilities, especially when you remember she has been at this for just 3 years. 

Her early career route offers no clues as to how she arrived in this auspicious role in Open Source. She began with a college degree she did not use that led her into retail, then a sharp turn into Volkswagen repair. After having children, she rolled into nursing, focusing on hospice, and eventually earned a BS, and later picking up another degree, this one in Human Communication. 

As a hospice nurse, she embraced her role as a guide for patients and families transitioning through the phases of terminal illness, but over time the work took a toll. The unexpected onramp to Drupal came after she did a bit of content entry on a Drupal site. She was intrigued, and decided to become a developer. “My colleague and mentor (loopduplicate) knew of DCO from DrupalEasy podcasts and Mike's (ultimike) presence in the Drupal community.” she recalls.

Coming into the DCO without much technical background, AmyJune had a lot more to learn than most students, which she quickly overcame. Mike recalls she took advantage of every possible resource full force. She worked closely with her mentor, was active in the weekly office hours/co-working labs and was truly engaged in every class session. 

In addition to the classes and lab, she recounts she spent two to three hours a week, perhaps a bit more toward the end, outside of class to get the most of her education.  Within a week after graduating, she was offered a paid internship at Kalamuna which led to her first full time position, and then on to a higher level gig with Hook42

In her current position with Kanopi Studios, AmyJune also helps to organize camps and conventions throughout North America, with a focus on helping communities be more inclusive, as well as playing a mentoring role at events and beyond. These projects help her realize the gratification she drew from nursing. She explains, “...there is a feel good factor that comes when empowering others to get involved in Open Source projects. I love the smiles and reactions when someone I have mentored get theirs first credit or attribution. It feels good to help others feel good.”

As for her thoughts on Drupal Career Online, AmyJune is a big fan of the active and ever growing DrupalEasy Learning Community. "The continued support and mentorship is unbelievable. I love attending the weekly office hours...I like to hear what the other students are working on. Also I enjoy the camaraderie. (and sometimes the commiseration!)" She adds, "The relationships I have forged through the program have been valuable and essential to my growth as a developer."

"The trajectory of my career has been amazing," she reflects. "I started as an intern in programming, moved to a team's community lead, and now being an Open Source Ambassador for Kanopi allows me the time to be a Mentor and Drupal community lead in the camp organizer space…," she explains.  Looking forward, she continues, "I would love to be able to move into a lead mentoring or diplomacy role involving accessibility and inclusion."

AmyJune’s advice to those looking to get into Drupal?   

  1. Find a good mentor. Always ask questions. Never stop asking. Every great Drupaller was once a beginner.

  2. Share what you know. You will always know more than someone else, and when helping others with something you don't know, you can always figure it out together.

  3. Trust in yourself. Imposter Syndrome is a bitch.

As a developer, AmyJune admires patience and humor in the other developers she works with. "Developers who are patient are good collaborators and mentors, and being able to laugh and joke makes the day-to-day work flow so much easier," she explains. 

 You can follow AmyJune at volkswagenchick, on Twitter @volkswagenchick and learn more about some of the Projects is working on: 

A11yTalks- a monthly online meetup dedicated to promoting community discussions on a variety of accessibility issues.  

BADCamp (Bay Area Drupal Camp) - the largest free Drupal Camp in North America.  

WordCamp US  

The next session of Drupal Career Online will be launching new careers beginning August 26th.  If you’d like to learn more about this 12-week certificate program, you can attend one of DrupalEasy’s no-cost Taste of Drupal mini webinars, or visit DrupalEasy’s Drupal Career Online page. You can also contact me at [email protected]


 

Jun 30 2019
Jun 30

Version 1.9.0 of DDEV-local introduced the ability to share your local project online via a temporary, public URL using ngrok.

This allows you the ability to quickly and securely provide access to your local site to other developers and stakeholders as well as an easy way to test your local site on other devices.

ngrok is a service that exposes local servers behind NATs and firewalls via public URLs over secure tunnels. Once the small ngrok client is installed on your local machine, the ddev share command will enable the sharing and provide you with a public URL for your local site.

While there are paid tiers for the ngrok service, a free tier is provided with reasonable limits on usage. See the ngrok web site for details. In the first example, we'll utilize the free, anonymous tier.

The free, anonymous tier does not encrypt your data between your local and the ngrok servers, even though an https connection is provided from the ngrok servers to connected clients. Therefore, it is strongly suggested that once you get the free, anonymous tier working, create a free account and authenticate your local ngrok client to ensure your data is encrypted the entire trip.

Note that this is a one-time setup for your machine, and does not have to be repeated for each of your DDEV-Local projects.


Step 1: Install the ngrok client

Download and install the client specific to your OS from https://ngrok.com/download. While there are instructions to download and install ngrok on various operating systems, I found that using Homebrew (Mac OS X and Linux) was easiest:

brew cask install ngrok

If you're using Windows 10 and Chocolately, then I recommend installing with:

choco install ngrok

Step 2: Sharing your local site

Run the following:

ddev share

If successful, this command will return some information about the share, including public URLs with which you can access the site.

As requests are made to the site, the screen will update detailing each request.

ngrok status

Note that in the screenshot above, that the "https://94d5c548.ngrok.io" public URL is forwarding the insecure "http://127.0.0.1:32786". If we were to set up a ngrok account and authenticate our local ngrok client, it would be forwarding "https://127.0.0.1:32786" instead.

Use Crtl-C to stop the sharing.

Additional ngrok features and functionality

Secure your data by signing up for a free ngrok account and then authenticating your local ngrok client with your account credentials using the command provided by the ngrok web site:

./ngrok authtoken <a-long-string-of-characters-that-is-your-token>

ngrok authtoken

Once your local ngrok client is authenticated, the next time you do a ddev share, you'll be able to see that your connection uses https from end-to-end.

While the free ngrok plan is normally sufficient for smaller projects, paid ngrok plans include multiple users, custom domains and subdomains, additional connections, static IP addresses, and other features.

This tutorial is an excerpt from version 3 of Michael Anello's Local Development with DDEV Explained book - coming soon! Version 3 will include everything new to DDEV-Local through version 1.9.1. Pick up an electronic copy of Version 2 for less than $10 and you'll automatically get free access to Version 3.

Jun 19 2019
Jun 19

Jen Lampton (Backdrop user account), co-founder of Backdrop CMS, senior Drupal developer at Jeneration.com joins Mike Anello and Ryan Price to get reacquainted with Backdrop and to discuss why it could be a good long-term solution for sites after Drupal 7's end-of-life.

Discussion

DrupalEasy News

Upcoming Events

Sponsors

Follow us on Twitter

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Jun 08 2019
Jun 08

If you use the Drupal Composer Drupal Project template for managing your Drupal 8 site’s codebase, and you commit dependencies to your Git repository, then you’ve probably run into issues involving cloned dependencies. Sometimes when requiring a dependency via Composer, you end up with a cloned version (which includes a .git directory) instead of a release version. 

If you’re committing dependencies to your repository, then the .git directories associated with cloned dependencies cause an issue when you try to commit. A common resolution is to remove the .git directory from the dependency’s directory.

While this solves the immediate issue, the next time you go to update Drupal core, you’ll likely see an error message along the lines of, “The .git directory is missing from /var/www/html/vendor/some/dependency, see https://getcomposer.org/commit-deps for more information”. How can we get past this?

Here’s my workflow:

  1. Delete the entire /vendor/ directory.
  2. Run “composer install” to reinstall all dependencies. 
  3. Update Drupal core (normally with “composer update drupal/core webflo/drupal-core-require-dev "symfony/*" --with-dependencies”
  4. Re-remove any .git directories for cloned dependencies.
  5. Commit the update.

Ultimately the "proper" solution will be to not commit dependencies to the project repository. I agree that this is the best solution, but not everyone’s workflow currently supports this.

There's also a great discussion in the Drupal Composer Drupal Project issue queue about alternate methods to deal with this issue. 

Have a different workflow to deal with cloned dependencies? Share it in a comment below!

Just getting started with managing your Drupal 8 project with Composer? Jeff Geerling has some super-helpful blog posts.

Jun 01 2019
Jun 01

AmyJune Hineline, Open Source Community Ambassador at Kanopi Studios joins Mike Anello to talk about her upcoming Contribution Tour 2019, as she visits numerous Drupal and WordPress events to help train new contributors.

Discussion

DrupalEasy News

Upcoming Events

Sponsors

  • Drupal Aid - Drupal support and maintenance services. Get unlimited support, monthly maintenance, and unlimited small jobs starting at $99/mo.
  • WebEnabled.com - devPanel.

Follow us on Twitter

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

May 28 2019
May 28

I recently decided to begin rebuilding the various landing pages on DrupalEasy.com using Layout Builder, introduced as a stable module to Drupal 8.7 core. Prior to this, the various landing pages on the site had been built using Paragraphs module.

While I appreciate what Paragraphs module can do as a layout tools for individual entities, I learned the hard way that perhaps it isn't the best tool for the job of building landing pages. 

I've been keen to use Layout Builder for awhile, but also hesitant to make the switch. Layout Builder has (unstated) lofty goals - to be the de-facto method of building landing pages in Drupal. I'll be perfectly happy if I didn't have to use Paragraphs or Panels in the future, instead relying on a core module.

I was biding my time until Layout Builder was stable in core, and now that it has come to pass, I wanted to take the time to rebuilding our landing pages while updating their content, layout, and styles just a bit.

Use layout builderFor starters, I created a new "Landing page" content type. Knowing that all of our landing pages will just be a series of blocks, I didn't add any fields - in fact, I removed the default "Body" field from the content type. I also created a default layout by selecting the "Use Layout Builder" checkbox on the content type's "Manage display" page. Knowing also that I may want to tweak the layout of some of our landing pages, I also selected the "Allow each content item to have its layout customized." (this effectively replaces the Panelizer contrib module). 

From there, I clicked the "Manage layout" button and set up a default layout for our landing pages. I'm not going to take you step-by-step through the process, but it's quite intuitive - and far better than any of the community's attempts to provide a browser-based layout tool in the past (no offense to anyone who has tried - it's a really difficult problem!)

After that, I created a new "Landing page" node and went directly to the "Layout" tab. The default layout I created in the previous step was ready for me to populate - but I was also able to tweak the layout for just this node as well. The process for adding content to the layout is easy primarily because it utilizes Drupal core's settings tray functionality. Existing blocks, custom blocks, as well as fields belonging to the content type are easily placed. I especially like the "Show content preview" checkbox for simplifying (and speeding up?) the interface during construction. 

Show content preview

My experience wasn't without hiccups, however. I did run into a couple of issues that I'd imagine a few other folks will stumble upon as well.

First, I tried adding a system Search block to one of my layouts. When I did this, I was unable to save the layout. I traced this issue to an issue related to rendering form blocks inside Layout Builder. At the time of writing this post, I didn't feel there was a mature enough patch yet, so I opted to remove the Search block for now. 

As this site is hosted on Pantheon, **and its codebase is built on https://github.com/pantheon-systems/example-drops-8-composer** , I ran into an issue where I was unable to add a new section to any layout. Turns our it was caused by this issue - luckily the fix for this was easy.

Finally, as I use the Bootstrap base theme for this site, when adding a bit of styling, I noticed that I had to override (using CSS) some of the breakpoints that Layout Builder uses by default. Specifically, Layout Builder has a 40em breakpoint, which doesn't align with Bootstrap's (default) 768px breakpoint. Not a big deal to do with a little bit of CSS (Sass), but important to note nonetheless. I used the following Sass to align layout builder's 2-column layout with the Bootstrap breakpoint:

.layout--twocol-section {
  &.layout--twocol-section--50-50 {
    > .layout__region--first,
    > .layout__region--second {
      @media #{$mobile} {
        flex: 0 1 100%;
      }
      @media #{$tablet} {
        flex: 0 1 50%;
      }
    }
  }
}

Overall, I'm really happy with Layout Builder so far - the resulting landing pages are easier to update - both from a content and a layout standpoint. It also provides a good deal of confidence knowing that I'm now using a core solution that will only improve with time.

May 27 2019
May 27

Local development environments are in the midst a bit of a renaissance recently - mainly driven by the maturation and adoption of Docker-based solutions.

I've been using (and recommending) DDEV for awhile now, and one of the things that I really like about it is the consistent pace of development. Since early February, there have been three minor releases of DDEV (1.6, 1.7, and 1.8). With each minor release of DDEV comes new, often very useful features. Here's just a few of my recent favorites:

NFS Mounting

One of the few disadvantages of using a Docker-based solution over a native local development solution is often the performance (depending on your operating system and hardware). In the DDEV 1.6 release, NFS mounting was introduced - this is a method to mount the DDEV Docker containers using NFS instead of the default Docker mount - resulting in significant performance gains. While using NFS mounting does involve a one-time system -setup, the results are well worth it.

Windows Chocolatey support

For Windows users, Chocolatey is similar to Homebrew for Mac OS X. With DDEV 1.6, you can now install DDEV using Chocolatey from the command line.

Local DDEV config files

If you're working in a team environment, then having a local DDEV config file is a huge advantage. Prior to DDEV 1.7, if you wanted to utilize a DDEV post-start hook, it had to be configured in .ddev/config.yaml. In a team environment, this file is shared among all developers, so everyone would share the same post-start hook (even if they didn't want it). Starting in DDEV 1.7, you can have your own .ddev/config.local.yaml with only your additions or modifications to .ddev/config.yaml. For example, if you want to add a post-start hook and not share it with the rest of your team, just create a .ddev/config.local.yaml file and add it there.

Easy local https by default!

It is pretty much standard practice these days to have your production environment only available via https. It only makes sense that your local development environments should behave in the same manner. In DDEV 1.8, support for the most-excellent mkcert project was added, so with a one-time, super-easy mkcert installation on your host operating system, DDEV will automatically default to providing you with an https connection to your local development environment. 

There's a lot of great reasons to use DDEV (check out more of them in my DDEV book!), and it is exciting to know that every six weeks or so, we'll be getting new ones with each DDEV release.

Apr 27 2019
Apr 27

Michael Hess, (mlhess), Senior Technologist and Adjunct Lecturer at University of Michigan and member of Drupal's Security Working Group joins Mike Anello to talk about recent Drupal core security updates, security release processes, Drupal 7's future end-of-life, and the new Drupal Steward program.

Interview

DrupalEasy News

Upcoming events

  • DrupalCamp Chattanooga - June 7 and 8, 2019.
  • DrupalCamp Asheville - July 12-14, 2019.
  • Midwest Drupal Summit - August 8-11, 2019 - Michael is the primary organizer - for more info, go to #mwds in the Drupal Slack workspace.

Sponsors

Follow us on Twitter

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Apr 01 2019
Apr 01

Get ready for your trip to Seattle with this April Fool's Day special episode of the DrupalEasy Podcast.

Drupal Fools

a Dr. Seuss joint (sortof)

From the top of your head to the tips of your toes,
You are a Drupaller, everyone knows.

You think about Drupal all day and all night.
You’re more than obsessed with getting things right.

Your Views and your Fields and your Content Types,
Simply scream “Drupal!” here are some reasons why:

Your User Experience is so Steve Jobs-esque
Your Splash Awards medals are spilling off your desk!

Your API documentation site,
Lets your developers get sleep at night.
You’re well known to eat your own dog food.
When you’re done with work you’re still in a good mood.
And why not? Your patches have all been applied,
The hackers can’t get in, and they even tried!

I heard a rumor at DrupalCon Seattle,
That your coding standard leaves code reviewers rattled.
Before you go saying that I must be kidding,
Know that I suck a peek, I did some digging…
I couldn’t find one curly brace out of place,
One line break too many or one poor stack trace.

Have you ever noticed just how our community
Is one of the best at promoting unity?
We’re very good at giving hugs,
Especially to those who have fixed our bugs.
But if you’re not a fan of physical affection,
We don’t make a big deal of your objection.
(We’re still glad you chose to sit in our section)

Like Birds of a Feather or a Business of Ferrets,
The Drupal community celebrates merits.
Even if you don’t pretend to know code,
Your contribution deserves to be showed.
Webchick will help you, as luck would have it,
When your first core improvement is ready to commit.
(Stick around until Friday, and you won’t regret it)

And if this is your first time at DrupalCon...

Did you know that Drupal is eighteen years young?
We’re just getting started, we’re still having fun!
Of all websites, we’re say, five in a hundred,
The more ambitious ones are quite well funded,
But even for NGOs our scopes are not blunted.
We’ve got thousands of community projects,
To extend, integrate, and meet all of your specs.
Even if you don’t speak like a geek,
I’m sure the vendors won’t judge you like some kind of freak.
They’ll help you translate the Greek, so to speak.

If this is your first event, or your hundred and first,
We welcome you to dive in to Drupal head first.
Bring us a challenge, we’ll find you a guru,
As long as you understand our Kool-Aid is blue.
(We do have other interests besides Open Source,
We’re human aren’t we? Why yes, of course!)

Have you met Dries Buytaert? He’s the project’s creator.
Without him, I might be a Red Lobster waiter.
He’s tall and Belgian, well over two meters,
(Not that I’ve measured him, that would be cheating),
He’s the lead of this project and he helps set the agenda
To give us some staying power and stay just a bit trendy.
There are really so many others to thank,
Given ten thousand thank you notes, none would be blank.
It takes a village, at least that’s what I think.

So welcome to the land of rainstorms and coffee,
Of mega-giant software companies,
To DrupalCon Seattle, it’s like my family reunion.
Think Digital. Be Human.

DrupalEasy News

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Mar 17 2019
Mar 17

Ryan Price, Principal Engineer, Drupal and Web with Autodesk joins Mike Anello to discuss the hurdles involved with implementing a continuous integration system, OpenDevShop, improving hook_help(), a Drupal 8 Feeds-like module, and DrupalCon Seattle!

Interview

DrupalEasy News

Upcoming events

Sponsors

  • Drupal Aid - Drupal support and maintenance services. Get unlimited support, monthly maintenance, and unlimited small jobs starting at $99/mo.
  • WebEnabled.com - devPanel.

Follow us on Twitter

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Mar 10 2019
Mar 10

I often work on migrations that involved dates that need to be migrated into Drupal 8. While many times the dates are for entity created and updated dates, and therefore in Unix timestamp format, sometimes (when migrating events, for example), I'll need to migrate a date in some other format into Drupal's date field.

In the past, I've ended up writing a custom process plugin or callback to convert the date into the proper format for Drupal core's date field, but I recently discovered the format_date process plugin (I'm pretty sure I'm late to the party on this) and realized I was doing more work than I had to. 

The short version is this - the format_date plugin takes a date in any format (as long as it can be described using the standard PHP Date patterns) and converts it to the format Drupal requires. Oh, and it also has timezone support!

Here's an example of taking a datetime in the format of "11/04/18 08:30:00" (EST) and converting it to the format that Drupal's core date field requires, "2019-11-04T08:30:00" (UTC).

field_eventdate/value:
  plugin: format_date
  from_format: 'm/d/y H:i:s'
  to_format: 'Y-m-d\TH:i:s'
  from_timezone: 'America/New_York'
  to_timezone: 'UTC'

It's pretty simple! Less custom code usually means less opportunities for mistakes and less code to maintain in the future!

Mar 10 2019
Mar 10

One of the pillars of the consulting side of the work we do here at DrupalEasy is data migration into Drupal sites. Over the past few years, we've been focused on migrating data into Drupal 8 using the most excellent core migrate modules along with contrib modules like Migrate Tools, Migrate Plus, and Migrate Source CSV

If there's one thing I've learned over the years is that data to be migrated is never, ever, ever, ever, never as clean as it is claimed to be. There's always something that has to be massaged during the migration process in order to get things working.

One of the most common things I see when migrating data from a .csv is strings with trailing spaces. If you take a cursory look at the data in a spreadsheet, you might see something like "Bread", but if you look at the same data in a text .csv file, you'll see that the string is actually "Bread " (trailing space). If you're migrating this field to a vocabulary using the entity_lookup process plugin, that trailing space will cause the term to not be found, and therefore not migrated.

The solution? Well, you could clean up the data, but there's actually a much easier solution that I use by default on almost all string data being migrated - I use the "callback" plugin to in-turn call the PHP trim() function on incoming strings in the "process" section of the migration configuration. Here's an example:

field_topics:
  -
    plugin: callback
    callable: trim
    source: Topic
  -
    plugin: entity_lookup
    entity_type: taxonomy_term
    bundle: topics
    bundle_key: vid
    value_key: name
    ignore_case: true

Using this method allows for the incoming data to be a little dirty without affecting the migration.

Mar 10 2019
Mar 10

Code flows up, data flows down.

I repeat this phrase in just about every workshop I teach - it is one of the basic principles of being a professional web developer. The idea is that we should be working locally, then pushing our changes (using Git) up to the project's dev, then QA, the live environments. As for the project's data (database and files directory for Drupal sites), the direction is opposite, we should only be moving data "down" - from live to QA, or live to dev, or live to local.

There are, of course, exceptions to every rule, and certainly in this case as well.

One exception is when the project is just getting started. Consider the example where you've started a new project on your local, you've reached the first milestone of development and are ready to move everything to a shared development environment where the client can catch their first glimpse of the project. In this case, you'll likely be moving everything "up" - code, database, and files. 

I had this exact scenario recently, I was migrating a rather large site to Drupal and had the initial migration looking good, and was in the process of getting it up-and-running on Pantheon. I successfully pushed the code as well as SFTPd the 1.6GB files directory to the Pantheon dev environment. The database was a bit larger than the 100MB maximum Pantheon allows to be uploaded through the browser, so I was using their "URL" method.

Pantheon database import interface

My plan was to put the database dump in a public Dropbox folder, then copy/paste the URL of the file in the Pantheon Dashboard interface. Unfortunately, it didn't work. I tried both .sql and .sql.gz formats, I tried doing the database import using Terminus (Pantheon's command-line interface) - each time I was provided with either no error message, or one that wasn't very helpful.

The solution? Turns out it is a bit of a DropBox issue, albeit one that is pretty easy to fix.

When copying/pasting the URL for a public file on DropBox, the URL ends in dl=0 - turns out that this prevents Pantheon from being able to import the file. Simply change it to dl=1 and the problem is solved (this works in both the Dashboard and Terminus)!

Feb 05 2019
Feb 05

As someone who has been building Drupal sites for over 12 years now, I'd like to think that my knowledge and expertise has grown at a rate similar to the power, flexibility, and complexity of the Drupal project itself. For well over 10 years, Drupal training and development has been the focus of my consulting business; over the holidays I took some time to look back and really think about the lessons I've learned and how I can utilize them moving forward. 

In addition to documenting the process for myself as well as my current and future clients, I also wanted to share what I've learned with the Drupal community. After all, it is this community that has made it possible for me to have the success that I have found so far. I have worked on projects of all sizes from large Fortune 500 companies to small local businesses. I’ve been alone on project as well as with large teams of developers. There have also been projects with massive budgets as well as projects with no budget. The breadth of this experience has really contributed to my ability to provide more value for my clients. 

One word I use often when speaking with current as well as prospective clients is "sustainability". I always want to be involved in a solution that provides good value not only now, but for the lifetime of the project. I want to build sites that are easy to maintain, easy to update, and easy for different developers to cycle in-and-out of. With sustainability, and all of the elements that contribute to it in mind, I present the 11 tips to start a Drupal project right. 

1. Commit to a Local->Dev-Stage->Prod developer workflow

Having a professional developer workflow should go without saying, but I often come on-board small, single-developer projects that have a remote development environment and a live environment - and nothing else. At the very least, projects of all sizes should have not only a dev and live environment, but developers should have local environments as well. 

There's a lot of focus on DevOps in the Drupal ecosystem (with good reason), but before you jump into a continuous integration/continuous development (CI/CD) system, be sure you have the basics first and then add complexity only as necessary. I've seen way too many projects invest in a full-on CI/CD system only to have it ignored because developers didn't have the time and/or expertise to utilize it properly.

2. Commit to the entire team using a project tracker

This is a bit of a pet-peeve of mine. I'm a firm believe that commitment to a project tracker must include 100% of the development team and stakeholders. Note the "and stakeholders" - this includes project managers, content and QA folks, and anyone else who has a role in the project. How often is a project ready to launch and then at the last minute a stakeholder chimes in requesting changes? This is demoralizing and frustrating for the entire development team.

Project tracker tasks should be focused. Large tasks like "theme the site" aren't very helpful and comment threads in tasks like this often become unwieldy, defeating the purpose of using a project tracker. Train the entire team on using the project tracker and committing to using it for the majority of project task communication. 

3. Utilize a remote Git repository

You're not using Git yet? Seriously? Stop reading this and go get yourself and your team trained up (we offer training). Also - commit early and often. Smaller, more focused commits (like project tasks) are easier to manage.

4. Use Composer to manage the code base

This is an article about Drupal 8, so this isn't really optional. While there is work in the community on various Composer-related projects, for now the Composer template for Drupal projects is the de-facto standard for managing your Drupal 8 project's codebase. Don't know how to use Composer? Learn it (we also offer Composer training).

5. Use consistent local development environments for development team

Avoid "it works on my machine" conversations for the rest of your life by ensuring that the entire development team is using identical local environment configurations. Docker-based solutions are tailor-made for this type of thing, but it has been possible for awhile with virtual machine-based solutions as well. A solid local development environment will pay dividends - making it easy to get new developers up-and-running, and allowing developers to focus on building the project, not monkeying around with their local environment.

I've been a fan of DDEV-Local, a Docker-based solution, for awhile - I provide training and I also wrote a book about it! 

6. Define information architecture with all stakeholders

This is where I see projects go sideways more often than not. When defining the information architecture (IA) for the site, all stakeholders must be involved. This tip really goes hand-in-hand with the next one, but the bottom line is that this needs to be a discussion. There's nothing worse than getting near the end of a project and showing it to a content author and finding out that there are gaps. Generally, the goal is to get the granularity right when defining IA. This is next to impossible to do without feedback early in the process from all stakeholders.

Review any existing content that is to be migrated to the new system, ask content authors what the issues with their current system are, and be careful not to over-engineer a solution that won't provide enough bang-for-the-buck. 

7. Prototype information architecture with content authors

This tip goes hand-in-hand with the previous one - an important part of defining the IA is testing and confirming that everything is accounted for. In my experience, the absolute best way to do this is by prototyping the system. Allow your actual content authors, editors, and admins to test-drive the new architecture by adding and editing content on a prototype of the site. This needs to be done very early in the development process, so the focus should be 100% on the add/edit forms - not the output. In fact, I recommend not putting any effort into theming the output at this point, making it crystal clear that the prototyping exercise is to confirm that the set of entities, bundles, and fields designs are on-target.

I really cannot stress enough how important this step is. IA mistakes made early that are not corrected will be a burden until they are corrected (if ever). It's normally relatively easy (and inexpensive) to fix IA mistakes early - quite the opposite if they are left to fester and other parts of the site are built upon them. I have never been part of a project where the IA prototyping didn't result in important updates to the IA. 

8. Create a style guide

If you're building a custom theme, then you probably need a style guide. Part of a solid UX/UI design is consistency in design. Consistency brings user comfort. When users are more comfortable on your site, they'll spend more time there. 

Style guides can be as simple or as complex as they need to be. At the absolute minimum, I would recommend that a style guide contain basic typography and a color palette. You'll need to consider how/if typography will change based on responsive mode (are H1s the same pixel size on mobile as they are on a desktop display?) Similarly, you'll want to think about how the header/navigation/footer respond to various screen widths as well. Have an element that appears throughout your site? Then define rules how it looks in various places and various screen widths. 

9. Create wireframes and mockups as necessary

Similarly, if your project is going to have a custom theme, then you're going to need to design the layout of key pages. How are landing pages arranged? How do they respond at various screen widths? Think about the entire site and design wireframes for a representative sample of pages. Only 2 or 3 wireframes are necessary for many projects (home page, content page, interior landing page). 

Consider these representative pages as a group, not individually. Look for common elements (easier to theme) and value consistency. If every page is a one-off, then implementation costs will rise. 

Start with wireframes and generate only the mockups you need. Often, between a solid style guide and some good wireframes, mockups aren't necessary in many cases. Think of the style guide as a box of LEGO bricks that can be assembled into mockups in various configurations. If time and budget is limited, favor the style guide over mockups.

10. Use the Configuration System

Drupal 8's configuration system provides a powerful tool to easily push non-code configuration changes between environments. The "trick" to using it is that the entire team has to understand and participate in the process. If the development team is five people, and only two are using the configuration system, you're going to have rough sledding. 

The configuration system will help enforce a solid developer workflow, encouraging team members to update and test configuration (like a new View) locally before pushing it to remote development environments. A byproduct of using the configuration system is that config changes can easily tracked by the project tracker via commit messages. 

11. Define realistic and meaningful milestones

There's not much that kills developer morale and confidence in a project more than lack of project leadership. At the core of this is often a lack of project planning and milestones. All team members should be involved in the setting of goals and milestones for the project. A single milestone of "the site must be done in 5 months" doesn't cut it. The entire team should work together to define realistic and meaningful milestones. Take into account non-project responsibilities of team members, identify and plan for potential pain points in the project. 

Project leaders need to listen to team members and provide training and professional guidance when necessary. Most developers are problem solvers who like to learn new things. Project leaders should embrace and leverage this for the betterment of their projects, the result will be a positive one for the entire team!

Mike Anello is the architect and instructor for DrupalEasy’s Drupal Career Online, which includes intensive live online sessions, rich learning resources, an active learning community and hands-on projects designed to provide those who need to get skilled up in Drupal with the best possible start. The next session of the DCO starts February 25th. If you’d like to learn more, you can sign up for a no-cost Taste of Drupal mini-webinar.

Feb 04 2019
Feb 04

Kaleem Clarkson, Operations Manager and Front-End Drupal Developer at Kennesaw State University and Drupal developer at blend me inc. Listen in as they discuss the newly formed Drupal Event Organizers Group and Mike breaks bad news about the Marvel Universe to Kaleem.

Discussion

DrupalEasy News

Upcoming Events

Sponsors

Follow us on Twitter

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Jan 30 2019
Jan 30

All sorts of organizations have made their predictions and proclamations about what 2019 will be the year of... Some say it is the Year of Optimism and growth for helicopters, others, …of the Hack & Slash, …of indigenous languages, …of the electric SUV, and even the International Year of the Salmon.  It all comes down to what someone sees as an important aspect of their field to promote or what is or should be a trend.  DrupalEasy would therefore like propose we make 2019 the Year of Drupal Talent Development.

As an active member of the community, we've observed, had great discussions and provided several sessions at Camps and Cons about the talent shortage in the community as well as how to build a Drupal career. We feel it is pretty important to Drupal. Right now, there are more than 2,000 jobs requiring Drupal skills on Indeed, and hundreds more continually being added. The Drupal Association also recognized the need, as we discovered while putting together this blog post, with the introduction of a Drupal Educational Opportunities Newsletter, which will help get the word out to those looking to further their skills, and those looking to start a career in Drupal.  

As a training organization, we not only train within the community, but bring in new people to develop passion for Drupal. We’ve had over a decade to watch people who started out not being able to spell Drupal develop the commitment and skills to excel at it. We’ve seen our Drupal learning community grow, diversity, and expand internationally, as new students hone their skills and strive to contribute to the community while they do it. Through all of this talent development for Drupal and the community, most gratifying is seeing the companies and organizations compete for the people building rewarding and fulfilling careers through experience and participation. 

How can we make it the Year of Drupal Talent Development?  A simple way is for each of us to simply sharie information on Drupal as a career and the opportunities in Drupal to those who may benefit from it. For those with the need and resources, providing the education and training needed for individuals or teams. There are some great resources to get information about Drupal as a career

The US Department of Labor has an Occupational Outlook Handbookprovides summaries of careers including salary ranges, anticipated job growth, and types of work environments.  Their entry on Web Developer careers, though not specific to Drupal, seems to track pretty well. There is also great salary information about Drupal specific web development through the Indeed Salary Tool, as well as Glass Door's version

Of course, salary is just a part of it, so a few years ago, we put together a Drupal Career Resources page to provide an index of information, insight and news for those looking to get into Drupal. It is a quick way for those of us who are in the community to share a lot of information.    

We also truly believe that solid education in the ways of Drupal is key to get and keep people active in the community.  Mike Anello teaches our our 12-week live, Drupal Career Online course twice each year.  The career technical education course is licensed as a certificate program through the Florida Department of Education Commission for Independent Education.

Drupal Career Online is a  comprehensive program that includes 2 class sessions and one co-working lab session each week, along with Mike's office hours and access to other training provider resources, most recently Drupalize.me.  Participants are also provide rich learning resources including a lesson guide, class slides, links to go further in-depth into topics, and a screencast for every lesson, which is all accessible through a session-specific class web site. 

Prior to each DCO session, we hold Taste of Drupal mini-webinars to introduce people to Drupal, Drupal careers and our course.  There are 2 more sessions before the Spring 2019 session of Drupal Career Online kicks off on February 25th.  Those interested can sign up for a Taste of Drupal, or contact us to get more information.      

Dec 20 2018
Dec 20

Travis Carden, (traviscarden), Senior Software Engineer at Acquia joins Mike Anello to talk about the spreadsheet-based Drupal Spec Tool, a very cool tool that allows teams to specify different parts of a Drupal site and then generates diagrams and Behat tests.

Interview

DrupalEasy News

Upcoming events

Sponsors

  • Drupal Aid - Drupal support and maintenance services. Get unlimited support, monthly maintenance, and unlimited small jobs starting at $99/mo.
  • WebEnabled.com - devPanel.

Follow us on Twitter

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Dec 17 2018
Dec 17

Ted Bowman, senior software engineer with the Drupal Acceleration Team at Acquia, joins Mike to discuss the game-changing work of the Layout Initiative. Sorry about the poor quality of part of Mike's side of the conversation (as well as the comical overdubbing of other portions of the conversation).

Discussion

DrupalEasy News

Upcoming Events

Sponsors

Follow us on Twitter

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Dec 09 2018
Dec 09

If you've adopted a Composer-based Drupal 8 workflow (hopefully using the Drupal Composer/Drupal Project template) where you're keeping dependencies in your project's repository, then you've no-doubt experienced the annoyance of a rouge .git directory ending up in one of your project's dependencies. This will always happen when you're using the -dev version of a Drupal module. 

For example, as of the authoring of this Quicktip, the Field Redirection module does not yet have a stable release for Drupal 8. When added to a project using Composer, the results look like this:

Michaels-MacBook-Pro:dcoweek5 michael$ ddev composer require drupal/field_redirection
Executing [composer require drupal/field_redirection] at the project root (/var/www/html in the container, /Users/michael/sites/dcoweek5 on the host)
Using version 2.x-dev for drupal/field_redirection
./composer.json has been updated > DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Installing drupal/field_redirection (dev-2.x e1c30f2): Cloning e1c30f24f9 from cache
Writing lock file

Git directory

Notice on the "Installing drupal/field_redirection..." line, it indicates that the project is cloned, not downloaded. This means that a .git directory has been created in the Field Redirection directory.

Note that I'm calling Composer as "ddev composer ..." - this is because I use DDEV as my local development environment and am utilizing its built-in Composer command.

If this goes unnoticed, and you attempt to do a normal "git add/commit" workflow for the new module, you'll end up with a somewhat-friendly Git message indicating that you now have a Git submodule.

Unfortunately, Git submodules aren't normally necessary nor wanted when you are committing dependencies to the project repository. So, the typical solution is to delete the .git directory of the dependency prior to performing the "git add/commit".

Luckily, there's an easier way! Travis Neilans recently pointed me in the direction of the Composer Cleanup VCS Directories project. By adding this as a dependency of your project, any .git directories that result from adding project dependencies will be automatically removed! First, install the Composer Cleanup VCS Directories project using:

composer require topfloor/composer-cleanup-vcs-dirs

Then, anytime you use "composer require" to install a project dependency, if there's a .git directory, you'll see a message indicating that it has been automatically removed.

Deleting .git directory from /var/www/html/web/modules/contrib/field_redirection/.git

Dec 03 2018
Dec 03

Matt Glaman, (mglaman) and Bojan Zivanovic, (bojanz) join Mike live from Disney World to talk about decoupling Drupal Commerce as well as the roadmap for Drupal Commerce as a project. We take a quick side trip into some blog posts Matt recently wrote about running all of Drupal core's automated tests in DDEV-Local.

Interview

DrupalEasy News

Upcoming events

Sponsors

  • Drupal Aid - Drupal support and maintenance services. Get unlimited support, monthly maintenance, and unlimited small jobs starting at $99/mo.
  • WebEnabled.com - devPanel.

Follow us on Twitter

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Nov 17 2018
Nov 17

Book: Local Web Development with DDEV ExplainedIt's no secret that I'm a fan of Drud Technology's DDEV-Local web development tool. I selected it as my local development tool of choice for both my clients and my Drupal Career Online students after an exhaustive search. I've been teaching monthly 2-hour online workshops getting folks up-and-running with DDEV, and I've taught numerous full day "Getting started with DDEV" workshops at various Drupal events around the United States.

Since I've been writing, testing, and refining curriculum related to DDEV for well over a year now, it made sense to take everything I've learned and put it in a format that makes it available to even more folks looking to easily adopt a professional local development environment. I'm super-happy to announce that the book is now available for purchase on amazon.com at a price designed to get it into as many hands as possible - just $5.99 for a digital copy and $9.99 for the dead tree edition.

This first book, Local Web Development with DDEV Explained, is the result of a partnership wtih Steve Burge and the rest of the fine folks at OSTraining, which is the publisher. They've allowed me to retain full control of the book while at the same time tapping into OSTraining's extensive experience in publishing and marketing books related to open source content management systems. 

The book covers the full range of topics related to local web development and DDEV. Topics covered include:

  • Why a professional local development environment is important.
  • What a professional local development workflow looks like.
  • Installing DDEV on Mac OS X, Windows 10, and Ubuntu.
  • Step-by-step example of starting a new Drupal 8 project with Composer and DDEV.
  • Step-by-step example of getting an existing Drupal project up-and-running with DDEV.
  • Adding a Solr container.
  • Common workflows using DDEV.
  • Extending DDEV with hooks.
  • Using Xdebug with DDEV and PhpStorm.

The bulk of the book's content is straight from my training curriculum, so you can be sure that it is tried-and-true, and, as always, reflects only best practices. My goal is always to teach the right way to accomplish a task - no hacks or shortcuts.

My goal is to update the book several times per year, with a list of topics for the first revision already growing. I'll be starting on it in the next few days! By purchasing a digital copy, you'll automatically get updates to the book as they're released. 

Sep 22 2018
Sep 22

Drupal 8's text format system provides a way for developers to manage user generated content, regardless of if the user is trusted staff member or an anonymous commenter. With intelligent configuration of various text formats for the various roles on the site, the security and usefulness of a site can be maximized.

Much like Drupal 7's Better Formats module, Drupal 8's Allowed Formats module allows a developer to limit the text formats that are available on the field level. Normally, all formats that the user has access to are available on all fields, this module allows developers to force a particular format to be applied on a particular field.

The configuration is available on all formatted fields' "edit" page. For example, take this configuration for a "short summary" field.

Allowed Formats example

In this example, only the "Minimal HTML" format will be available for this field, regardless of if the current user has permission to use any of the other formats. For this application, the "short summary" field can only have links, strong text, and emphasized text. By limiting authors to only the "Minimal HTML" text format for this field, these parameters can be easily enforced.

Sep 22 2018
Sep 22

Debugging a Drupal 8 module can take many forms. Often, one of the first tools most developers use is the ability to output variables using the "Devel Kint" module (part of the Devel project). Much like the dsm() function from pre-Drupal 8 versions of Drupal core, the ksm() function provided by Devel Kint provides a slick way to output any variable type to the screen in a readable way. 

Unfortunately, many folks find Kint output to be a bit more cumbersome, and they're right, but Kint is doing a whole lot more than dsm() ever did. In addition to outputting just the variable's values, if said variable is an object, then Kint also outputs that object's methods and other valuable debugging information. Unfortunately, all that information comes with a cost - it tends to really bog down web browsers.

I was finding that some large variables in Drupal core ($form and $node, I'm looking at you) could even crash my browser (out of memory) due to the sheer depth of information returned by a simple ksm(). Out of desperation, I searched for a way to tame Kint a bit so that I could go about my debugging business.

Luckily, I stumbled upon this gist by Julian Pustkuchen which demonstrated how to limit the number of levels returned by a ksm() call. This solved my problem - no more browser out-of-memory issues. The downside is that sometimes a ksm($form) call doesn't get me deep enough into the array, so I have to be a bit more specific when ksm-ing. 

I took Julian's gist and dropped it in my settings.local.php file as follows:

include_once(DRUPAL_ROOT . '/modules/contrib/devel/kint/kint/Kint.class.php');
if(class_exists('Kint')){
  // Set the maxlevels to prevent out-of-memory. Currently there doesn't seem to be a cleaner way to set this:
  Kint::$maxLevels = 4;
}
Sep 22 2018
Sep 22

I've been a big fan of Drupal 8's configuration system since the beta-days of Drupal 8, and even more so now as the contributed module ecosystem around it has matured. I've been using the Config Readonly module from the very beginning to "lock down" configuration on production environments in order to help enforce developer workflows. 

Using the Config Readonly module is a bit of a double-edged sword. On one hand, it really helps in helping get developers accustomed to making configuration changes on local, then exporting them using Drupal 8's configuration system, committing them to the repository, and then moving them up through the project's defined deployment workflow.

On the other hand, sometimes it just really gets in the way. Two areas where I find that clients really find Config Readonly annoying in the live environment is when configuring menu items and block placement, both which can be affected by locked-down configuration. When the Config Readonly module is active, it is not possible to drag-and-drop menu links to reorder them. Nor is it possible to place a block or move a block to a new location.  

Luckily, the Config Readonly module maintainers added the ability to "whitelist" some configurations in version 8.x-1.0-beta3. This allows developers to keep certain configurations "unlocked" on the live environment via the settings.php file. For example:

if (IS_LIVE_ENVIRONMENT) {
  $settings['config_readonly'] = TRUE;
  $settings['config_readonly_whitelist_patterns'] = [
    'page_manager.page_variant.*',
    'system.menu.main',
  ];
}

In this code snippet, all Panel page variant configuration as well as the main menu are whitelisted, allowing site authors to modify these aspects of the site directly on the live environment.

Sep 22 2018
Sep 22

I ran across a situation the other day that had me a bit frustrated for a few minutes until Ted Bowman nudged me in the right direction. I was working on a small custom module for a client - one that involved altering a node form using hook_form_alter() - where I needed to know the value of the node ID being edited.

I had spent more than a few minutes digging into both the $form array and $form_state object desperately looking for the node ID, to no avail. I had pinged Ted on Slack about something else and I asked him if he knew how to find what I was looking for - he told me "maybe the form object is better".

That's all I needed to get unstuck, a few minutes and a Google search or two later, I stumbled upon the following:

$form_state->getformObject()->getEntity()->id()

Not only would this return the node id, it will actually return the id for any type of entity.

Just to be safe, I went ahead and wrapped it in a if-statement to make sure that the form object returned is actually an entity form:

if ($form_state->getFormObject() instanceOf EntityFormInterface) {
  $nid = $form_state->getformObject()->getEntity()->id();
}
Aug 13 2018
Aug 13

Drupal Career Online Case Study: Rosewood Marketing

Like their arboreal namesake, Rosewood Marketing is amazingly sound and particularly suited for very specific applications. Where the Rosewood tree serves to form the structure of certain fine musical instruments, billiard cues and chess pieces, Rosewood Marketing serves as a bridge for dozens of Amish and Mennonite small businesses to mainstream society. Their growth and development over the 22-year span of their success is not just in their marketing prowess, but in their inherent, sincere understanding of their client culture.    

If you really think about it, Rosewood has perhaps one of the most focused and secluded market segments in the US, which interestingly enough allows them to bring a type of diversity to the Drupal Community we don’t often consider. They do this amazingly well in their approach to business development and hiring. They first truly match new employees to their market and their company culture, and then leverage training programs to ensure the team has the skills and best practices in technology and communications to meet their business standards.  A person hired as a graphic designer receives training in tools such as Photoshop, InDesign, design principles and customer service. An online marketer receives training in analytics, SEO, and PPC, while a new manager learns time management.

Others become web developers, and as our luck would have it, DrupalEasy students and graduates. Of Rosewood’s 16 member staff, two are Drupal Career Online graduates and one new hire has just been enrolled in the upcoming Fall 2018 session.  Our new Rosewood student already has experience in Drupal 7, but needs to move forward in Drupal 8. Adrian Nolt, a 4-year employee of Rosewood and a Fall 2017 DCO graduate, explains, “Even though Stephen has...Drupal site-building experience, I recommended that he take DCO in order to acquire a common training foundation as our other Drupal developers...For me as a primarily self-taught Drupalist, DCO filled in knowledge gaps, and I would like for Stephen to experience the same joy.”

Stephen Ebersole, who was hired recently, works remotely for Rosewood, with his primary residence in Georgia, and currently living in Honduras serving his church. He, like most Rosewood employees, is a member of a Mennonite community.  Adrian explains, “Since Rosewood's target market is businesses run by members of the Plain Communities...besides the native understanding of our target market, we feel that while Drupal may be hard to learn, it is easier to pick up than people skills and a solid work ethic.”  

Adrian highlights the importance of this native understanding by explaining, “Many members of the Plain Communities are devout Christians with strong convictions...If a Rosewood team member does not...appreciate why his or her client will, for example, give up internet access in order to free himself from unnecessary temptations, he or she will not be able to make recommendations that align with our client's values. This understanding is more important to our ability to serve our clients well than expertise in a specific technology.”

Adrian continues, “...as soon as an employee has sufficient proficiency to perform basic tasks, he or she begins working on paid work, even if it means billing our clients at a reduced shop rate for a time. We believe that learning by doing is one of the most efficient ways to learn..though... can leave holes in a person's knowledge. For some of us, taking DrupalEasy's DCO course is about filling in the gaps and providing a common foundation for working together. However, it is also one of the fastest ways I know to get a Drupal beginner up to speed and productive with Drupal.”

The team at Rosewood has used video courses, but they have found for their purposes,  says Adrian, that “...many are too basic or not opinionated enough to apply to most real-life Drupal development practices.” He continues, “For example, they may teach installing Drupal 8 from a tarball, but we had already committed to a composer-driven workflow for Drupal 8 as the safest long-term bet, and I was looking for a course that teaches a professional development workflow. DrupalEasy DCO has proven to be the well-rounded, just-deep-enough training we were looking for, and as long as Drupal remains one of our specialties, we expect to consider it as part of our Drupal training regimen.”

Adrian feels the most valuable aspects of the DCO include clarifying the intersections of fields, blocks, entity types, content types, and relationships, which he says can be an "ah-ha" moment to someone just getting started. He also appreciates becoming familiar with command-line, git, local development, and views, as it is a must for success in Drupal 8, which he feels is a huge hurdle for those getting started. He adds “...the value of DCO lies in how it connects all the pieces, such as workflow, data architecture, module development, theming, and the business of Drupal, together into one comprehensive introduction to the Drupal ecosystem.”

Rosewood’s clients are primarily in the agricultural industry, or are builders, retailers, craftsmen, and small manufacturers, including small businesses such as  Vierbike, MM Weaver and Blue Ridge Furniture. The company is now going with other CMS options for simpler sites, but Adrian emphasizes,  “Drupal continues to excel at use cases that require structured data and over 30 pages. We feel that having Drupal in our tool bag allows us to provide outside-the-box marketing solutions to our clients simply by combining modules and configuring the user interface. On other platforms, competitors may need to resort to custom code or make compromises in order to use an out-of-the-box solution.”

As far as their training philosophy, that is evolving as well, according to Adrian, “In the past, we prescribed training when a person was hired or when they needed to learn something new. However, we have begun budgeting training dollars and time into our annual budgets in order to continually grow as professionals and as a company.” He continues, “Hiring and training people is a way to scale our service-based business to serve more clients. Continued education adds to our in-house skill set to allow us to serve them in more ways and more efficiently. Happy clients = successful Rosewood.” He adds, “We don't know the future, but judging by the past, we will continue to hire and train employees.”

The Fall 2018 session of Drupal Career Online starts September 3rd.  Group rates and government discounts are available. If you‘d like more information, join us for our no-cost mini-webinar Taste of Drupal on Monday, August 27.  

Jul 22 2018
Jul 22

A Drupal Career Online Case Study

Lisa StreeterA lack of off-the-shelf eCommerce software products that could meet the unique needs of her family’s biotech manufacturing company was a real issue for Lisa Streeter. “We’re not a big enough company to afford large, custom database solutions, so we needed to figure out how to do everything in-house,” she explains. (Lisa’s work responsibilities included everything computer-related, and “some other stuff.”) That’s how it started, but instead of just a solution, Lisa Streeter wound up with a whole new, fulfilling career.

Her initial quest for a database solution quickly began to grow her fascination in web development (primarily eCommerce,) and lessen her interest in the family business. “I like the idea that in web development, you’re actually building something, architecting information rather than just analyzing it,” she explains. She fine-tuned her focus, and after discovering Drupal, began to seek an effective way to become proficient.

“I don’t remember exactly how I first learned about Drupal Career Online. I didn’t know anybody who did anything with Drupal, so in the beginning I was just trying to figure out how I could learn Drupal," she explained. She tried some self-teaching methods, but those were not providing her a clear and effective path forward. DrupalEasy was regularly popping up in Google searches and referenced on sites like Drupal.org. “Early on it made my short list of potential “good places to learn Drupal” and then it was just a matter of finding the right time,” she recalls.

It turned out the time was the Fall 2017 session, and according to Lisa, that’s when her interest took a fast track, “I started really getting Drupal. It was a transformative experience.” She dove into the curriculum, participated in class, and DrupalEasy matched her with Matt Glaman from Commerce Guys as her mentor.  From there, her path became clear and direct. “DCO was just the right level of time commitment and intensity for me. It demanded enough of my time and effort to really accelerate the pace of my Drupal learning,” she explained. “At the same time, while I needed to give the class my full attention, it didn’t completely take over my life like going back to school full time would have,” she added.

Lisa has far exceeded our expectations as a developer hired with no previous Drupal experience. The discipline and experience she developed as a PHP developer transferred directly to Drupal development under the tutelage of DrupalEasy, and she's already making a huge impact in our team and community.

-Ryan Szrama, Commerce Guys

The online, live instruction by an expert in Drupal and training was a great fit for Lisa. “Mike is an exceptional teacher who helped me really “get” what Drupal is all about, how to do things and think about solving problems in the “Drupal way.” This was something I wasn’t able to learn on my own from books, screencasts, or trial-and-error,” she recalled.  She also appreciates the small class size and Mike’s personal commitment to everyone enrolled. She explained, his “personal interest in getting to know every student individually made the class seem tailor-made for me, even as I could see that it was also meeting the needs of my classmates in different ways,” she continued.

Mike Anello, (@ultimike) has been a part of the Drupal project for more than 12 years, and developed and has been delivering Drupal career training since 2011 via live in-person and online sessions and contracted programs with organizations needing to train their development teams in Drupal. His curriculum has become the model for the development of several other long-form training programs. He keeps alumni connected and engaged in learning through the DrupalEasy learning community, which evolved from his weekly online office lab hours. According to Lisa, “When you take the DCO course, you definitely feel like Mike is personally invested in the success of each and every student.”

With her interest in eCommerce in mind, Mike connected her with mentor Matt Glaman, a Drupal project maintainer and one of the Commerce Guys.  “For me, this resulted in a perfectly matched mentor, one who challenged me to tackle harder problems than I would have thought possible,” she said.  Matt recognized Lisa’s passion and talent, shared his insights with Commerce Guys partner Ryan Szrama, and then according to Lisa, “It all happened pretty quickly! “ The DCO ended just before Christmas, and she was offered a position on January 16th.

This fast track is a result of Lisa’s passion and Commerce Guys confidence in her abilities and training. She explained, “Ryan decided that he’d rather not hire me as a “Junior Developer”, even though there was an expectation that I’d be learning and working to improve my Drupal skills. Instead, I was hired as a “Drupal Developer,” with the understanding that I’d take responsibility for my own progress.”  It appears she has done just that, since in addition to serving as a developer, she recently was given the opportunity to be “Documentation Lead” (in addition to continuing dev work.)

Six months into her new career, Lisa is clearly fulfilled.  She recounts, “Before I started at Commerce Guys, I was worried about whether I could really handle a real, professional job (working for someone other than my family) while also being a stay-at-home mom.  But Commerce Guys has been a perfect fit in that respect. Many of my coworkers also have young children - everybody at Commerce Guys has been very gracious and understanding about my time.”

Commerce Guys is equally thrilled with Lisa. According to Ryan, "Lisa has far exceeded our expectations as a developer hired with no previous Drupal experience. The discipline and experience she developed as a PHP developer transferred directly to Drupal development under the tutelage of DrupalEasy, and she's already making a huge impact in our team and community."  Commerce Guys is still in hiring mode, looking for "...people who align with our company's core values and core focus. We value making an impact, taking initiative, and serving our customers with integrity. We focus on solving hard problems (our passion) within the eCommerce space (our niche,)" Ryan added.  

In addition to her documentation responsibilities, Lisa is currently doing site building, writing custom code and site administration. She also works on Drupal Commerce and related contrib module issues. “I write patches, including automated test code. Someone from the team reviews my code and gives me helpful feedback, which is also a really great way to learn and improve my coding skills, with the bonus that I’m directly contributing to the Drupal community,” she explains.

“The best part about my new career is that I have a “career.” For years, I’ve had an ambiguously defined job at my family’s company. I didn’t report to anybody, and nobody reported to me; I just “fixed” lots of random problems...I had to invent my own job title. So being able to say now that, “I’m a web developer” is pretty awesome!  

She also loves being part of a team, she explains “After so many years of working independently, it’s great to have job that involves a lot of collaboration, especially when the people I work with are so talented. And being part of the Commerce Guys, an organization that strives to make an impact with the software it creates, I have a sense of greater purpose.”

Even with all of her success, she highlights that she is still learning.  “In DCO, Mike talked about how he’s continually working to improve his own skills and how that’s something you need to enjoy doing to succeed as a web developer. I’m finding that to certainly be true for me. It’s just a really good feeling to be able to look back a month or 6 months and see how much I’ve learned and improved since then,” she explains.

The next session of Drupal Career Online starts September 3. Learn more at an upcoming Taste of Drupal free mini webinar, and check out our career resources for information on web developer and Drupal-specific careers. 

Jul 09 2018
Jul 09

Book cover: Local Web Development with DDEV ExplainedLocal Web Development with DDEV Explained, by Mike Anello, now available on amazon.com!

Looking to move to a professional local development environment? Learn how to use DDEV for your everyday development work with numerous step-by-step examples including installing DDEV, getting an existing Drupal site up-and-running, adding a Solr container, and everyday DDEV commands and workflows.

Only $5.99 for a digital copy and $9.99 for the dead tree edition - pick up your copy today!

Jul 04 2018
Jul 04

Quote: Great hands on intro...We're happy to announce that we've partnered with the folks at DRUD Tech to create and deliver a live, online, hands-on workshop that will teach the basics of professional local Drupal development using DDEV-Local.

DDEV-Local is a Docker-based local development environment that is designed to get your projects up-and-running quickly on your local development machine. DDEV-Local can be used with Drupal 7 and 8 as well as WordPress and other content management systems.

One of the big advantages of using this type of local development environment (as opposed to an old-school WAMP/MAMP-type solution) is that DDEV helps to ensure that every member of the development teams is using the exact same development environment, increasing productivity and decreasing the chances of environment specific bugs. Furthermore, you'll find that getting team projects up-and-running on your local machine is super-fast!

If you've been reading our recent blog posts or listening to our podcast, then you probably already know that we've taken a keen interest in local development environments lately. 

In fact, we've been diving deep into local development environments for almost a full year now, as we're in the process of evolving our long-form training classes to teach and utilize a more professional local development environment solution. A couple of months ago, we decided to standardize our trainings on DDEV, and since then we've been talking with the DRUD Tech folks (the creators of DDEV) about putting together a workshop that will provide students what they need to get up-and-running with DDEV-Local.

Here's a quick overview of what this new workshop will cover:

  • What is DDEV? 
  • Installing DDEV-Local (Mac OS X and Windows 10 Pro)
  • Getting an existing project up-and-running in DDEV-Local
  • Everyday DDEV-Local commands and functionality
  • DDEV-Local integration with hosting providers  
  • Updating DDEV-Local
  • DDEV-Local Tips and Tricks
  • Getting help with DDEV-Local

The first workshop will take place on Wednesday, July 18, 2018, 1-3pm EDT, and the cost is $75. Following the completion of the workshop, you'll have access to the 20+ page curriculum PDF as well as more than 10 screencasts demonstrating installation and basic usage of DDEV-Local. 

Register today and start using a professional local development environment!

We’ll be running the workshop monthly, so If you can't make it on July 18, upcoming dates include: 

  • Wednesday, August 22, 2018, 10am-noon EDT
  • Wednesday, September 19, 2018, 9-11am EDT

Quotes on this page were shared by participants in our beta-test of the course

Quote: Mike consistently ensures...
 

Jun 18 2018
Jun 18

Stefanie Gray, (stefaniegray), Engineer and Open Data Specialist for CivicActions joins Mike Anello to discuss all things DKAN.

Interview

DrupalEasy News

News

Sponsors

  • Drupal Aid - Drupal support and maintenance services. Get unlimited support, monthly maintenance, and unlimited small jobs starting at $99/mo.
  • WebEnabled.com - devPanel.

Follow us on Twitter

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

May 27 2018
May 27

This summer, we're taking the all-new "Upgrading your local development environment with DDEV" lesson from our 12-week Drupal Career Online class and bringing it with us as we visit three different Drupal events around the USA. At each event, we'll be presenting it as a full-day workshop at no- or (very) low-cost to event attendees.

Twin Cities Drupal Camp, Asheville Drupal Camp, Colorado DrupalCamp logos

If you're looking to move your local development environment to a more modern solution, then we believe this workshop is exactly what you're looking for. DDEV is a Docker-based environment built on modern principles and designed to be flexible, customizable, and powerful. 

We have been using DDEV with our current Drupal Career Online students, and are confident that our workshop is providing the skills they need to use it as their day-to-day local environment. The workshop (and DDEV) is designed for developers on Mac OS X and Windows 10 Pro - at the end of the day, you'll have the confidence you need to make the switch.

In addition to the full-day of training, you'll also leave with access to our 20+ page workshop handout (PDF) as well as access to all of our DDEV-related screencasts.

So, if you're interested in making the change, be sure to sign up for one of our in-person workshops this summer!

May 19 2018
May 19

Have you ever been building a form and found yourself wishing that you could insert additional help text - or even other forms of content (images, video) inline with the form? While each field's "Description" field is useful, sometimes it isn't enough.

The Markup module solves this problem in an elegant way by providing a new "Markup" field type.

Markup field type

This field doesn't expose any input widgets to the end user, rather it just allows for site builders to add additional markup (content) to an entity form.

Editing a Markup field.

The markup isn't saved with the resulting entity - it's just there to provide additional information to the user filling out the form.

Granted, this has always been possible by writing a small custom module utilizing hook_form_alter(), but having it as a field type makes it much more convenient to use.

Apr 24 2018
Apr 24

Ted Bowman and Mike Anello, both back from DrupalCon Nashville, spend some quality time together to catch up on all the latest happenings involving local development environments. Ted hosted some BoFs about the topic, and Mike posted a comparison of some of the more popular Docker-based, Drupal-focused local development tools, so we figured it was a good time to devote an entire podcast on the topic. In addition, Mike and Ted name their "favorite thing" from DrupalCon Nashville.

Discussion

Sponsors

Follow us on Twitter

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Apr 23 2018
Apr 23

With Drupal 8, the use of view modes (both default and custom) is gaining momentum. This is especially true because of their ability to be easily utilized by Views. Rather than specifying a list of fields with all the required configuration in a View configuration, many site-builders are finding it much easier to define a set of view modes for their entities, have them themed once, then re-used throughout the site - including as part of a View's output via the "Show: Content" option in a View's "Format" configuration. 

One hiccup that can slow this down is the not-uncommon occurrence of when a field needs to be output as a link to some destination. While this is relatively easy to do with Views' "Rewrite fields" options, there isn't an obvious solution when using view modes.

Enter the Linked Field module. As its name implies, it provides the ability for any field to be output as a link via its formatter settings. The formatter can be configured with a custom URL or it can use the value of a URL from another field value.

Linked Field module formatter settings

Think of this module as an "Output this field as a custom link" option for view modes!

The "Advanced" configuration section for the formatter settings includes the ability to custom things like the title, target, and class attributes for each link. 

If your goal is to maximize the use of display modes throughout your site, then this contributed module is an important tool in your arsenal.  

Mar 25 2018
Mar 25

Brooke Candelaria, (htownbrooke), the new Conference Director for the Drupal Association joins Mike Anello to introduce herself to the Drupal community as well as to provide a preview of DrupalCon Nashville as well as her thoughts on the evolution of DrupalCon Europe. Topics discussed include trivia night, the decoupled summit, rodeos, Hurricane Harvey, The Princess Bride, the DrupalCon Europe licensing bidding process, shoulder pads, and perhaps the greatest answer ever to our always challenging "exotic animal" question.

Interview

DrupalEasy News

Sponsors

  • Drupal Aid - Drupal support and maintenance services. Get unlimited support, monthly maintenance, and unlimited small jobs starting at $99/mo.
  • WebEnabled.com - devPanel.

Follow us on Twitter

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Mar 20 2018
Mar 20

Over the past year or so, I've been looking to replace my standard local development environment with a Docker-based solution. I've been evaluating DDEV, Docksal, and Lando (listed alphabetically), trying to figure out not only was the best for me, but also the best for me to teach and recommend to the hundreds of folks I teach both long-form and full-day Drupal workshops to each year. As I've test-driven each of these three options, I've been periodically posting tutorials on various related topics.

DDEVAs a long-time Mac OS X user, my previous go-to local development stack has been a mix of MAMP Pro and Acquia Dev Desktop. For teaching, I've mainly been recommending Acquia Dev Desktop, but I think the time has come for a more flexible and professional-level solution. The ability to customize each project's development environment with various versions of PHP, different database and search index servers (adding a Solr server to any of the options in this article is just plain easy), and other things is too big of an opportunity to let pass.

My evaluation of DDEV, Docksal, and Lando has not been quick. I've been using Docksal for several client projects for well over a year now. In fact, during the initial Mastering Professional Drupal Development Workflows with Pantheon course, I recommended it to all of our students. I've even written and shared a somewhat Pantheon-flavored version of a Docksal configuration. It includes custom scripts for automatically downloading and importing a copy of a remote Pantheon database to the local environment as well as running some initial Drush commands after the import is complete.

As the Lando project matured, I was attracted to it mainly for its recipe-based configuration, including a Pantheon-flavored recipe that outdid my custom Docksal scripts. Currently, I'm using Lando for about 5 different client projects (as well as my local development environment for DrupalEasy.com).

Finally, a few months ago, I saw down with a few folks from the DDEV project at BADCamp for an extended walkthrough. It took me another month or two before I really dove into it, using it for a new client project, but at this point (spoiler alert), I'm leaning towards it being my go-to local development environment for teaching.

Comparison

What follows below is just a summary of the various features that I've focused on while test-driving each option. By no means it is a comprehensive list of features, but I think it is safe to say that these are what are most important in my use cases. As I mentioned above, my needs are twofold: a solid local development environment for client work, and an easy-to-install-and-configure local development environment for my students on both Windows and Mac OS X. I imagine that most folks don't have the latter requirement, so be sure to select the best environment for your needs.

In no particular order, here's what I focused on:

User interface

All three options are only command-line driven at this point; none have a graphical user interface (yet). All three options provide a command-line tool with different (but similar) commands. For example:

  • To start a project's containers: lando start, fin start, ddev start ("fin" is Docksal's command-line tool)

  • To stop a project's containers: lando stop, fin stop, ddev stop

As Lando evolved from Kalabox, there is talk that a GUI may be part of a paid add-on in the future. The DDEV team has also made it known that a GUI is in currently being developed.

Hard drive space

As all three options are Docker-based; each project on your local has its own set of containers. I've found that for a typical project, these containers require (I think) around 500(ish)MB of hard drive space (not including your project's data). Obviously, this can add up quickly depending on the number of projects you have on your local. I've found that DDEV has an advantage in this area, as it stores your project's data (database, files directory) in a directory shared with the host operating system - so you can remove a project's containers without losing your site's data (database) - thus saving hard drive space. For someone like me who creates a lot of sites (for teaching), this is non-trivial. DDEV's "ddev remove" command that removes only the containers. If you want to remove a project's data as well, "ddev remove --remove-data" does the trick. Both Lando and Docksal have commands to remove a project's containers and data as well, but neither (currently) has an option to preserve data.

LandoAs someone who had zero knowledge/experience with Docker at the beginning of this process, estimating how much hard drive space this stuff takes up is a bit of a black art. The "500(ish)MB" number I mentioned in the previous paragraph isn't anything more than an estimate as I watch my available hard drive space grow and shrink as I create and remove sites. I would love to have easy-to-use commands (for someone that isn't familiar with Docker) showing how much space is being used, options for clearing Docker caches, and anything else that could help developers manage hard drive space.

Drush and Drupal Console support

DDEV, Docksal, and Lando's command line tool provide a command to run Drush commands: fin drush <drush-command>, lando drush <drush-command>, ddev exec <drush-command>.

Pantheon and other remote host support

I tend to use Pantheon quite a bit, both for clients and teaching. The ability to easily get a local environment's database up-to-date from a remote environment quickly is a huge time-saver (and solid development practice). Having integration with Pantheon (and hopefully other hosts in the future) is an important factor for me.

  • DDEV's Pantheon integration isn't as complete, but it does have the valuable "pull" command which will bring down the database and files directory. I really wish it had separate commands for pulling the database and files directory. Often, it only makes sense to only pull the database, and then use something like Stage File Proxy for local files.

  • Docksal lags behind in this area - it don't provide any built-in tools for interacting with remote hosts, but they do provide useful examples for creating your own custom commands.

  • Lando has the edge here, with its robust push-and-pull commands for moving databases, files directories, and codebases between your local and any remote Pantheon environment.

Pre-made configurations

  • DDEV has various "quickstarts", similar to Lando's recipes, including ones for Drupal 6, 7, and 8, as well as Backdrop, Wordpress, and Pantheon hosting.

  • Docksal provides some basic default stack configurations, including an Acquia Cloud one, but not on the same level as Lando or DDEV. UPDATE: I've been corrected - Docksal does example configurations available for Drupal 7, Drupal 8, WordPress, and a few other CMSs.

  • Lando provides local development environment "recipes" for a plethora of development projects - including recipes for Drupal 6, 7, and 8, as well as recipes for Pantheon, Python, Dotnet, Joomla, Wordpress, and several other commonly used frameworks and providers (it is really quite impressive).

It doesn't appear that any of the options support Acquia, Platform.sh, or any of the other so-called "modern" Drupal hosting solutions (yet), but I don't think there's anything stopping that from happening in the future. In fact, it is already starting to happen.

Support and Documentation

All three options have both issue queue support as well as real-time chat support. Your mileage may vary, but I've found all three projects have very responsive maintainers, with a slight edge going to DDEV for responsiveness.

In addition, they all have relatively good documentation, considering their rapid development schedules and frequent additions. With all three options, I've found that I've had to hunt down answers not easily found in the documentation.

As an example, a few times while creating a new DDEV-powered site, I kept getting a message that port 443 was in use, but I couldn't figure out by what. It was easy enough to change the DDEV config to use a different port number, but it wasn't until I stumbled on a blog post where I learned about "lando poweroff" - this command spins down all Lando containers, including a "traefik" container that holds on to - you guessed it - ports 80 and 443. While there is a documentation page for "lando poweroff", there's nothing on the "Getting started" documentation page about it. It was only by searching the web and finding a blog post that I was able to figure out what the root cause of the issue was. I'm not picking on Lando here (far from it), as I've run into similar documentation issues with DDEV and Docksal as well. Bottom line - use all the support resources available to you.

Frequency of updates

One measure of a project's health and momentum is the frequency of updates. In all three cases, development is clearly on-going in each project.

  • DDEV - 6 releases in 2018 (5 minor, 1 patch), 13 releases in 2017 (10 minor, 3 patch).  

  • Docksal - 0 releases in 2018, 11 releases in 2017 (1 major, 6 minor, 1 patch).  

  • Lando - 4 releases in 2018 (4 betas), 51 releases in 2017 (20 alphas, 31 betas).  

Windows support

While I'm a Mac OS X user, not all of my students always are. Therefore, it is important to me that I select a tool that works well on both Mac and Windows, with a minimum of any "unique configurations" on Windows. All three options utilize some form of automated testing to ensure that each build works on both platforms. To date, I haven't discovered any major issues with any of these tools on Windows. In all cases, I've found it to be much easier to use a 3rd-party command line emulator, rather than using Windows' default command line tools.  

Requires internet connection

  • DDEV works fine without an internet connection - no configuration necessary.

  • Docksal can be run without an internet connection by manually adding an entry to your hosts file via the "fin hosts add mysite.docksal" command.

  • Lando has a documentation page about offline development, but it is only for Mac OS X, and the process is a bit more involved. UPDATE! I goofed! The previous link is if you want to manage your own local DNS, if you just want to work offline, it is much easier!

PHP options

All three tools provide the ability to swap in different versions of PHP via their configuration files.

  • Docksal allows you to place a partial php.ini file as part of your project's configuration. The directives in this file will override any default PHP settings provided by the container.

  • Lando has some support for some PHP settings as part of their configuration files and also supports a php.ini file as part of a project's configuration.

In all three tools, it is possible to ssh into the CLI container and modify the php.ini settings directly - using this approach, these changes are only temporary, however, as the next time the container is rebuilt, the custom php.ini changes will be lost.

Performance

DocksalWhile I didn't run a full suite of tests on all three options, I did want to quantify their relative speed in a real-world situation. My method was to take an actual (Drupal 8) client site, get it up-and-running in all three options (sequentially), and simply time how long it took to run a "drush cache-rebuild all". I ran the command three times for each option and then calculated the average. Other factors depending on your exact site and configuration may come into play (having Xdebug enabled is a bit of a performance hit), so your mileage may vary.

  • DDEV: 90 seconds
  • Docksal: 20 seconds  
  • Lando: 89 seconds  

Why the huge advantage for Docksal? It's pretty simple - I'm currently using Docksal in "virtual machine" mode instead of utilizing Docker for Mac (both Lando and DDEV utilize Docker for Mac/Windows). It's pretty well-known that native Docker for Mac/Windows solutions are a bit performance-challenged. According to Docksal documentation, Docker for Mac/Windows will eventually become the recommended way of working with Docksal, despite the performance losses.

Other stuff

  • Docksal has a cool "automatic stand-alone CLI container" - this is a container that is not tied to a specific project and is always available. One big advantage to this container is that it can be used to run Composer commands without having to have Composer installed on the host operating system. This is (IMHO) a big deal on Windows, where installing Composer can be tricky (due to its dependency on PHP). There is talk for doing something similar in Lando as well as DDEV.  

  • Docksal utilizes a separate command to start and stop its main virtual machine (fin vm start/stop). It's not a big deal, just a small extra step (but the performance gains are worth it, as mentioned above.)

  • DDEV automatically writes a settings.local.php file, overwriting the entire file. So, if you're like me and you like to have configuration settings specific to your local environment (Stage File Proxy, Environment Indicator, as well as some of the stuff found in example.settings.local.php, you'll have to either recreate your settings whenever DDEV overwrites the file, or you can create a second settings.local2.php file. There is an open issue about possibly modifying this behavior.

Summary

Things I love about each option

  • DDEV - the fact that I can completely remove a project's containers without losing the project's database (and other data) is really nice. While their Pantheon integration isn't as robust as Lando's, it does enough (for now). The team behind DDEV appears to have the most consistent release schedule, and I've found their various support channels to be the most responsive. Also - DDEV has a "ddev sequelpro" command that automatically launches the Sequel Pro app (Mac OS X) and connects to the current project's database. I know it's a trivial thing, but I love it so much.

  • Docksal - its fast. If/when the maintainers decide to make using Docker for Mac/Windows the default, it'll be back on even ground with DDEV and Lando, but for now, it's just plain fast. I also really like that Docksal includes a "fin run-cli" command that allows you to run Composer commands ("composer create-project", for example) before setting up a project's containers. So handy.

  • Lando - its Pantheon integration is second-to-none. The ability to push and pull code, database, and/or files makes it a breeze when integrating with Pantheon sites. I'm really looking forward to when additional hosting-based recipes are available.

Things I don't love about each option

  • DDEV - I use a MacBook Air with 8GB RAM and a 1.7GHz Intel Core i7 as my main development machine. The stunning performance gap between DDEV and Lando compared with Docksal is completely attributed to Docker for Mac. I don't know all the ins-and-outs about why its performance is so lame, but I find it maddening sometimes. Also, the settings.local.php issue I mentioned above, but fingers-crossed that gets resolved soon.

  • Lando - re-read what I just wrote about DDEV (except for the settings.local.php stuff). Same. Also, whenever Docker is restarted, the Lando proxy also automatically starts up and grabs hold of port 443 - regardless of if I have any local Lando sites up-and-running. This can cause conflicts with other processes that want to use that port. Lando's "push" command for Pantheon is a little too aggressive for my tastes - it automatically adds, commits and pushes all outstanding changes in your local codebase to the Pantheon repository (I don't care for "git add ." either).

  • Docksal - lack of Pantheon integration. Granted, it's not terribly difficult to write custom commands to automate pulling databases from Pantheon, but it sure would be nice if it was built-in.

While going through this exercise, I've realized that there's really no single globally "the best" solution. There are pros and cons for each option, and it's really up to the developer (or development team) to determine what's best for them.

Regardless of which option you decide to go with, here are some important things that I've learned:

  • Pay attention to updates and apply them appropriately (including Docker updates if you're using DDEV or Lando). The pace of each option is such that something that doesn't work today might very well be fixed in the very near future. Pay attention to the release notes for each update, as sometimes there are incompatibilities with specific versions of Docker.

  • All of these options take up a non-trivial amount hard drive space for each project. For projects that are dormant, go ahead and destroy the containers - that's the whole point of having a solid developer workflow. Recreate the containers (re-import the DB and files directory if you're using Lando or Docksal) when you need to work on the project again.

  • Get familiar with the real-time chat support for whichever option you go with. They can be real time-savers.

Which will I be using going forward? For client work, the answer is "probably all three". For more complex sites, I'm addicted to Docksal's performance. For teaching, I'll be test-driving standardizing on DDEV starting with the Spring, 2018 class of Drupal Career Online. It's ease of installation on both Windows and Mac OS X, along with its straightforward commands, hard-drive-space-saving architecture, and incredibly responsive support channels give it the edge (at least for me) over Lando.

Which solution should you use? It really depends on you and/or your team's situation. You're going to want to take into account factors such as host operating system (Mac OS X or Windows), hosting environment (on-site, managed VPS, Acquia/Pantheon/Platform.sh), skill level, and other factors. We're experiencing a bit of a renaissance in local development environments with a good deal of innovation and momentum - which makes it a buyer's market, so take advantage and find the solution that works best for you.

Official project links

Blog posts

Acknowledgements

Thanks to Mike Pirog from the Lando project, Rick Manelius from the DDEV project, and David Hernandez from the Docksal project for their input on this blog post.

Mar 12 2018
Mar 12

David Needham (davidneedham), Developer Advocate with Pantheon as well as a long-time Drupal community member and trainer, joins Mike Anello to discuss his new-ish role at Pantheon, tools for trainers, and a bit of a rabbit-hole into local Docker-based development environments.

Interview

DrupalEasy News

Upcoming events

Sponsors

Follow us on Twitter

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Mar 04 2018
Mar 04

DrupalEasy faviconEvery Drupal 8 site should have a custom favicon that helps to reinforce the site's brand - of this there is really no argument. But, over the past (more than a few) years, the role of the lowly favicon has grown from just the little icon on a browser tab. These days, favicons are also used on mobile devices as the gateway to your site. Keeping your brand strong in all contexts is more important than ever.

Luckily, the Responsive Favicons module, combined with Favicon Generator makes it pretty easy to keep your site's branding consistent across multiple platforms. 

Favicon contexts

Assuming you have a relatively square-ish version of the site's logo, making this all happen is pretty easy.

First - head to Favicon Generator, upload the site's logo, then review/tweak the settings for the various contexts. You'll be asked for the "App name" (usually the site's name), suitable background colors (I selected a nice pear-color for the DrupalEasy logo - you can see it in the iOS mockup above), as well as image overrides (optional) for each context. For the "Favicon Generator options", select the "I will place favicon files at the root of my web site" option (at the recommendation of the Responsive Favicons module maintainers). At the end of the process, you'll get a zipped file full of all the necessary icons and meta data. 

Next, download and install the Responsive Favicons module. Head to its configuration area (/admin/config/user-interface/responsive_favicons) and complete the form. For the "Path to responsive favicon files", I just used "favicons". The "Favicons tags" section is provided at the end of the Favicon Generator's process. Finally, point the zip file generated by the Favicon Generator to the final form field. Click to "Save configuration" and you should be all set!

Lessons like this (and much, much more) are taught during our 12-week, 3x/week Drupal Career Online course. Learn more and register for our free Taste of Drupal webinar to dive into the details of the course.

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web