COVID-19 and recognizing racism as a public health threat spotlights the importance of health communities of practice and their need to have high-quality, data-driven discussions. How do we do data-informed conversations well?  How do we expand them to include more health professionals and more community members outside what is recognized as the healthcare industry?  Both are very clearly needed now.

Thanks to a client giving us a shout out, Agaric realized recently we've done a lot of health communities over the years and would love to talk and learn with others.  We're hosting a "Birds of a Feather" (people interested in the same topic coming together) at DrupalCon Global today at 3:15 Eastern Time to talk about facilitating discussion among healthcare practitioners and researchers and the public, and anything along community or data-sharing lines. 

Environmental racism was forced into the national conversation by Flint, Michigan years ago and COVID-19 has made long-standing problems of racism in healthcare provision impossible to ignore.  The rebellion against police repression started in Minneapolis is itself a reaction to the public health issues caused by policing which were predictable, and Minneapolis resident D.A. Bullock, indeed, predicted it.

What's the next steps for healthcare workers and researchers?  For any person who cares about our communities?  How do we move conversations within health communities and with outside communities forward, and never fall back to not caring?  The stakes for both well-informed and broad-based discussion are clearer than ever.  We know pressure, policy, and practice are what make change; what is our role?

Please leave your comments even if you can't join us today!

Read more and discuss at agaric.coop.

Acro Media is proud to be a part of Google Summer of Code 2020 for the first time in it’s 15 year history. 

What is Google Summer of Code (GSoC)?

“Google Summer of Code is a global program focused on introducing students to open source software development. Students work on a 3 month programming project with an open source organization during their break from university.” - About | Google Summer of Code

Why is Acro Media involved in GSoC?

Introducing students to open source software development and helping drive open source coding forward are key mandates of GSoC, which is something Acro Media can definitely get behind. 

Improved coding and talented new developers are only going to make the Open Source Community stronger.

Student developers like Vishal Chaudary gain valuable mentorship and insight through a 3-month internship. 

Vishal was chosen to take part in GSoC as a student developer working on the Drupal Commerce Fraud Project. The project aims to port the Commerce fraud module to Drupal 8/9 with candidate level release. This includes updating the current module with adding new features compatible with latest versions of Drupal. 

Vishal has been sharing his intern experience through a series of blog posts highlighting the things he has learned along the way. 

Here is a quick look at some of his highlights:

• Week 1: 
  • Debugging and fixing for porting of Drupal 8 version
• Week 2:
  • Added test for the feature to show cities previously having fraudulent orders
• Week 3:
  • Added improvement in Features of the module
• Week 4:
  • Addition of Reset fraud score functionality
• Week 5:
  • Converting Rules entity form content type to config
• Week 6:
  • Improving documentation for the module version 7.x and 8.x

Read more about Vishal’s GSoC journey here

Transforming a Brand Into an Ecosystem Type E-book Firas Ghunaim Thu, 07/16/2020 - 16:29

 

Enterprise-level businesses have very unique technical requirements that can prove to be complex due to the nature of their digital transformation requirements. For example:

  Multilingual Digital Experiences

These businesses often need to communicate with a diverse global audience - needing to publish content and reach out with marketing messages personalized to each audience segment's language. Hence, the need to build a multilingual website.

Using the ideal technology to build your digital experiences you can enable your marketing team to create multilingual websites from the same Drupal CMS. Each language can be quickly translated and optimized for SEO at the same time.

 

Multisite

Major enterprises have numerous domains or microsites dedicated to a particular audience or product. With Drupal you no longer need to spend extra to scale and grow your digital presence as the need arises. All those sites can be an interconnected web with seamless integrations from the same centralized CMS - sharing all best practices, security and UX features.

This is but the tip of iceberg when it come to building an engaging and open digital experience for an enterprise-grade business in today's digital world.

To gain more insight towards what it takes to transform such a project - you can download our ebook by filling out the form.

Form Form title Download Now Solutions by industry Media and Entertainment Financial Services Healthcare High Tech Travel and Tourism Retail Higher Education Government Nonprofits and NGOs Solutions by need Enterprise CMS Drupal Managed Services E-Commerce Knowledge Management On-Site SEO Omnichannel Marketing Automation Social Business Community Related services Support and Maintenance Web Development Drupal Migration and Upgrades DevOps and Engineering Digital Marketing UI/UX Design Digital Strategy Product Open Social Marketing Automation Uber Publisher Varbase Vardoc

In early June, the long awaited version 9 of the Drupal CMS was released. Logically, this gave rise to a number of blog posts about the ease of migrating to 9 and what this release means for the open-source project. Revisit some of these in our overview for June!

READ MORE

A short video showing how to use the newly released Component Blocks module.

