Development News

Evolving Web: What's Next for Drupal 9?

Main Drupal Feed - Mon, 06/22/2020 - 14:01

Drupal 9.0 was launched earlier this month as a continuation of Drupal 8. This time around, the core update was more about updating the technology underlying Drupal's codebase and eliminating dependencies than introducing brand-new features, but fear not: we'll be getting some of those soon enough.

Drupal releases features on a semi-annual basis, and version 9.1 is expected to be rolled out around December this year. Due to the decentralized nature of Drupal's development, the roadmap for 9.1 isn't necessarily set in stone; that said, the strategic initiatives and core objectives are well-documented, so we know what we can expect in the foreseeable future. Most importantly, gone are the days when Drupal was developer-first, editor-second: it's all about usability and accessibility for everyone moving forward.

Let's take a closer look at what that might entail. On the menu: a new front-end theme, automatic updates, and community-driven improvements collected from the 2020 Drupal Product Survey.

Olivero Front-End Theme

When I built my first-ever Drupal site during an Evolving Web training session, I remember thinking two things: "Wow, this is really flexible and fun to use once you get the hang of it", and "Wow, the default theme looks a bit dated". I'm a fan of Drupal, but the Bartik theme and its decade-old design just don't quite do it justice for first-time users.

Drupal has made it a major priority to completely overhaul its user experience and be friendlier for everyone, not just developers. Now that Claro, a new, accessible admin theme, is available in Drupal 9, contributors are focusing on Olivero, a modern front-end theme designed to showcase the CMS in its best light out of the box. Like Claro, Olivero follows a new-and-improved design system that prioritizes user experience and accessibility.

Screenshot of the Olivero front-end theme for Drupal sites

It'll be a good few months before we can officially say bye-bye to Bartik, so here's what we know about Olivero so far to tide you over in the meantime:

  • It looks really good. Olivero's sharp colour palette, modern typography, and judicious use of white space gives Drupal sites a polished, state-of-the art look straight out of the box.
  • It'll be WCAG AA-compliant from the ground up. Accessibility is a major focus in Olivero, which is slated to include a high-contrast mode among myriad other accessibility-first features and functionality.
  • It supports all the most recent features added to Drupal, including embedded media and the drag-and-drop layout builder.

To read more about Olivero's development (and see the prototype high-contrast mode in action), check out this blog post by Lullabot, one of the teams involved in building the theme. According to the post's author, a launch within 9.1 is the most likely release scenario, so stay tuned this December.

Automatic Updates

As it stands, updating a Drupal site isn't the most straightforward process. That's set to change in the foreseeable future, however, as automatic updates have been one of Drupal's main strategic initiatives for some time now.

Major features of the existing Automatic Updates module, which is planned to eventually become part of Drupal core, include:

  • Major update announcements to notify admins when a core update is on its way, what it entails, and how to prepare
  • Update readiness checks to automate the process of ensuring sites are compatible with the latest update
  • One-click updating to allow admins to trigger the database update directly via the Automatic Updates service

These features are currently being tested and refined by the community, and we can expect a core release as soon as they're ready. Get all the details about the Automatic Updates project in the Drupal docs.

The 2020 Drupal Product Survey

Drupal's project lead Dries Buytaert recently started collecting responses to the annual Drupal Product Survey (here's the related post on Dries' blog). The survey's goal is to prioritize upcoming initiatives according to the community's needs. The results will be unveiled this July during the global virtual DrupalCon.

Looking at the survey's contents can give us some clues as to what might be coming to Drupal in the mid- to long-term (but we'll have to wait till the results are out to get a clear picture of how the Survey will influence Drupal's strategic direction).

Target Audiences

When you take the survey, the first questions are about how you use Drupal. The rest of the survey is then tailored according to your response. Here's a glimpse of the different demographics you can choose from to give you an idea of who the questionnaire is intended for (short answer: anyone who has anything to do with Drupal in any capacity!).

The first question on the Drupal Product Survey shows the scope of its audience

