Drupal Feeds

Week 10: Finishing Social Post Implementer and GSoC Meetup At LNMIIT himanshu-dixit Thu, 08/10/2017 - 23:24

Pluralizing and singularizing words got very easy with the inclusion of the Doctrine Inflector class.

This week whilst trying to update one of our projects to the latest version of Drupal 8 core, we had some issues.

We use Composer to manage our dependencies, modules etc, and on this particular occasion, things weren't straightforward.

In order to solve it, we had to use some of the lesser known features of Composer, so decided to share.

Share:

This week whilst trying to update one of our projects to the latest version of Drupal 8 core, we had some issues.

We use Composer to manage our dependencies, modules etc, and on this particular occasion, things weren't straightforward.

In order to solve it, we had to use some of the lesser known features of Composer, so decided to share.

by lee.rowlands / 11 August 2017 The problem

So updating Drupal core with composer is normally pretty simple. And on this occasion, we had no reason to suspect it would be anything different.

Normally we'd just run

composer update "drupal/core" --with-dependencies

But this time, nothing happened.

So we checked that there was a newer version available

composer show -a "drupal/core"

And sure enough, we can see 8.3.6 in the available versions.

Time to dig deeper.

The why

Luckily, composer will tell you why it won't install something.

composer why-not "drupal/core:8.3.6"

Which yielded

drupal/core 8.3.6 conflicts drush/drush (<8.1.10)

Aha, so drush is the issue.

So maybe we just update both

composer update "drupal/core" "drush/drush"

Nope.

Digging deeper

So after trying a few different combinations of version constraints etc, we decided to remove drush, update and then add it back.

composer remove --dev "drush/drush"

Which worked.

composer update "drupal/core" --with-dependencies

Ok, nice, we now have Drupal 8.3.6

composer require --dev "drush/drush"

Nope.

Your requirements could not be resolved to an installable set of packages. Problem 1 - Installation request for drush/drush 8.1.12 -> satisfiable by drush/drush[8.1.12]. - Conclusion: remove phpdocumentor/reflection-docblock 3.2.2 - Conclusion: don't install phpdocumentor/reflection-docblock 3.2.2 - drush/drush 8.1.12 requires phpdocumentor/reflection-docblock ^2.0 -> satisfiable by phpdocumentor/reflection-docblock[2.0.0, 2.0.0a1, 2.0.0a2, 2.0.0a3, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5]. - Can only install one of: phpdocumentor/reflection-docblock[2.0.0, 3.2.2]. - Can only install one of: phpdocumentor/reflection-docblock[2.0.0a1, 3.2.2]. - Can only install one of: phpdocumentor/reflection-docblock[2.0.0a2, 3.2.2]. - Can only install one of: phpdocumentor/reflection-docblock[2.0.0a3, 3.2.2]. - Can only install one of: phpdocumentor/reflection-docblock[2.0.1, 3.2.2]. - Can only install one of: phpdocumentor/reflection-docblock[2.0.2, 3.2.2]. - Can only install one of: phpdocumentor/reflection-docblock[2.0.3, 3.2.2]. - Can only install one of: phpdocumentor/reflection-docblock[2.0.4, 3.2.2]. - Can only install one of: phpdocumentor/reflection-docblock[2.0.5, 3.2.2]. - Installation request for phpdocumentor/reflection-docblock (locked at 3.2.2) -> satisfiable by phpdocumentor/reflection-docblock[3.2.2]. Installation failed, reverting ./composer.json to its original content.

Hm, so we have a version of phpdocumentor/reflection-docblock in our lock file that is too high for drush.

composer why "phpdocumentor/reflection-docblock"

Yields

phpspec/prophecy v1.6.1 requires phpdocumentor/reflection-docblock (^2.0|^3.0.2)

Aha, so prophecy - but it allows either version .. but our lock file has pinned it to the 3.x branch

So lets force composer to downgrade that

composer require --dev "phpdocumentor/reflection-docblock:^2.0"

Now lets see if we can add drush back

composer require --dev "drush/drush"

Success!

Now all that remains is to clean up, because we don't really want to depend on phpdocumentor/reflection-docblock

composer remove --dev "phpdocumentor/reflection-docblock"

Done - quick - commit that lock file while you're winning!

Summary

So while it might be easy to curse Composer for not letting you upgrade, its actually doing exactly what you told it to do.

Your lock file has a pinned version, it is honoring that.

And in order to resolve it, Composer provides all the tools you need in the form of the why and the why-not commands.

Tagged Composer, Drupal 8

Posted by lee.rowlands
Senior Drupal Developer

Dated 11 August 2017

Add new comment

I’ve recently embarked on my first official Drupal 8 project, for Sinvict Technology (case study when the project launches), and it was interesting to see how certain things changed for the better, certain things stayed familiar and certain things seemed slightly worse off. I thought I’d write up some comparison notes between the two versions. This is my personal opinion based on my experiences. You should have your own opinion too.