by lee.rowlands / 16 July 2020

Component blocks module lets you integrate your existing Pattern library / UI Patterns functionality with Layout Builder.

Tagged Style Guides, Front End Development

The previous article of this series provided an overview of setting up a GitHub Actions workflow that would publish changes into a Kubernetes cluster. This article takes you through each of the steps of such a workflow.

We are targeting to release Drupal 10 around June 2022. That is less than two years from today!

Why so fast, you ask?

Drupal 9's biggest dependency is Symfony 4, which has an end-of-life date in November 2023. This means that after November 2023, security bugs in Symfony 4 will not get fixed. Drupal has to adopt Symfony 5 (or later) and end-of-life Drupal 9 no later than November 2023.

For security purposes, all Drupal 9 users will need to upgrade to Drupal 10 by November 2023. We like to give site owners at least one year to upgrade from Drupal 9 to Drupal 10, therefore we are targeting Drupal 10 to be released in June 2022.

Will the upgrade to Drupal 10 be easy?

Yes, it will be easy, and here is why.

New functionality for Drupal 10 is actually added to Drupal 9 releases. This means module developers can start adopting any new APIs right away. Along the way, we deprecate old functionality but keep backwards compatibility. Once we are ready to release Drupal 10, we remove all deprecated code. Removing deprecated code breaks backwards compatibility, but because module developers had a chance to stay up to date with API changes, the upgrade to Drupal 10 should be easy.

If that makes your head spin, think of it this way: Drupal 10 is identical to the last version of Drupal 9, with its deprecations removed. Because of that, there should be no last-minute, big or unexpected changes.

We used this approach for Drupal 9, and it was successful: 95 of the top 100 contributed modules were ready the day Drupal 9.0.0 was released. We know from Drupal 9 that this approach to upgrades works, and we'll continue to refine it going forward.

In the previous article we provided a reference of available configuration options for migrate source plugins. In today’s article we are doing something similar for destination plugins. We will present a reference of available configuration options for migrate destination plugins provided by Drupal core and some contributed modules. Knowing which options are available might require some Drupal development knowledge. By providing this reference it should make the process of writing migrations easier.

For each migrate destination plugin we will present: the module that provides it, the class that defines it, the class that the plugin extends, and any inherited options from the class hierarchy. For each plugin configuration option we will list its name, type, a description, and a note if it is optional.

DestinationBase (abstract class)

Module: Migrate (Drupal Core)
Class: Drupal\migrate\Plugin\migrate\destination\DestinationBase
Extends: Drupal\Core\Plugin\PluginBase

This abstract class is extended by many migrate destination plugins. This means that the provided configuration keys apply to any destination plugin extending it.

List of configuration keys:

1. destination_module: An optional string value. Identifies the module handling the destination data. If not set, the Migrate API tries to read the value from the destination plugin definition.

Entity (abstract class)

Module: Migrate (Drupal Core) Plugin ID: entity:$entity_type See below.
Class: Drupal\migrate\Plugin\migrate\destination\Entity
Extends: Drupal\migrate\Plugin\migrate\destination\DestinationBase
Inherited configuration options: destination_module.
Related article: Drupal migrations reference: List of properties per content entity

This abstract class is extended by migrate destination plugins that want to import entities. It uses the MigrateEntity derivative to handle both content and configuration entities. The derivative sets the plugin ID to entity:$entity_type where $entity_type is the machine name of the entity. For example, entity:node and entity:node_type.

By default, content entities are handled by the EntityContentBase class while configuration entities use EntityConfigBase. Some entities like user (content) and node type (configuration) use specific classes for the import operation. The DefaultPluginManager::getDefinitions method triggers the search for classes that will override the default for a particular plugin ID. The override ultimately happens in the DerivativeDiscoveryDecorator::getDerivatives method.

In addition to the keys provided in the parent class chain, this abstract class provides the following configuration keys, which will be available to its derivatives:

1. default_bundle: An optional string value. Gets the bundle for the row taking into account the default. If not present, the bundle entity key should be set in the process section for entities that can have more than one bundle. For example, the type property for nodes, the vid property for taxonomy terms, and the bundle property for media entities.

EntityContentBase

Module: Migrate (Drupal Core) Plugin ID: entity:$entity_type See below.
Class: Drupal\migrate\Plugin\migrate\destination\EntityContentBase
Extends: Drupal\migrate\Plugin\migrate\destination\Entity
Inherited configuration options: destination_module and default_bundle.

This class is used to handle import operations for all content entities, unless a specific class exists for the plugin ID being used. For example, nodes are handled by this class, but users leverage the EntityUser class. The MigrateEntity derivative sets the plugin ID to entity:$entity_type where $entity_type is the machine name of the content entity. For example, entity:node, entity:user, entity:taxonomy_term, entity:file, entity:media, entity:comment, entity:block_content, and entity:contact_message.