Content Editor Experience

The content editing experience in Drupal has seen constant improvements over the last several releases, but how will it evolve in 9.1 and beyond? The survey's questions for content creators include a list of potential Drupal enhancements, which respondents are asked to prioritize. A few highlights:

  • More refined draft/publishing control. This has already been addressed in recent updates; Drupal 9 includes enhanced content moderation workflows that are well-suited to actual editorial processes. It'll be interesting to see how this will be improved upon even further.)
  • Improved accessibility testing and control. Drupal core aims to adhere to stringent accessibility requirements out of the box (note leigh link here to that one page), but it could definitely offer even more testing features for creators directly via the admin UI
  • Improved contextual help and overall "how-to" guidance and Redesigned information architecture/simplified terminology for admin pages. A lot has been done in recent updates to make Drupal more user-friendly and approachable, so this survey question should be a good indicator of how successful those efforts have been--and what still needs to be done to further democratize the CMS.

Other noteworthy points relating to content creation workflows include:

  • Making more pre-built templates available
  • Autosaving
  • Real-time previewing of content being edited
  • Improvements to structured data and metadata management
Developer Experience

Site builders, theme builders, designers, and front- and back-end developers answering the survey also get questions about usability and accessibility, but those obviously look a bit different than the ones targeting content authors.

