March 21, 2017
Listen:
Topics:
In episode #140 We walk about using composer.
- What is composer
- When to use composer
- What about drush?
- Composer and hosting providers
- Getting started
Module of the Week:
The Group module allows you to create arbitrary collections of your content and users on your site and grant access control permissions on those collections
Out of the box, Drupal only allows a person to view, create or edit the different content types you create. However, you might want to be able to let them view or edit all content types, but only in a specific section of the site.
Group also allows you to create communities. Users of the site can become members of a Group. You can then decide what membership of a Group entitles them to, such as access to content only available to members of that Group. There can also be different levels of membership to a Group so, for example, you can have administrative members who can create content and basic members who can only view content within the Group.
Sponsors
nLightened Design
nLightened Design specializes in designing, developing and fulfilling your web marketing needs.
Oomph, Inc.
Crafting digital experiences with passion & purpose. We connect you and your audience in a more meaningful way by leveraging the open source power of Drupal and WordPress.
Parallax Information Technology
Parallax Information Technology is a web development agency providing services since 1996 to small and and Fortune 100 companies.
Comments
Frederick Henderson replied on Permalink
Hi Guys!
I listen to all your podcasts. Keep up the great work.
I do have a question related to using composer. I am managing my Drupal 8 sites with composer and I am wondering what the best practice is for managing non-PHP libraries. I believe John Picozzi mentioned in this podcast that Composer will manage just your PHP dependencies. What about CSS, JS, or JQuery dependencies? What is the best practice for this?
A classic example is the Drupal 8 Webform module. It has 11 dependencies that fall in the non-PHP categories. It has a composer.json but it lists none of these 11 dependencies in it.
The Webform module has a drush command that will generate a composer.json file with the dependencies. It is suggested to copy the repository and required sections into your Drupal 8 project's composer.json. This is messy but works. I have to wonder what happens when it is time to upgrade webform and the versions of some of the 11 dependencies change. I am guessing this means mucking around again in my composer.json again.
Part of the problem is that repositories have to be in a project's main composer.json file. This is something that the composer developers have agreed on for security reasons. It is documented (https://getcomposer.org/doc/04-schema.md#repositories) and the reasons why are also in the documentation (https://getcomposer.org/doc/faqs/why-can%27t-composer-load-repositories-...). This makes it impossible for module developers to add repositories to the module's composer.json file.
I have seen this composer plugin called wikimedia/composer-merge-plugin (https://github.com/wikimedia/composer-merge-plugin) that allows you to combine composer.json files at run time. Using something like this it should be possible to use drush commands like the one provided by webform to generate a new composer.webform.json each time that can then be merged into the main composer.json of a Drupal 8 project.
Maybe this Drush command should be something that is in Drush itself that each module could then use to have their composer.json for their dependencies generated.
Is using composer to download libraries other than php abusing the custom VCS & package repositories?
This functionality was created to temporarily try some things, or use a fork of a project until your pull request gets merged.
I have to wonder if there is a better way. I would be interested to hear what you and any experts that you might bring on the the show would have to say about this.
Thanks again for all your time, effort, learning and laughter that you put into the Talking Drupal podcast!
Frederick Henderson
Nic replied on Permalink
Thanks for the question! I need to research this a bit before responding I have not used webform in Drupal 8 yet.
Thanks for listening!
Nic replied on Permalink
Good afternoon Frederick, I've had a chance to review this a bit more after installing Webform. I don't have a definitive answer for you here, but I have a few observations.
First it looks like Webform has evolved quite a bit between 7 and 8. There are a lot more configuration options.
I'm sure you are aware, but you don't need to download those libraries as they get loaded from CDN if you don't download them. Personally I'd rather not do that myself with this many libraries. I think the route that makes most sense is the wikimedia merge plugin, it seems pretty anagolous to the patches process that is provided here: https://github.com/cweagans/composer-patches If your aim is to not edit the file directly and to use the command line you will run into the same nesting limit that exists for generating composer.json files from the command line in both cases. However, this route seems to be the direction drupal is going. For some projects I would also just consider running the two drush commands and committing the libraries directly, then anytime the webform module updates running that again.
Add new comment