In addition to the keys provided in the parent class chain, this class provides the following configuration keys:

1. translations: An optional boolean value. It indicates if the entity is translatable, defaults to FALSE. If set to TRUE, the corresponding langcode entity key will be added to the list of destination IDs that uniquely identifies each record. If the migration itself does not provide a value for the langcode property, the site’s default language is used.
2. overwrite_properties: An optional array of string values. It is a list of properties or fields in the destination entity that will be overwritten if an entity with the same ID already exists. Any properties that are not listed will not be overwritten. Refer to the class documentation for an example.
3. validate: An optional boolean value. It indicates whether an entity should be validated, defaults to FALSE. This was introduced in Drupal 8.8 and can be used to prevent invalid entities from being migrated. For example, a node with an empty title would fail validation. A required field that is not set by the migration will trigger a validation error, unless the field is configured to have a default value. Similarly, an integer field with minimum and maximum values will trigger an error if a value outside that range tries to be imported. Field API validations are triggered when this configuration option is set to TRUE.

EntityUser

Module: User (Drupal Core) Plugin ID: entity:user See below.
Class: Drupal\user\Plugin\migrate\destination\EntityUser
Extends: Drupal\migrate\Plugin\migrate\destination\EntityContentBase
Inherited configuration options: destination_module, default_bundle, translations, overwrite_properties, and validate.

This class provides a destination plugin for migrating user entities. It performs extra checks like preventing that the password for user 1 is overridden by the migration.

In addition to the keys provided in the parent class chain, this abstract class provides the following configuration keys:

1. md5_passwords: An optional boolean value. If set to TRUE, the pass (password) property of the user entity is assumed to contain an MD5 hash. The passwords will be salted and re-hashed before they are saved to the destination Drupal database.

EntityRevision

Module: Migrate (Drupal Core) Plugin ID: entity_revision:$entity_type See below.
Class: Drupal\migrate\Plugin\migrate\destination\EntityRevision
Extends: Drupal\migrate\Plugin\migrate\destination\EntityContentBase
Inherited configuration options: destination_module, default_bundle, translations, overwrite_properties, and validate.

This class provides an entity revision destination plugin. Only revisionable entities, those that define a revision entity key, can use this destination plugin. It uses the MigrateEntityRevision derivative which sets the plugin ID to entity_revision:$entity_type where $entity_type is the machine name of the entity. For example, entity_revision:node whose revision key is vid and entity_revision:block_content whose revision key is revision_id.

Entity revisions can only be migrated after the entity to which they belong has been migrated. For example, revisions of a given node (entity_revision:node destination migration) can be migrated only after the current version of that node (entity:node destination migration) has been imported.

EntityReferenceRevisions

Module: Entity Reference Revisions module Plugin ID: entity_reference_revisions:$entity_type See below.
Class: Drupal\entity_reference_revisions\Plugin\migrate\destination\EntityReferenceRevisions
Extends: Drupal\migrate\Plugin\migrate\destination\EntityRevision
Inherited configuration options: destination_module, default_bundle, translations, overwrite_properties, and validate.
Related article: Introduction to paragraphs migrations in Drupal

This class provides an entity revision revision destination plugin. It uses the MigrateEntityReferenceRevisions derivative which sets the plugin ID to entity_reference_revisions:$entity_type where $entity_type is the machine name of the entity. For example, entity_reference_revisions:node and entity_reference_revisions:paragraph. For example, entity_reference_revisions:node whose revision key is vid and entity_reference_revisions:paragraph whose revision key is revision_id.

This is the destination plugin used for migrating Paragraphs. Entity reference fields are no longer supported to reference Paragraphs. Instead, entity entity reference revisions must be used. Therefore, this class is used for paragraphs migrations with the entity_reference_revisions:paragraph plugin ID. See this article for an example on how to migrate paragraphs.

In addition to the keys provided in the parent class chain, this abstract class provides the following configuration keys:

1. new_revisions: An optional boolean value. Flag to indicate if a new revision should be created instead of updating a previous default record. Only applicable when providing an entity id without a revision_id. Defaults to FALSE.

EntityConfigBase

Module: Migrate (Drupal Core) Plugin ID: entity:$entity_id See below.
Class: Drupal\migrate\Plugin\migrate\destination\EntityConfigBase
Extends: Drupal\migrate\Plugin\migrate\destination\Entity
Inherited configuration options: destination_module and default_bundle.