Discussion points aimed at developers and designers include these potential Drupal enhancements:

  • Improved configuration management
  • Additional front-end development tools, like NPM support and SDKs for common JavaScript frameworks
  • Drush-style out-of-the-box command-line tools integrated into Drupal Core (if you're currently looking for Drush commands to use during deployment, consider getting the Drush module, which adds several admin functionalities)
  • Improved data modeling tools
  • Better support for atomic content (i.e. reusable, channel-agnostic assets), in addition to a component-based theme system with reusable interactive theme elements like responsive tables
  • More modules added to Drupal Core, such as Feeds (to provide a migration UI), Rules (to provide a business logic UI), Admin toolbar, and Pathauto (for generating URL path aliases)
  • Privacy management support, such as user-managed identity access for GDPR
Help Shape Future Versions of Drupal

Of course, this is just the tip of the iceberg when it comes to future plans for Drupal. If you have an opinion on anything we just covered (or on Drupal in general), make sure to take the 2020 product survey (direct survey link) to have your voice heard. Drupal is, and always has been, a community effort, so by taking the time to fill out the questionnaire you'll be directly contributing to the future of a powerful open-source CMS that powers millions of experiences across the web.

Meanwhile, if you want the facts about the latest current edition of Drupal, sign up for our upcoming webinar What You Need to Know About Drupal 9.

+ more awesome articles by Evolving Web

Tag1 Consulting: Introduction to DrupalSpoons, a new developer workflow for Drupal contributors

Main Drupal Feed - Mon, 06/22/2020 - 12:16

In this exciting episode of Tag1 Team Talks, Moshe Weitzman (Subject Matter Expert, Senior Architect, and Project Lead at Tag1) hopped on with Michael Meyers (Managing Director at Tag1) and your host Preston So (Editor in Chief at Tag1 and author of Decoupled Drupal in Practice) for a deep dive into what makes DrupalSpoons so compelling for Drupal contributors and the origin story that inspired Moshe to build it.

Read more preston Mon, 06/22/2020 - 05:16

Tag1 Consulting: Introduction to DrupalSpoons, a new developer workflow for Drupal contributors

Main Drupal Feed - Mon, 06/22/2020 - 12:16

In this exciting episode of Tag1 Team Talks, Moshe Weitzman (Subject Matter Expert, Senior Architect, and Project Lead at Tag1) hopped on with Michael Meyers (Managing Director at Tag1) and your host Preston So (Editor in Chief at Tag1 and author of Decoupled Drupal in Practice) for a deep dive into what makes DrupalSpoons so compelling for Drupal contributors and the origin story that inspired Moshe to build it.

Read more preston Mon, 06/22/2020 - 05:16

Tag1 Consulting: Introduction to DrupalSpoons, a new developer workflow for Drupal contributors

Main Drupal Feed - Mon, 06/22/2020 - 12:16

In this exciting episode of Tag1 Team Talks, Moshe Weitzman (Subject Matter Expert, Senior Architect, and Project Lead at Tag1) hopped on with Michael Meyers (Managing Director at Tag1) and your host Preston So (Editor in Chief at Tag1 and author of Decoupled Drupal in Practice) for a deep dive into what makes DrupalSpoons so compelling for Drupal contributors and the origin story that inspired Moshe to build it.

Read more preston Mon, 06/22/2020 - 05:16

Tag1 Consulting: Introduction to DrupalSpoons, a new developer workflow for Drupal contributors

Main Drupal Feed - Mon, 06/22/2020 - 12:16

In this exciting episode of Tag1 Team Talks, Moshe Weitzman (Subject Matter Expert, Senior Architect, and Project Lead at Tag1) hopped on with Michael Meyers (Managing Director at Tag1) and your host Preston So (Editor in Chief at Tag1 and author of Decoupled Drupal in Practice) for a deep dive into what makes DrupalSpoons so compelling for Drupal contributors and the origin story that inspired Moshe to build it.

Read more preston Mon, 06/22/2020 - 05:16

Tag1 Consulting: Introduction to DrupalSpoons, a new developer workflow for Drupal contributors

Main Drupal Feed - Mon, 06/22/2020 - 12:16

In this exciting episode of Tag1 Team Talks, Moshe Weitzman (Subject Matter Expert, Senior Architect, and Project Lead at Tag1) hopped on with Michael Meyers (Managing Director at Tag1) and your host Preston So (Editor in Chief at Tag1 and author of Decoupled Drupal in Practice) for a deep dive into what makes DrupalSpoons so compelling for Drupal contributors and the origin story that inspired Moshe to build it.

Read more preston Mon, 06/22/2020 - 05:16

Flocon de toile | Freelance Drupal: Customizing a CSV export with Entity Export CSV on Drupal 8

Main Drupal Feed - Mon, 06/22/2020 - 09:49
The Entity Export CSV module allows us to quickly set up CSV exports for any type of Drupal 8 content entity. Sometimes, we may need to customize the exports we perform, such as exporting 2 different pieces of information from the same Entity Reference field for example. Let's find out how to customize our CSV exports.

Flocon de toile | Freelance Drupal: Customizing a CSV export with Entity Export CSV on Drupal 8

Main Drupal Feed - Mon, 06/22/2020 - 09:49
The Entity Export CSV module allows us to quickly set up CSV exports for any type of Drupal 8 content entity. Sometimes, we may need to customize the exports we perform, such as exporting 2 different pieces of information from the same Entity Reference field for example. Let's find out how to customize our CSV exports.

Flocon de toile | Freelance Drupal: Customizing a CSV export with Entity Export CSV on Drupal 8

Main Drupal Feed - Mon, 06/22/2020 - 09:49
The Entity Export CSV module allows us to quickly set up CSV exports for any type of Drupal 8 content entity. Sometimes, we may need to customize the exports we perform, such as exporting 2 different pieces of information from the same Entity Reference field for example. Let's find out how to customize our CSV exports.

Flocon de toile | Freelance Drupal: Customizing a CSV export with Entity Export CSV on Drupal 8

Main Drupal Feed - Mon, 06/22/2020 - 09:49
The Entity Export CSV module allows us to quickly set up CSV exports for any type of Drupal 8 content entity. Sometimes, we may need to customize the exports we perform, such as exporting 2 different pieces of information from the same Entity Reference field for example. Let's find out how to customize our CSV exports.

Flocon de toile | Freelance Drupal: Customizing a CSV export with Entity Export CSV on Drupal 8

Main Drupal Feed - Mon, 06/22/2020 - 09:49
The Entity Export CSV module allows us to quickly set up CSV exports for any type of Drupal 8 content entity. Sometimes, we may need to customize the exports we perform, such as exporting 2 different pieces of information from the same Entity Reference field for example. Let's find out how to customize our CSV exports.

CTI Digital: Drupal 7 End of Life: What's next for your website?

Main Drupal Feed - Mon, 06/22/2020 - 08:22

It’s nearly a decade since the release of Drupal 7. During this time, we have seen new legislation in web accessibility, privacy (GDPR), the rise of mobile internet, and the proliferation of high-performance devices. 

CTI Digital: Drupal 7 End of Life: What's next for your website?

Main Drupal Feed - Mon, 06/22/2020 - 08:22

It’s nearly a decade since the release of Drupal 7. During this time, we have seen new legislation in web accessibility, privacy (GDPR), the rise of mobile internet, and the proliferation of high-performance devices. 

CTI Digital: Drupal 7 End of Life: What's next for your website?

Main Drupal Feed - Mon, 06/22/2020 - 08:22

It’s nearly a decade since the release of Drupal 7. During this time, we have seen new legislation in web accessibility, privacy (GDPR), the rise of mobile internet, and the proliferation of high-performance devices. 

CTI Digital: Drupal 7 End of Life: What's next for your website?

Main Drupal Feed - Mon, 06/22/2020 - 08:22

It’s nearly a decade since the release of Drupal 7. During this time, we have seen new legislation in web accessibility, privacy (GDPR), the rise of mobile internet, and the proliferation of high-performance devices. 

CTI Digital: Drupal 7 End of Life: What's next for your website?

Main Drupal Feed - Mon, 06/22/2020 - 08:22

It’s nearly a decade since the release of Drupal 7. During this time, we have seen new legislation in web accessibility, privacy (GDPR), the rise of mobile internet, and the proliferation of high-performance devices. 

imalabya.co: Setting up Default Contents for Drupal installation profile

Main Drupal Feed - Sun, 06/21/2020 - 09:36
Setting up Default Contents for Drupal installation profile

While building an installation profile or a distribution using Drupal it's likely to set up the contents every time there is a new build. This becomes a chore when the number of available functionalities or listing increases. It becomes difficult to test the different listings without a proper number of contents.

Default content provides a way to include default contents for the required entities in JSON format and added as a dependency to the profile setup. This will import the minimum required set of contents available for testing and demo upon installation.

Using the Default content module

The Default Content module doesn't do anything on its own. It needs a custom module to be in the module which has the entity JSON exports to import. Now, when I say entities any type of entities can be imported; files included. However, for files, we need to do some manual work. The project page however mentions that it supports Files import using the File entity module, but I couldn't make it work but used a workaround.

Pre-Requisites & Setup

The post assumes you have the Default Content modulus & Drush CLI is installed. 

Create a new module demo_default_content in your profile and add the default_content module as a dependency. HAL & Serialization can also be added as a dependency but since it's added a dependency in default_content so it can be skipped.

name: 'Demo default content' type: module description: 'Default content export' core_version_requirement: ^8 || ^9 package: "SDNN" dependencies: - default_content:default_content Exporting contents

The exported JSON files for the entities will be placed in a directory called content inside the custom module. To export content, there 2 Drush commands available.

  1. Export a single entity drush dce
  2. Export all referenced entities for an entity drush dcer which is preferable since all the references are handles automatically. However, there are a few things to take care of while using it [mentioned below]

Provided, there is an article or number articles with the fields like term reference, media & author; running the following Drush command will export all the articles node and the referencing entities for it.

drush dcer node --folder=path/to/demo_default_content/content

This will create a folder structure like the following

content/ ├── file │ └── 136733d4-def1-4d2d-ba68-9cf20a2c5094.json ├── media │ └── 116c9694-0f3a-4bcc-82f1-9302b766afd0.json ├── node │ └── c48fe37c-8660-4838-9984-017f06565e51.json ├── taxonomy_term │ ├── ea674d7c-e086-40e5-9956-41c0cf6746b2.json │ └── ff343e13-0136-4ca7-aa7a-6b6596ebf844.json └── user ├── cc247ecf-6435-4a23-9552-1b4d49489efe.json └── cc247ecf-6435-4a23-9552-1b4d49489efe.json Fixing the exported contents
  1. Remove any JSON file which exports the user with ID 1 if the module is being installed separately and not added as a dependency to the profile. Search for an entry "uid": [ { "value": 1 } ] in the JSON exports under the user directory. If the file contains the user ID 1 then remove the file.

  2. Now, files JSON export will have the references to the file path in the public:// directory. But in a fresh install, since the files will not be present the images will appear to be broken.

To handle the broken image, create a folder called "assets" (name is arbitrary). Place the upload files in the "assets" folder like images in Media and user Picture. It's recommended to place the files in separate folders for each entity type.

Now, since the image files are not present in the public:// directory, copy the files from the modules assets directory to the public:// directory when the module will be installed using hook_install()

$fs = \Drupal::service('file_system'); // Copy the media assets. $media_path = 'public://media/'; $fs->prepareDirectory($media_path, FileSystemInterface::CREATE_DIRECTORY); $media = $fs->scanDirectory(drupal_get_path('module', 'demo_default_content') . '/assets/media', '/\.(jpg|png|jpeg)$/'); foreach ($media as $source) { $fs->copy($source->uri, $media_path . $source->filename); } // Copy the user pictures. $picture_path = 'public://picture/'; $fs->prepareDirectory($picture_path, FileSystemInterface::CREATE_DIRECTORY); $picture = $fs->scanDirectory(drupal_get_path('module', 'demo_default_content') . '/assets/picture', '/\.(jpg|png|jpeg)$/'); foreach ($picture as $source) {   $fs->copy($source->uri, $picture_path . $source->filename); }

This will ensure that the files are present when the default entities are exported.

Conclusion

So, the Default content is a great tool to quickly setup a default set of contents while working on an installation profile. This is really helpful during doing a manual QA, running Behat test or when we need to demo the functionalities of the profile. Although, there are other ways to create default contents using which Umami demo profile is using, but the Default content module make exporting and importing contents pretty easy to use.

malabya Sun, 06/21/2020 - 15:06 Drupal developmentSite buildingCI/CD & Automation

imalabya.co: Setting up Default Contents for Drupal installation profile

Main Drupal Feed - Sun, 06/21/2020 - 09:36
Setting up Default Contents for Drupal installation profile

While building an installation profile or a distribution using Drupal it's likely to set up the contents every time there is a new build. This becomes a chore when the number of available functionalities or listing increases. It becomes difficult to test the different listings without a proper number of contents.

Default content provides a way to include default contents for the required entities in JSON format and added as a dependency to the profile setup. This will import the minimum required set of contents available for testing and demo upon installation.

Using the Default content module

The Default Content module doesn't do anything on its own. It needs a custom module to be in the module which has the entity JSON exports to import. Now, when I say entities any type of entities can be imported; files included. However, for files, we need to do some manual work. The project page however mentions that it supports Files import using the File entity module, but I couldn't make it work but used a workaround.

Pre-Requisites & Setup

The post assumes you have the Default Content modulus & Drush CLI is installed. 

Create a new module demo_default_content in your profile and add the default_content module as a dependency. HAL & Serialization can also be added as a dependency but since it's added a dependency in default_content so it can be skipped.

name: 'Demo default content' type: module description: 'Default content export' core_version_requirement: ^8 || ^9 package: "SDNN" dependencies: - default_content:default_content Exporting contents

The exported JSON files for the entities will be placed in a directory called content inside the custom module. To export content, there 2 Drush commands available.

  1. Export a single entity drush dce
  2. Export all referenced entities for an entity drush dcer which is preferable since all the references are handles automatically. However, there are a few things to take care of while using it [mentioned below]

Provided, there is an article or number articles with the fields like term reference, media & author; running the following Drush command will export all the articles node and the referencing entities for it.

drush dcer node --folder=path/to/demo_default_content/content

This will create a folder structure like the following

content/ ├── file │ └── 136733d4-def1-4d2d-ba68-9cf20a2c5094.json ├── media │ └── 116c9694-0f3a-4bcc-82f1-9302b766afd0.json ├── node │ └── c48fe37c-8660-4838-9984-017f06565e51.json ├── taxonomy_term │ ├── ea674d7c-e086-40e5-9956-41c0cf6746b2.json │ └── ff343e13-0136-4ca7-aa7a-6b6596ebf844.json └── user ├── cc247ecf-6435-4a23-9552-1b4d49489efe.json └── cc247ecf-6435-4a23-9552-1b4d49489efe.json Fixing the exported contents
  1. Remove any JSON file which exports the user with ID 1 if the module is being installed separately and not added as a dependency to the profile. Search for an entry "uid": [ { "value": 1 } ] in the JSON exports under the user directory. If the file contains the user ID 1 then remove the file.

  2. Now, files JSON export will have the references to the file path in the public:// directory. But in a fresh install, since the files will not be present the images will appear to be broken.

To handle the broken image, create a folder called "assets" (name is arbitrary). Place the upload files in the "assets" folder like images in Media and user Picture. It's recommended to place the files in separate folders for each entity type.

Now, since the image files are not present in the public:// directory, copy the files from the modules assets directory to the public:// directory when the module will be installed using hook_install()

$fs = \Drupal::service('file_system'); // Copy the media assets. $media_path = 'public://media/'; $fs->prepareDirectory($media_path, FileSystemInterface::CREATE_DIRECTORY); $media = $fs->scanDirectory(drupal_get_path('module', 'demo_default_content') . '/assets/media', '/\.(jpg|png|jpeg)$/'); foreach ($media as $source) { $fs->copy($source->uri, $media_path . $source->filename); } // Copy the user pictures. $picture_path = 'public://picture/'; $fs->prepareDirectory($picture_path, FileSystemInterface::CREATE_DIRECTORY); $picture = $fs->scanDirectory(drupal_get_path('module', 'demo_default_content') . '/assets/picture', '/\.(jpg|png|jpeg)$/'); foreach ($picture as $source) {   $fs->copy($source->uri, $picture_path . $source->filename); }

This will ensure that the files are present when the default entities are exported.

Conclusion

So, the Default content is a great tool to quickly setup a default set of contents while working on an installation profile. This is really helpful during doing a manual QA, running Behat test or when we need to demo the functionalities of the profile. Although, there are other ways to create default contents using which Umami demo profile is using, but the Default content module make exporting and importing contents pretty easy to use.

malabya Sun, 06/21/2020 - 15:06 Drupal developmentSite buildingCI/CD & Automation

imalabya.co: Setting up Default Contents for Drupal installation profile

Main Drupal Feed - Sun, 06/21/2020 - 09:36
Setting up Default Contents for Drupal installation profile

While building an installation profile or a distribution using Drupal it's likely to set up the contents every time there is a new build. This becomes a chore when the number of available functionalities or listing increases. It becomes difficult to test the different listings without a proper number of contents.

Default content provides a way to include default contents for the required entities in JSON format and added as a dependency to the profile setup. This will import the minimum required set of contents available for testing and demo upon installation.

Using the Default content module

The Default Content module doesn't do anything on its own. It needs a custom module to be in the module which has the entity JSON exports to import. Now, when I say entities any type of entities can be imported; files included. However, for files, we need to do some manual work. The project page however mentions that it supports Files import using the File entity module, but I couldn't make it work but used a workaround.

Pre-Requisites & Setup

The post assumes you have the Default Content modulus & Drush CLI is installed. 

Create a new module demo_default_content in your profile and add the default_content module as a dependency. HAL & Serialization can also be added as a dependency but since it's added a dependency in default_content so it can be skipped.

name: 'Demo default content' type: module description: 'Default content export' core_version_requirement: ^8 || ^9 package: "SDNN" dependencies: - default_content:default_content Exporting contents

The exported JSON files for the entities will be placed in a directory called content inside the custom module. To export content, there 2 Drush commands available.

  1. Export a single entity drush dce
  2. Export all referenced entities for an entity drush dcer which is preferable since all the references are handles automatically. However, there are a few things to take care of while using it [mentioned below]

Provided, there is an article or number articles with the fields like term reference, media & author; running the following Drush command will export all the articles node and the referencing entities for it.

drush dcer node --folder=path/to/demo_default_content/content

This will create a folder structure like the following

content/ ├── file │ └── 136733d4-def1-4d2d-ba68-9cf20a2c5094.json ├── media │ └── 116c9694-0f3a-4bcc-82f1-9302b766afd0.json ├── node │ └── c48fe37c-8660-4838-9984-017f06565e51.json ├── taxonomy_term │ ├── ea674d7c-e086-40e5-9956-41c0cf6746b2.json │ └── ff343e13-0136-4ca7-aa7a-6b6596ebf844.json └── user ├── cc247ecf-6435-4a23-9552-1b4d49489efe.json └── cc247ecf-6435-4a23-9552-1b4d49489efe.json Fixing the exported contents
  1. Remove any JSON file which exports the user with ID 1 if the module is being installed separately and not added as a dependency to the profile. Search for an entry "uid": [ { "value": 1 } ] in the JSON exports under the user directory. If the file contains the user ID 1 then remove the file.

  2. Now, files JSON export will have the references to the file path in the public:// directory. But in a fresh install, since the files will not be present the images will appear to be broken.

To handle the broken image, create a folder called "assets" (name is arbitrary). Place the upload files in the "assets" folder like images in Media and user Picture. It's recommended to place the files in separate folders for each entity type.

Now, since the image files are not present in the public:// directory, copy the files from the modules assets directory to the public:// directory when the module will be installed using hook_install()

$fs = \Drupal::service('file_system'); // Copy the media assets. $media_path = 'public://media/'; $fs->prepareDirectory($media_path, FileSystemInterface::CREATE_DIRECTORY); $media = $fs->scanDirectory(drupal_get_path('module', 'demo_default_content') . '/assets/media', '/\.(jpg|png|jpeg)$/'); foreach ($media as $source) { $fs->copy($source->uri, $media_path . $source->filename); } // Copy the user pictures. $picture_path = 'public://picture/'; $fs->prepareDirectory($picture_path, FileSystemInterface::CREATE_DIRECTORY); $picture = $fs->scanDirectory(drupal_get_path('module', 'demo_default_content') . '/assets/picture', '/\.(jpg|png|jpeg)$/'); foreach ($picture as $source) {   $fs->copy($source->uri, $picture_path . $source->filename); }

This will ensure that the files are present when the default entities are exported.

Conclusion

So, the Default content is a great tool to quickly setup a default set of contents while working on an installation profile. This is really helpful during doing a manual QA, running Behat test or when we need to demo the functionalities of the profile. Although, there are other ways to create default contents using which Umami demo profile is using, but the Default content module make exporting and importing contents pretty easy to use.

malabya Sun, 06/21/2020 - 15:06 Drupal developmentSite buildingCI/CD & Automation

imalabya.co: Setting up Default Contents for Drupal installation profile

Main Drupal Feed - Sun, 06/21/2020 - 09:36
Setting up Default Contents for Drupal installation profile

While building an installation profile or a distribution using Drupal it's likely to set up the contents every time there is a new build. This becomes a chore when the number of available functionalities or listing increases. It becomes difficult to test the different listings without a proper number of contents.

Default content provides a way to include default contents for the required entities in JSON format and added as a dependency to the profile setup. This will import the minimum required set of contents available for testing and demo upon installation.

Using the Default content module

The Default Content module doesn't do anything on its own. It needs a custom module to be in the module which has the entity JSON exports to import. Now, when I say entities any type of entities can be imported; files included. However, for files, we need to do some manual work. The project page however mentions that it supports Files import using the File entity module, but I couldn't make it work but used a workaround.

Pre-Requisites & Setup

The post assumes you have the Default Content modulus & Drush CLI is installed. 

Create a new module demo_default_content in your profile and add the default_content module as a dependency. HAL & Serialization can also be added as a dependency but since it's added a dependency in default_content so it can be skipped.

name: 'Demo default content' type: module description: 'Default content export' core_version_requirement: ^8 || ^9 package: "SDNN" dependencies: - default_content:default_content Exporting contents

The exported JSON files for the entities will be placed in a directory called content inside the custom module. To export content, there 2 Drush commands available.

  1. Export a single entity drush dce
  2. Export all referenced entities for an entity drush dcer which is preferable since all the references are handles automatically. However, there are a few things to take care of while using it [mentioned below]

Provided, there is an article or number articles with the fields like term reference, media & author; running the following Drush command will export all the articles node and the referencing entities for it.

drush dcer node --folder=path/to/demo_default_content/content

This will create a folder structure like the following

content/ ├── file │ └── 136733d4-def1-4d2d-ba68-9cf20a2c5094.json ├── media │ └── 116c9694-0f3a-4bcc-82f1-9302b766afd0.json ├── node │ └── c48fe37c-8660-4838-9984-017f06565e51.json ├── taxonomy_term │ ├── ea674d7c-e086-40e5-9956-41c0cf6746b2.json │ └── ff343e13-0136-4ca7-aa7a-6b6596ebf844.json └── user ├── cc247ecf-6435-4a23-9552-1b4d49489efe.json └── cc247ecf-6435-4a23-9552-1b4d49489efe.json Fixing the exported contents
  1. Remove any JSON file which exports the user with ID 1 if the module is being installed separately and not added as a dependency to the profile. Search for an entry "uid": [ { "value": 1 } ] in the JSON exports under the user directory. If the file contains the user ID 1 then remove the file.

  2. Now, files JSON export will have the references to the file path in the public:// directory. But in a fresh install, since the files will not be present the images will appear to be broken.

To handle the broken image, create a folder called "assets" (name is arbitrary). Place the upload files in the "assets" folder like images in Media and user Picture. It's recommended to place the files in separate folders for each entity type.

Now, since the image files are not present in the public:// directory, copy the files from the modules assets directory to the public:// directory when the module will be installed using hook_install()

$fs = \Drupal::service('file_system'); // Copy the media assets. $media_path = 'public://media/'; $fs->prepareDirectory($media_path, FileSystemInterface::CREATE_DIRECTORY); $media = $fs->scanDirectory(drupal_get_path('module', 'demo_default_content') . '/assets/media', '/\.(jpg|png|jpeg)$/'); foreach ($media as $source) { $fs->copy($source->uri, $media_path . $source->filename); } // Copy the user pictures. $picture_path = 'public://picture/'; $fs->prepareDirectory($picture_path, FileSystemInterface::CREATE_DIRECTORY); $picture = $fs->scanDirectory(drupal_get_path('module', 'demo_default_content') . '/assets/picture', '/\.(jpg|png|jpeg)$/'); foreach ($picture as $source) {   $fs->copy($source->uri, $picture_path . $source->filename); }

This will ensure that the files are present when the default entities are exported.

Conclusion

So, the Default content is a great tool to quickly setup a default set of contents while working on an installation profile. This is really helpful during doing a manual QA, running Behat test or when we need to demo the functionalities of the profile. Although, there are other ways to create default contents using which Umami demo profile is using, but the Default content module make exporting and importing contents pretty easy to use.

malabya Sun, 06/21/2020 - 15:06 Drupal developmentSite buildingCI/CD & Automation

Pages