Core is so much better

I really like the improvements made to core for Drupal 8. Making views part of core was a great idea, as was making the date field core as well. I felt the organisation of files in the new folder structure was more intuitive...

PHP 7 can help improve Drupal site performance

Drupal is PHP 7-ready and sites that run many contrib modules, or particularly memory-intensive ones, will need more memory requirements. Optimizing Drupal website performance with PHP 7 version will boost the overall page speed. 

PHP 7 was released in December 2015 and offers high performance, huge load capacity and asynchronous programming support  for online applications. According to the latest study, PHP 7 is twice as fast as PHP 5.6 and reduces memory usage.

Why this is the right time to move to PHP 7

Drupal 7 core officially supports PHP 5.2.5 or higher  However, PHP 7 introduces backward incompatible changes which may need to be addressed in contributed or custom modules and themes. While some Drupal 7 sites may run on minimum of PHP versions, you can move to Drupal 8 with PHP 7 support to enhance the performance of the site.

Drupal 8 officially supports 200+ new features and improved functionalities, and upgrading to PHP 7 brings a lot of improvements and delivers high performance Drupal site, whether you are a website owner or a Drupal developer

Drupal core's automated test suite is now fully passing on a variety of environments where there were previously some failures (PHP 5.4, 5.5, 5.6, and 7). Several bugs affecting those versions were fixed as well. These PHP versions are officially supported by Drupal 7 and recommended for use where possible.

Anecdotal evidence from a variety of users suggests that Drupal 7 can be successfully used on PHP 7, both before and after the 7.50 release. 

A slow website load time impacts visitors, overall user experience, and the bottom line. With the improved speed enhancements of Drupal 7 and Drupal 8 with PHP 7, your user engagement and experience will increase and less likely they will leave your website

admin Fri, 08/11/2017 - 06:38 Drupal 8 Drupal Application Development
Drupal 8 ships with a great and easy to use 'vertical_tabs' form element but unlikely a horizontal counterpart is missing. I'll show you, how can get horizontal tabs into your forms.

Combining different tools to produce fantastic reactions is the true “chemistry” of web development. The special trend of the day is using Drupal with JavaScript tools. We’ve had a chance to look at the benefits of using Drupal with Angular and Drupal with Node.

Read more
What is CSP?

Content Security Policy – or CSP – is a security feature of modern browsers. Browsers will ignore data from domains that are not cleared in the CSP http-response header. For instance if you embed a YouTube movie on a webpage and the domain is not whitelisted in the CSP header, then the movie will not be loaded. All traffic from youtube.com will be blocked and the movie cannot be displayed.

Start:  2017-08-15 12:00 - 2017-08-17 12:00 UTC Event type:  Online meeting (eg. IRC meeting)

The monthly security release window for Drupal 8 and 7 core will take place on Wednesday, August 16.

This does not mean that a Drupal core security release will necessarily take place on that date for any of the Drupal 8 or 7 branches, only that you should watch for one (and be ready to update your Drupal sites in the event that the Drupal security team decides to make a release).

Drupal 8.4.0-beta1 will also be released sometime during the week to continue preparation for the upcoming minor release in October.

There will be no bug fix or stable feature release on this date. The next window for a Drupal core patch (bug fix) release for all branches is Wednesday, September 06. The next scheduled minor (feature) release for Drupal 8 will be on Wednesday, October 5.

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

E3 Named Finalist in 5 Acquia Engage Award Categories E3 Named Finalist in 5 Acquia Engage Award Categories root Mon, 08/14/2017 - 12:04

As an Acquia Preferred Partner, we are thrilled to announce our work has ranked amongst the world’s most innovative websites and digital experiences in the 2017 Acquia Engage Awards. Elevated Third received recognition in the Nonprofit, Brand Experience, Financial Services, Digital Experience, and Community categories for the following projects. 

The Acquia Engage Awards recognize the amazing sites and digital experiences that organizations are building with the Acquia Platform. Nominations that demonstrated an advanced level of visual design, functionality, integration and overall experience have advanced to the finalist round, where an outside panel of experts will select the winning projects.

Winners will be announced at Acquia Engage in Boston from October 16-18, of which we are sponsors.  

“Acquia’s partners and customers are setting the benchmark for orchestrating the customer journey and driving the future of digital. Organizations are mastering the art of making every interaction personal and meaningful, and creating engaging, elegant solutions that extend beyond the browser,” said Joe Wykes, senior vice president, global channels, and commerce at Acquia. “We’re laying the foundation to help our partners and customers achieve their greatest ambitions and grow their digital capabilities long into the future. We’re inspired by the nominees and impact of their amazing collective work.”

Check out our competition! The full list of finalists for the 2017 Acquia Engage Awards is posted here.