This class is used to handle import operations for all configuration entities, unless a specific class exists for the plugin ID being used. For example, taxonomy vocabularies are handled by this class, but node types leverage the EntityNodeType class. The MigrateEntity derivative sets the plugin ID to entity:$entity_type where $entity_type is the machine name of the content entity. For example, entity:node_type, entity:user_role, entity:taxonomy_vocabulary, entity:block, entity:comment_type, entity:block_content_type, entity:contact_form, entity:date_format.

In addition to the keys provided in the parent class chain, this abstract class provides the following configuration keys:

1. translations: An optional boolean value. if TRUE, the destination will be associated with the langcode provided by the source plugin. Defaults to FALSE. For example: en for English, es for Spanish, and fr for French.

EntityNodeType

Module: Node (Drupal Core) Plugin ID: entity:node_type
Class: Drupal\node\Plugin\migrate\destination\EntityNodeType
Extends: Drupal\migrate\Plugin\migrate\destination\EntityConfigBase
Inherited configuration options: destination_module, default_bundle, and translations.

This class is used to import node types. It does not take extra configuration options. The plugin overrides the import method to attach the body field to the imported content type. This depends on the presence of certain destination properties in the imported row. That is, the following properties needs to be mapped in the process section of the migration:

1. create_body: An optional boolean value. If TRUE, a body field will be added to the content type.
2. create_body_label: An optional string value. If set and create_body is TRUE, the value for this destination property will be used as the label of the body field.

Config

Module: Migrate (Drupal Core) Plugin ID: config
Class: Drupal\migrate\Plugin\migrate\destination\Config
Extends: Drupal\migrate\Plugin\migrate\destination\DestinationBase
Inherited configuration options: destination_module.

This class persists data to the configuration management system. In addition to the keys provided in the parent class chain, this class provides the following configuration keys:

1. store null: An optional boolean value. If TRUE, when a property is NULL, the NULL value is stored. Otherwise, the default value is used. Defaults to FALSE. Note that there is a space character in the configuration name.
2. translations: An optional boolean value. if TRUE, the destination will be associated with the langcode provided by the source plugin. Defaults to FALSE.

Additionally, the plugin expects certain destination properties in the imported row. That is, the following properties needs to be mapped in the process section of the migration:

1. config_name: A string value. The machine name of the configuration. For example: node.settings, node.type.article, user.settings, system.site, and core.extension.
2. langcode: An optional string value. The language code of the configuration. For example: en for English, es for Spanish, and fr for French.

Table

Module: Migrate Plus Plugin ID: table
Class: Drupal\migrate_plus\Plugin\migrate\destination\Table
Extends: Drupal\migrate\Plugin\migrate\destination\DestinationBase
Inherited configuration options: destination_module.

This class allows you to write directly to a table not registered with Drupal Schema API. See this test for an example on how to use this plugin.

In addition to the keys provided in the parent class chain, this class provides the following configuration keys:

1. database_key: An string value. Key for the database connection used for inserting records. See this documentation page for more information on database connection keys. We also covered the topic when explaining the SqlBase source plugin.
2. table_name: An string value. Name of the table where records will be imported.
3. batch_size: An optional integer value. Maximum number of rows to insert in one query. Defaults to 1.
4. id_fields: An associative array value. Fields used to uniquely identify table rows. At least one field is required. See the class’s docblock for an example of the expected structure.
5. fields: An optional associative array value. Mapping of column names to values set in the process section.

Available configuration for other migrate destination plugins

In Drupal core itself there are around 50 migrate destination plugins. And many more are made available by contributed modules. It would be impractical to document them all here. To get a list by yourself, load the plugin.manager.migrate.destination service and call its getDefinitions() method. This will return all migrate destination plugins provided by the modules that are currently enabled on the site. This Drush command would get the list:

# List of migrate destination plugin definitions. $ drush php:eval "print_r(\Drupal::service('plugin.manager.migrate.destination')->getDefinitions());" # List of migrate destination plugin ids. $ drush php:eval "print_r(array_keys(\Drupal::service('plugin.manager.migrate.destination')->getDefinitions()));"

To find out which configuration options are available for any destination plugin consider the following:

• Find the class that defines the plugin and find out which configuration values are read. Some plugins even include the list in the docblock of the class. Search for a pattern similar to $this->configuration['option_name'] or $configuration['option_name']. The plugins can be found in the Drupal\module_name\Plugin\migrate\destination namespace. The class itself would be in a file under the /src/Plugin/migrate/destination/ directory of the module.
• Look up in the class hierarchy. The destination plugin can use any configuration set directly in its definition class and any parent class. There might be multiple layers of inheritance.
• Check if the plugin requires the presence of specific destination properties to be set in the process section. This is usually documented in the class’ docblock, but you can also look for code like $row->getDestinationProperty('property_name').

What did you learn in today’s article? Did you know that migrate destination plugins can inherit configuration keys from their class hierarchy? Were you aware that there are so many destination plugins? Other than the ones listed here, which destination plugins have you used? Please share your answers in the comments. Also, we would be grateful if you shared this article with your friends and colleagues.

Read more and discuss at agaric.coop.

Mauricio Orozco from the SC Commission for Minority Affairs gave a talk about the state of Drupal within the SC State government. In recent years Drupal has grown from a tool used on a small number of projects to the platform of choice for all new agency sites. He spoke about the state’s initiative to move more to Drupal, South Carolina Interactive and their role in supporting government projects, which agencies are moving toward Drupal, and how this is benefiting residents of South Carolina.

If you would like to join us please check out our up coming events on MeetUp for meeting times, locations, and remote connection information.

We frequently use these presentations to practice new presentations, try out heavily revised versions, and test out new ideas with a friendly audience. So if some of the content of these videos seems a bit rough please understand we are all learning all the time and we are open to constructive feedback. If you want to see a polished version checkout our group members’ talks at camps and cons.

If you are interested in giving a practice talk, leave me a comment here, contact me through Drupal.org, or find me on Drupal Slack. We’re excited to hear new voices and ideas. We want to support the community, and that means you.

Drupal VM 6 'Rectifier' is here!

I just released Drupal VM 6.0.0 today, and it is the best version of Drupal VM yet!

The main goals for this new version are stability and compatibility.

Originally I was going to drop some features that are helpful for people running older Drupal 7 sites, but since Drupal 7's End of Life was just extended into 2022, I decided to extend the support for some features like Drush make files, as many users of Drupal VM still maintain Drupal 7 sites, or use Drupal VM to test the upgrade from Drupal 7 to Drupal 8 or 9.