Round up your front-end JavaScript libraries with Composer phenaproxima Mon, 08/14/2017 - 18:03

In Lightning 2.1.7, we’re finally answering a long-standing question: if I’m managing my code base with Composer, how can I bring front-end JavaScript libraries into my site?

This has long been a tricky issue. drupal.org doesn’t really provide an official solution -- modules that require JavaScript libraries usually include instructions for downloading and extracting said libraries yourself. Libraries API can help in some cases; distributions are allowed to ship certain libraries. But if you’re building your site with Composer, you’ve been more or less on your own.

Now, the Lightning team has decided to add support for Asset Packagist. This useful repository acts as a bridge between Composer and the popular NPM and Bower repositories, which catalog thousands of useful front-end and JavaScript packages. When you have Asset Packagist enabled in a Composer project, you can install a Bower package like this (using Dropzone as an example):

$ composer require bower-asset/dropzone

And you can install an NPM package just as easily:

$ composer require npm-asset/dropzone

To use Asset Packagist in your project, merge the following into your composer.json:

"repositories": [ { "type: "composer", "url": "https://asset-packagist.org" } ]

Presto! You can now add Bower and NPM packages to your project as if they were normal PHP packages. Yay! However...

Normally, asset packages will be installed in the vendor directory, like any other Composer package. This probably isn’t what you want to do with a front-end JavaScript library, though -- luckily, there is a special plugin you can use to install the libraries in the right place. Note that you’ll need Composer 1.5 (recently released) or later for this to work; run composer self-update if you're using an older version of Composer.

Now, add the plugin as a dependency:

$ composer require oomphinc/composer-installers-extender

Then merge the following into your composer.json:

"extra": { "installer-types": [ "bower-asset", "npm-asset" ], "installer-paths": { "path/to/docroot/libraries/{$name}": [ "type:bower-asset", "type:npm-asset" ] } }

Now, when you install a Bower or NPM package, it will be placed in docroot/libraries/NAME_OF_PACKAGE. Boo-yah!

Let's face it -- if you're using Composer to manage your Drupal code base and you want to add some JavaScript libraries, Asset Packagist rocks your socks around the block.

BUT! Note that this -- adding front-end libraries to a browser-based application -- is really the only use case for which Asset Packagist is appropriate. If you're writing a JavaScript app for Node, you should use NPM or Yarn, not Composer! Asset Packagist isn't meant to replace NPM or Bower, and it doesn't necessarily resolve dependencies the same way they do. So use this power wisely and well!

P.S. Lightning 2.1.7 includes a script which can help set up your project's composer.json to use Asset Packagist. To run this script, switch into the Lightning profile directory and run:

$ composer run enable-asset-packagist
This year European DrupalCon will take place in Vienna, Austria. It's still more than a month away. However, the sessions were already selected. We will look at the ones, which were accepted in the business track. And we will also explain why. DrupalCon Vienna is one of the biggest Drupal events in the world this year. Therefore, some of our team members will be present at the event in the capital city of Austria. But once again our AGILEDROP team will not be just present at the event. We had a »bigger« role. Namely, our commercial director Iztok Smolic was invited to the Business track… READ MORE
Payment and Mollie on Drupal 8 christophe Tue, 15/08/2017 - 10:22 Mollie provides a facade for several payment methods (credit card, debit card, Paypal, Sepa, Bitcoin, ...) with various languages and frameworks support. In some cases, you could decide to use the Payment module instead of the full Commerce distribution. This tutorial describes how to create a product as a node and process payment with Mollie, only via configuration. A possible use case can be an existing Drupal 8 site that just needs to enable a few products (like membership, ...).
Drupal Modules: The One Percent — Pagerer (video tutorial) NonProfit Tue, 08/15/2017 - 07:23 Episode 31

Here is where we bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll consider Pagerer, a module which offers many options when customizing your pagers.

Creating unique content is a direct way both to Google’s and your customers’ hearts, and Drupal 8 is making the road much smoother and the journey more enjoyable! Creating interactive HTML5 content and content modelling in Drupal 8 are just a couple of examples we’ve already described.

Read more

The Mediacurrent team is excited to be supporting the inaugural Decoupled Dev Days event in NYC this week (August 19-20) as organizers and sponsors! We hope you’ll be joining us, however, we know how busy summer weekends can be so we will be sharing session recordings after the event.
 

In part two of our Webform tutorial, we’ll show you how to create multipage forms, apply conditional logic, create layouts and much more! We’ll take the simple newsletter signup form created in part one of this tutorial and add additional pages. Then we’ll demonstrate how to show or hide an element depending on the selection made on another element. We’ll also look at layouts and then finish off with an overview of some of the other great features Webform has to offer. For forms with many elements, it’s best to spread them across two or more pages. In this section, we’ll take the form we created in part one and move some of the elements to make a two page form. We’ll also add a preview page and make changes to the confirmation screen.
Decoupled Drupal Technologies and Techniques Decoupled Drupal Technologies and Techniques Joe Flores Tue, 08/15/2017 - 12:17

Part 3 in this series is continued from a previous post, Decoupled Drupal: A 10,000ft View.

One of the main considerations when building the POWDR website was uniformity. POWDR is a holding company composed of many separate companies, all with individual websites. In order to ease the burden on content admins, we sought a solution that avoided multiple content types for each separate site. As a holding company with so many websites to maintain, managing many content types can become really complicated really quickly. It was our job to keep the content admins at top of mind in order to make their job updating the various websites as easy as possible.

Drupal Multisite for Easier Administration

The reason we ended up going with a multisite is that for each POWDR property there is a separate Drupal instance. In typical ski industry form, POWDR continues to acquire additional resorts and companies. They are constantly bringing on companies with different processes, different applications, and different third-party vendors. Many have different teams acting as admin. So, one of our first considerations was how people on the main POWDR team were going to administrate and edit all of this content.

We considered doing it all in one large API site though that plan quickly became too complicated when it came to permissions. Instead, it was decided that the project would be split up into multiple sites. Acquia made this process nice and easy. Using Acquia and Drupal 8, we were able to spin up a new multisite instance within the parent Drupal instance.

After some practice, we are now able to spin up a new instance in a matter of minutes. Using Drupal 8 and configuration, we copy the configuration from a parent skeleton site into a new site This allows the design team to start their development process with a basis on the API side without us having to reprogram and rebuild from the ground up.

Paragraphs Makes Complex Content Manageable

Working with Hoorooh Digital, we created an overarching entity structure using paragraphs that allowed us to make a baseline unit to build upon. Each paragraph was essentially a different piece of the website. They made components within Angular line up with paragraphs on the Drupal side. If you’re not familiar with paragraphs, in Drupal 8, their entities in and of themselves. This was nice for us because it allowed us to load and alter them programmatically, much like any other entity on the backend. They could be rearranged and served to the frontend from any site to meet design needs.

Implementation was one of the larger challenges of the POWDR project. The difficulty arose as we matched up the frontend to the Drupal backend. Custom code was required to ingest the paragraphs in the components. If you’re thinking about taking on this project, be sure to consider this step during the estimation process. In our experience, a good portion of the frontend development was required to render frontend components. We took the time to decide how componentry and paragraphs would be ingested from the Drupal platform, then matched up with the frontend framework. This allowed us to standardize all of the content coming out of the API so that frontends wouldn’t have to be rewritten for every site.

D8 and JSON REST API Decrease Development Time

The real power here was that, out-of-the-box, Drupal 8 does have a JSON REST API. We took that and ran with it. We realized early on that the Angular frontend and the out-of-the-box JSON API were going to require a lot of work to get them to work together. Instead of sacrificing this time, we extended the JSON encoder class in Drupal 8 and created our own POWDR format JSON encoder. This allowed us to create a serializer service and a bunch of custom entity normalizers. We then added related entities and some custom processing to meet the frontend needs. Out-of-the-box, the JSON API is built so that you’re requesting each related entity down the line. You get an entity ID and then you make another call to the API to get the content of that entity.

Essentially, what we did by extending the JSON encoder and all the entity normalizers was create an entity reference class. By using this structure we were able to load related entities, such as paragraphs and media, all on the same parent node, enabling the JSON encoder and all the entity normalizers to load the related entities and be served up as pieces on the API call. This gave POWDR the ability to create pages in much of the same structure that they’d be using on the frontend. The content admin sees a structure similar to the frontend and their API calls. POWDR is building pages on the backend in much the same way that they’re coming out on the frontend. This saves a lot of these extra extraneous API calls.

One of the great things about Drupal 8 is that it is built on Symfony, and incorporates a lot of modern PHP concepts, which helped our development of this custom API move quickly. Using Drupal 6/7, we would have to build from the ground up then figure out how the API was going to call itself. Instead, we just extended the class, extended a few other classes and, in a matter of days, had at least a working model for the design team to work from.

Overall, development was much faster for this project. Since everything was an entity point the back end API could load taxonomies, media, paragraphs in the same way and they also looked the same. This meant the design team could be presented something that is agnostic to the backend functionality but still utilizes Drupal’s media power.

To Be Continued...

In the next post of this series our hosting Partner, Acquia will cover the ins and outs of the POWDR project’s frontend design. Stay tuned!

I had this blog post written last week but didn’t publish because it felt wrong. It wasn’t until earlier today, when I was listening to one of my favorite public speakers, that I realized it was because I was talking at you, not to you. In truth, whenever I’ve discussed this document I keep talking about the what its purpose is and how it could bring value to our Drupal community but not why you should care.

Pages