The default PHP version was upgraded from PHP 7.2 to 7.4 in Drupal VM 6, and this new version should work great with almost any Drupal 7, 8, or 9 website (in fact, PHP 7.3 is Drupal 9's minimum requirement!).

Jeff Geerling July 14, 2020

14 Jul

Today, we are excited to announce that Dropsolid has joined as one of the exclusive partners that will offer Extended Support for Drupal 7 up until November 2025. This means you get at least 3 extra years of full security coverage. This Extended support program is in collaboration with the Drupal Association and Drupal Security Team, and will give you official support on your Drupal 7 site for a whole extra 3 years. This will give you all the time you need to take the right steps towards a new Digital Experience Platform on Drupal 9 and beyond.

Last year, we encouraged our clients to begin planning their migrations to Drupal 8. Not unsurprisingly, as we will need to say goodbye to our friend, Drupal 7, soon.

Drupal 7 was released on January 5, 2011. Drupal 8 was released on November 19, 2015 and the latest and shiniest release came out a couple days ago with Drupal 9 on June 3, 2020. Drupal 7 is almost 10 years old, and will be almost 12 years old when it comes time to say goodbye in November 2022.

New version or next level?

Moving from Drupal 7 to Drupal 8 or 9 could be a great opportunity to upgrade your digital platforms to the next level instead of merely to the next version. Drupal 9 is more than a CMS, it’s a DXP. Turning your website into a personalized digital experience is not something you do overnight. You need to be well prepared, start from a digital strategy with clear goals. Taking time for that preparation now, will pay off later.

Drupal Extended Support can be a solution if you need more time to finish your digital transformation strategy before upgrading.

A smooth upgrade path for every business on it’s own pace

Some businesses might have other priorities right now or might need more time to prepare the migration to Drupal 8 or 9. Businesses that are hit by COVID-19, or on the contrary, businesses that suddenly have decided to accelerate on their digital transformation and need more time to make a strategic action plan.

At Dropsolid we want to be a reliable partner for all companies using Drupal: big or small, in fast growing industries or in sectors that got hit hard by Corona. We want to provide all businesses with the best possible transition path to Drupal 9, so that business owners can focus on taking the right steps in their digital transformation whenever and however it is strategically the best time for their business.

All customers of Dropsolid using Dropsolid Experience Platform will automatically benefit from highly critical Drupal 7 updates, all other updates require signing up for our Extended Support program.

Want to move your Drupal 7 site to the Dropsolid Experience Cloud and get a bit more time to prepare your next phase?
Get in touch with us!

More information about this program of the Drupal Association can be found at https://www.drupal.org/security-team/d7es
 

Nick Veenhof

During the development of Lucius we built quite a lot of features, that are embedded in the product (an open source Drupal distribution). But we figured some of these might come in handy for other Drupal site owners, outside of the OpenLucius Drupal install profile.

So this is the first release we did: "Simple Like Button", a very simple like button Drupal module that works in two steps:

I recently released a new contributed module to aid translation on Drupal 7 sites: Entity Translation: Separated Shared Elements Form (ETSSEF). Yes, it has a convoluted name! It finally resolves a suggestion from years ago in an Entity Translation project issue, to allow editing untranslatable fields separately to translatable ones. One of our clients has a multilingual product database site with a few hundred fields on their content, so anything like this that could reduce the size of their editing forms is useful. I figure the best way to demonstrate this is with a recipe that blends it together with some other super (but generally obscure) modules. I hope you can spot parts that may be helpful for your projects!

The Recipe
  Ingredients

• Drupal 7, and at least PHP 5.6
• A content type, with well over a hundred fields
• The Entity translation module
• Several languages
• A nice admin theme, e.g. Adminimal
• My new ETSSEF module
• The Field SQL Blob Storage (from my colleague James Silver), Field Storage UI, Field SQL norevisions and Field SQL Storage Group Load modules
• The Field Attach Form Selective sandbox module (also from James)
• A generous helping of persistence and attention to detail
• A pinch of creative ambition

Recipe Difficulty Rating: Intended for experienced Drupal cooks only; others may prefer to try our takeaway service.
 

Method

1. Enable each of the modules listed above, and set the admin theme to be used.
    
2. Configure the various Field storage modules. Try to understand what each of these is doing, and adjust appropriately for you if necessary: // Turn off storage of revision info for your content type that has many fields. $bundle = 'farmer'; variable_set('field_sql_norevisions_entities', array( 'node' => array( $bundle => 1, ), )); // Default to using Blob storage (1 table instead of 1000s). variable_set('field_storage_default', 'field_sql_blob_storage'); // Relabel the options in the UI to make the distinction clear. variable_set('field_storage_ui_relabel_options', array( 'field_sql_blob_storage' => 'Retrievable only', 'field_sql_storage' => 'Sortable & Filterable', )); // Load default-sql-storage fields in batches of 20 (instead of 1 at a time). variable_set('field_sql_storage_group_load_max_fields', 20);  
3. Set up your content type with many many fields. Choose 'Retrievable only' for the storage type for any fields that don't really need to be used for querying against, or sorting/filtering in lists. This will improve performance, as all the field data for those is stored together in a 'blob' column in the database so can be loaded (& unserialized) in a single go, rather than requiring select queries from so many different individual database tables.
    
4. Configure nodes of this type to use entity translation (field translation) and head to the entity translation settings at /admin/config/regional/entity-translation. Set their 'Shared elements on translation forms' setting to 'Only display on their own separate forms':
   
   This ensures that untranslatable fields are just edited on the initial Edit tab (in a 'Shared' secondary tab); with just translatable fields in the translation forms. When there are so many fields, it's worth slimming down forms as much as possible! This also has the advantage that untranslatable data can be edited without needing to touch any specific translation.
    
5. Override the edit form for your node type in a custom module, to use the Field Attach Form Selective module, so that fields are only shown on the form as they are filled in. This vastly reduces the amount of stuff on the form. I've written a gist that demonstrates this, and includes wiring it up to work nicely with ETSSEF. You must copy the entire contents of node_form() from node.pages.inc in Drupal core into the farmer_node_form() function, but replace the call to field_attach_form() at the bottom, with a call to field_attach_form_selective(). Use the same arguments.
    
6. I then added some classes and CSS to the secondary tabs on the page to show the flag icons next to each language, as well as repeating the current tab name in the page title. I then added CSS to fix the page header in place so that editors easily retain that contextual information as they scroll down the giant forms. Otherwise it's too easy for them to forget which language they are editing!

 

Season to taste

Now when you edit your content type, your forms will be much slimmer and your site will run far smoother with hundreds of fields. As with any recipe, take the bits of this that are to your taste, ignore others, or blend it into your own creations! This was only for D7, so bringing the ideas over to Drupal 8/9 in some form would be an obvious thing to do. I’d love to hear of other ingredients you use to help when editing content forms with enormous amounts of fields, translatable or not.

 

Photo by Maarten van den Heuvel on Unsplash

A Brief Guide on Improving the FrontEnd Performance of your Drupal 8 Website with Advanced CSS/JS Aggregation Karishma 14 Jul, 2020 Top 10 best practices for designing a perfect UX for your mobile app

A well-performing website just doesn’t cut it these days. To stand out of competition, businesses are looking for high performance websites with lightning speed load times. You could potentially lose a big chunk of customers with every additional second your website takes to load. Today let’s learn about optimizing the frontend performance of your website with the Advanced CSS/JS aggregation module for Drupal 8.

To make Drupal sites run faster, it is essential to load CSS/JS files as quickly as possible for a page. One problem with Drupal core aggregate is that it is not good at determining which resource (CSS/JS) files go together. So, when you have different pages that require different resource (CSS/JS) files, usually Drupal core does it in a way where there is lot of extra information that are unnecessary on certain pages. The Drupal AdvAgg module comes with a plethora of features to help websites render faster. And the module also supports Drupal 9!

What does the Advanced CSS/JS Aggregation module do?

The Drupal AdvAgg module does a lot of different things to help speed up delivery and loading of resource files on your website. Advanced Aggregation combines multiple CSS files and creates fewer CSS files so that sites render faster. It caches aggregated files more efficiently. It also provides more effective methods of compression. Thus helping in offering users with more engaging user experiences.

Getting started with the Advanced CSS/JS Aggregation module Installing

Installing the AdvAgg module for Drupal 8 is like installing any other contributed modules. I’m using the Composer to install since it automatically installs all of the necessary dependencies. Open the terminal, within the project enter the following command - 

$ composer require 'drupal/advagg:^4.1'

Next, enable the AdvAgg module

  Configuration tab:

This tab provides several configuration options that are discussed below.

Global Options  

1. Enable/Disable the Advagg module temporarily by checking/unchecking the Enable advanced aggregation checkbox.
2. Use this option if you want to allow DNS prefetching for external CSS/JS, which tries to settle domain names for links before a user clicks on them. Enabling this can have unwanted effects on site. Keep this unchecked unless needed.
3. In the Cache settings, we have options like development, low, normal, high caching of resource (CSS/JS) files. High caching stores more data while normal stores less data compared to high. Development caching stores very less data. I'm going with normal here.

Compression options

This provides Gzip compression and Brotli compression which are the methods used for compressing CS/JS assets.

CSS Options/JS Options

1. In order to avoid multiple CSS/JS files in one page, AdvAgg uses media queries to determine what files are needed on a page and combine them so that they load faster.
2. Fix improperly set type – This option will fix the problem in syntax, when you are trying to reference CSS and JS files if there are any problem there
3. If this option is checked, the external stylesheets on the same host are not converted into files.

CRON Options

1. Here you can set the minimum amount of time between advagg_cron() runs. The default value for this is 1 day.
2. Use this option to Delete aggregates that were modified more than the chosen time. The default value for this is 1 month.

Obscure Options

This tab does not contain any configuration options. You can flush the module cache or entire cache in the Operation tab.

Bundler Tab :

This splits your aggregated resource files into multiple bundles of small resource files. With bundler active checked, you have more bundles of small CSS files, it makes sure that it strips anything that's not being used in a given page. Even with the more http request for a resource file you can have overall boost in the performance because of fewer bytes transmission.

This tab has CSS Bundling and the Javascript Bundling with the same configuration settings.
1. Target Number of CSS/JS Bundles Per Page: Specify the number of CSS/JS Bundles to be sent per page.
2. Grouping Logic: You can select the aggregation logic should go by file count of file size.

CDN Tab:

Content distribution network (CDN), is a distributed network of proxy servers that helps immensely in boosting website performance and load time. Website content can be distributed to servers closest to the site visitor which makes response and load times even faster.

1. CDN to use - Choose between a network of server providers Google and Microsoft. 
2.  Checking Use Minified resources would reduce the bandwidth needed because of the smaller file sizes.

CSS Minification tab:

This allows the removal of white spaces, comments, unwanted variable names etc. You can select between the Core minifier or the YUI Compressor, where YUI is better form of compression.

External Minification tab:

External Minification is used when you are using command line compression.

JavaScript Minification tab:

For JS minification select a minifier. Selecting a faster minifier is always better.

Old IE Compatibility tab:

Prevent more than 4095 CSS selectors in the aggregated CSS file - You can modify the value to avoid getting errors from IE Version below 10, where if your CSS has more than 4095 selector IE will not render the page properly.

 

A high-performing website is a necessity in today’s world of neck and neck competition. The Advanced CSS/JS Aggregation module for Drupal 8 truly helps to improve the frontend performance of Drupal websites. This can have a huge impact on user experience and can help garner more engagement. As Drupal developers, we leverage the best of Drupal’s modules and features to ensure our clients expectations are not just met but exceeded. Contact us to know how we can help you on your next Drupal project.

Drupal Planet Drupal Drupal 8 Drupal Development Drupal Module CSS/JS Shefali ShettyApr 05, 2017 Subscribe For Our Newsletter And Stay Updated Subscribe

Leave us a Comment

  Shefali ShettyApr 05, 2017 Recent Posts Image A Brief Guide on Improving the FrontEnd Performance of your Drupal 8 Website with Advanced CSS/JS Aggregation Image Stop Spam! How to use the Captcha and ReCaptcha module in Drupal 8 Image How to manage Google Ads by integrating DFP (DoubleClick for Publishers) with your Drupal 9 website Want to extract the maximum out of Drupal? TALK TO US Featured Success Stories

Know more about our technology driven approach to recreate the content management workflow for [24]7.ai

link

Find out how we transformed the digital image of world’s largest healthcare provider, an attribute that defined their global presence in the medical world.

link

Discover how a Drupal powered internal portal encouraged the sellers at Flipkart to obtain the latest insights with respect to a particular domain.

link

VIEW ALL CASE STUDIES

When users choose an educational institution, the first thing they see is a website. Today every site (no matter for which sphere) should grab the attention of the user, and the websites for educational institutions should also shout “Come to us!”. You no longer have to think about what CMS you should rely on when creating such a site!

We took care of you and picked up 9 examples of Drupal educational websites: Harvard University, Bucknell University, Brown University, Middlebury College, etc. 

Slow down and enjoy the article "Great examples of Drupal websites for universities".

 

I have officially Lifted the PHPStan Drupal extension and the Drupal Check tool on

Drupal 9’s big splash in early June sparked a widespread realization that migration needed to move to front burner status in anticipation of a Nov. 2021 decommission date for Drupal 7 and 8. That sense of urgency has been temporarily tabled as the Drupal organization took the widespread uncertainty and upheaval of the global pandemic into account, and moved the end-of-life date for Drupal 7 and Drupal 8 out by one year to November 2022. So now what?

Creating components using the Paragraphs module offers incredible flexibility in building pages based on Drupal. One of the common restrictions is the issue of reusing the same paragraphs in very similar components. If the only thing that limits you is the set and layout of fields, the Paragraph View Mode module will help you.

The very first lines of the module's code were created as a dedicated module for one of the projects we implemented. I quickly noticed, however, how such a functionality could be useful in the whole Paragraphs module ecosystem. Currently, the module has a stable 1.4 version and is covered by the Security Advisory Policy.

Dates 

The first version of the module was released in July 2019. Since then, I have been actively following the list of issues, implementing patches and new functionalities. The last patches were introduced to the developer version in July 2020.

Module's popularity

According to the statistical data published on the module's page: https://www.drupal.org/project/paragraph_view_mode, it is currently used by about 450 websites, which translates into approximately 10 uses per week.

Module's creators

The first draft of the module was created in order to address the needs of a current project. After its initial release on the drupal.org website, I introduced some additional improvements and new functionalities. The community also helped, e.g. with making the module compatible with Drupal 9.
Currently, I am the only person who worked directly on the module's code. The module itself is supervised by two maintainers who respond to all issues as quickly as possible.

What is the module used for? 

Paragraph View Mode is a sub-module for the Paragraphs module. Its advantages will be appreciated by both, developers and people responsible for editing content on a website. It may be necessary when:

• you are building a website from many components, and some of them are very similar, e.g. they use a similar set of fields;
• you want to minimise the number of components with regards to the administration;
• you think about streamlining the frontend part;
• you want to ensure better organisation of templates with regards to the UI and directly within the code;
• you want to avoid using many complex field-based modifiers, e.g. lists.

As you can see, this module can offer several useful functions, and all this goes hand in hand with the simplicity of this solution in accordance with the so-called "Drupal Way".

Unboxing

You can download the module from the https://www.drupal.org/project/paragraph_view_mode webpage or via composer:

composer require drupal/paragraph_view_mode

After the installation, go to editing the selected paragraph type, the default path is usually:
 
[your_domain]/admin/structure/paragraphs_type/[your_paragraph_bundle]
 
In the "Paragraph View Mode" drop-down section, select the option “Enable Paragraph view mode field on this paragraph type" and then save the form.

The module will automatically create a "Paragraph view mode" field with a configuration widget (available in the manage form display tab).
 
The widget's configuration consists of two fields. The first field is the selection of available display modes. The module automatically receives a list of only those that are unblocked on the current paragraph type, while you can decide which of them you want to display on the list of options in the form.

The second field is used to define the default value of the field in the absence of its value (e.g. for a newly created paragraph).

With the module configured in this way, you can dynamically switch the display modes directly in the page adding/editing form.

Plans for the future

The basic functionality of the module is already completed, and it is hard to come up with new functionalities. Recently, however, I created a new issue https://www.drupal.org/project/paragraph_view_mode/issues/3150153, in which I plan (with a little help from the community) to develop the functionality of linking the field value with the display mode of the form and its dynamic substitution. I also intend to continue supporting Drupal 9 and future versions.

Summary

The Paragraph View Mode module, despite its low complexity, offers a lot regarding the efficiency, convenience and – above all – flexibility of the editors' work. In addition, it allows the Drupal developers or the person responsible for the website to reduce the amount of work needed to organise and maintain the components on the website, thus reducing the overall cost of maintaining the website.