Development News

PreviousNext: How to integrate your pattern library with Drupal's layout builder using Component Blocks module

Main Drupal Feed - 16 hours 1 min ago

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

WPTavern: Blocksy Theme Adds New Charity Starter Site, Pro Version to Launch in 2020

Wordpress Planet - Wed, 07/15/2020 - 22:32

Blocksy is one of the best free themes available for the block editor right now and is rapidly growing in popularity. CreativeThemes, the Romania-based company behind the theme, released an update to Blocksy this week, along with a new starter site for charities.

The concept of “starter sites” is an interesting new twist on “starter templates,” which essentially allow users to import the content from a demo. Theme makers for products like Blocksy, Astra, and Go use this approach to help users implement different types of websites by importing the content from a pre-built demo site. The demos use the same base theme but vary widely in how they are customized.

Blocksy’s starter sites are a one-click XML demo import that automatically brings in the pages, images, and theme options. This puts all the blocks in the right place so the user needs only to customize the demo, instead of trying to find the right settings to match the demo.

The new Charity starter site is built with the Stackable plugin’s page builder blocks. It joins four other free starter sites designed specifically for blogs, apps, travel, and e-commerce. The design can be imported under the Blocksy menu in the WordPress admin.

According to the theme’s beautifully designed and user friendly changelog, Blocksy can now automatically detect Custom Post Types and add their appropriate options. The update also adds a sizing option for related posts thumbnails, a new Twitch social icon, and improves compatibility with WooCommerce product display and miscellaneous extensions.

Blocksy Pro Version Coming Soon

When we first reviewed the theme in January 2020, it had 1,000 active installs and 58 five-star reviews. Over the past six months, the theme’s user base has grown to more than 4,000 active installs and a perfect five-star rating on WordPress.org from 191 reviewers. It is currently maintained by a team of two – Sergiu Radu and Andrei Glingeanu.

Blocksy’s creators have been working on custom projects and random jobs to support the time they spend developing the theme but they plan to launch a pro version as early as this summer.

“We plan to add more features in the premium version, more demos, and also offer better and faster support,” Radu said. “I hope after we release the premium version we will be able to take on a few more people in our team to help us, at least with support so we can concentrate better on development.”

Radu said the pro version will include some premium starter sites as well as additional functionality for the base theme. They are aiming to include the following features in the first release:

  • Multiple conditional headers
  • Multiple conditional footers
  • Multiple conditional sidebars
  • More header elements
  • More footer elements
  • White labeling
  • Custom fonts extension
  • Adobe Typekit extension
  • Hooks (conditional)
  • Sticky header

In a second round of updates for the pro version, Blocksy creators plan to include features like custom color palettes, AMP, LearnDash, and EDD integrations, along with extensions for ads, mega menus, and portfolios. In the meantime, Radu says they do not plan to add more features to the free version – only improvements and new starter sites.

WPTavern: Eye-Catching Typography and Personality: Blossom Themes Launches Sarada Lite

Wordpress Planet - Wed, 07/15/2020 - 20:56
Sarada Lite homepage.

Blossom Themes launched Sarada Lite, its 25th theme, on the WordPress theme directory today. The theme is billed as a “feminine blog theme” specifically for professional bloggers. However, it would work well in a variety of contexts. While it is targeted at fashion, travel, and lifestyle bloggers, it is well-rounded enough for anyone who wants a touch of personality as part of their blogging experience.

I nearly passed over this theme. It had no mention of the block editor or Gutenberg in its description. It was not tagged in the directory as having editor styles (technically, it doesn’t have them). There are few themes that I give much attention to if they do not style the latest features and blocks in WordPress. It has to be truly eye-catching otherwise. Sarada Lite is a breathtaking design, so it drew me in. It is the sort of theme that inspires me to write. Plus, its light color scheme along with the author’s choice of images in the demo fit perfectly into the summer season. It simply makes me want to sit on the beach with a mojito and my laptop ready to spin up some great content.

What makes this theme stand out is its typography. The status quo with most free themes in the WordPress theme directory is to simply not give any attention to things like font size, characters per line, line height, or vertical rhythm. Long-form content is practically unreadable with such themes. However, long-winded writers need not be fearful of the reader losing interest because of the design. Sarada Lite creates an inviting atmosphere that beckons the visitor to actually read.

The theme supports several plugins, most of which are a part of the Blossom Themes collection. They are unnecessary for a solid blogging experience with this theme. Users should shy away from taking advantage of every bell and whistle the theme or its add-ons provide. The default setup is mostly where the theme shines.

Users who need a shop can also enjoy WooCommerce integration. The theme does not add much in the way of shop-related features, opting to style the default output of the eCommerce plugin instead.

Design Elements Worth Noting Single post view.

When testing and reviewing themes, it is often easy to get lost in the features. However, with Sarada Lite, it’s not the theme features that are important. They may even be a detriment to the theme (more on that later). The thing that makes this theme special is the small design elements. The author puts a unique spin on things that give the theme a personality of its own. Designers who want to show off their design chops often go overboard, but Sarada Lite has just enough flair to draw attention to important elements without getting in the way of the content.

In particular, the theme’s use of the Caveat font gives secondary text just the right amount of pop. It is not a font that lends itself well to long-form content. However, the theme makes use of it for links, captions, quote citations, and a few other elements.

Sarada Lite’s blockquote design.

The theme offers various layouts with and without a sidebar. For single posts, I recommend dropping the sidebar and choosing the full-width centered layout to make full use of the block editor’s capabilities. This gives enough breathing room for users who like to make liberal use of wide and full-width blocks. The theme has an option to change the layout globally and on a per-post basis.

Issues

One of the biggest issues with Sarada Lite is that users do not get a one-to-one match between the editor and the front end. The missing piece is the theme’s beautiful typography. It is nowhere to be found while writing a post. The theme’s admin-side CSS is bare-bones to the point where there is little use in loading the stylesheet. I hope this is merely something the theme author skipped for version 1.0 with a firm plan to add it in the next release. At worst, it is an extra couple of hours of work that offers a huge benefit to theme users.

The other major downside of Sarada Lite is that it tries to do too much. Its customizer options feel a bit overboard and disorganized. In too many cases, I was left wondering what a particular option was for or searching around for specific options in odd places.

I also found the Instagram feed (available via the Blossom Themes Social Feed add-on) in the header to be a horrendous addition, ruining what is an otherwise open and inviting design. Fortunately, this is an optional feature. Once again, the theme is doing too much here. I understand it is a bullet point on the ol’ marketing sheet, but it is an eyesore in practice. The Instagram feed works much better in the footer. My advice for theme users: avoid putting this in your header at all costs. Your site visitors should not need to skip over social media images just to get to your content.

As gracefully as the various sliders on the theme’s homepage are done, I am now and always anti-slider. They offer no real benefit to the reader and often hide away content that would have otherwise been seen. The theme’s slider sections, some of which are optional, are relatively low-key. I have seen far worse, but I would rather not see them at all.

Despite the theme’s issues, they are not so detrimental that I wouldn’t recommend the theme. Assuming the theme author adds in editor styles that match the front end, the other issues can mostly be avoided by user choice. The theme works well without tinkering with its options and adding extra plugins.

Sarada Lite is best without all the extras. What the user does with the theme will make or break the experience.

Lullabot: Continuous Deployment, Infrastructure as Code, and Drupal: Part 2

Main Drupal Feed - Wed, 07/15/2020 - 18:46

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.

Dries Buytaert: Drupal 10 target release date and Drupal 9 end-of-life

Main Drupal Feed - Wed, 07/15/2020 - 12:17

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.

HeroPress: Second Chances: How A Trip Back Into The WordPress Community Saved My Life

Wordpress Planet - Wed, 07/15/2020 - 11:00

Often, we refuse change and don’t get a second opportunity to make things right. But for me, June 17, 2017, changed my life forever. A life-threatening heart event forced me to start over and in the short time since WordPress helped me rediscover myself and to do the things I truly love.

At 10 am that morning, I was laid out flat on a cold, hard operating table being poked, prodded, and prepped for a surgical procedure. According to my doctors, this procedure was the only sure way to find out what had been plaguing me for five long years. Within the next sixty minutes, if things go sideways, I could be dead.

As I slowly came to, words floated through a lifting fog of anesthesia. “You had two 100% blocked arteries,” my cardiologist said. A flood of concern and questions seemed to flow freely foremost, “what will happen to me?”

Two Paths Lead to WordPress

Looking back, my WordPress journey has two paths, pre- or post-heart event. When the lead developer and CSS goddess left our public transit agency almost 10 years ago, they left behind a company news blog with the Headway theme. That year we were fortunate to have room in our budget allowing me to attend the WordPress VIP Intensive Developer Workshop in Napa.

At that time my experience was entirely in basic static HTML as a web designer so imagine how lost and out of place I felt being asked to “spin up a virtual box” midway through the first day. Surrounded by the best and the brightest distributed Automatticians from around the world, person after person answered my questions or assisted in any way they could. That day I learned what the phrase WordCamp Community really meant.

Leaving the Past Behind

What if you got a do-over? A mulligan, a reset button? Imagine being totally free from the stressors of the daily grind, similar to being a young child, with nothing to do but play all day.

Staring at the ceiling from my bed while recovering, I decided to stop the world and get off. I took a leave of absence from work beginning September 11. Looking deep within, I searched to rediscover me and the loves of my life – giving selflessly to others, picking up a pencil to sketch, storytelling, and WORDPRESS.

Every day for the next ninety days, I resolved to do only the things reconnected me with things dormant in my past that brought me joy:

  • Each morning I’d pick up a pencil, sketch;
  • I’d exercise and practice mindfulness; and
  • No day would be complete without giving back, doing something with WordPress for others. Like an Agile process, I’d loop through these tasks, reassess, then repeat, each morning becoming stronger than the previous.

Slowly, progress was being made in my recovery. From feeling faint and unable to walk from my bedside to my bathroom; 100 steps turned into 100 yards then one lap at my local park. I set a goal to climb to one of the highest points in our area, the top of Central Park.

The Journey of 4,890 Miles Begins with One Step

My second path into WordPress started later that summer. Untethered, I walked into my first-ever official WordPress Meetup in a coworking space located downtown Los Angeles, apprehensive, unsure what to expect. That evening a wonderful speaker on SEO followed the organizers from WordCamp Los Angeles calling for volunteers and I immediately raised my hand. The old me would not have.

From that point through December, I attended almost twenty (20) WordPress Meetups, attended four WordCamps (Grand Rapids, Los Angeles, Riverside, and United States via Livestream) logging almost 5,000 miles in the process. Rebuilding a website for a printing company pro bono while rehabilitating my heart and body. The energies received in return for giving back to the WordPress Community healed me emotionally, allowing me to contribute creatively — I loved it and wanted to do even more!

Making a List, Checking It Twice

Tired of driving home very late nights from area Meetups from all points around SoCal, I decided to start a meetup locally. On January 26, 2018, at 7:30 pm, I reached the last slide of my first presentation at our official WordPress Santa Clarita Valley Meetup. It read, “host the first annual WordCamp Santa Clarita”.

The faces in the audience – Tom, Steve, Matt, and others new to WordPress all looked at me skeptically, seeing someone full of dreams, spouting enthusiasm. But one thing was clear to me — WordPress had given me a shot at reclaiming something laid dormant and anything seemed possible.

Sixteen (16) months later, the first WordCamp north of Los Angeles and south of Sacramento since 2014 debuted in Santa Clarita. A small, but an incredible team of volunteers bought into my enthusiasm turned around and gave back to our attendees in our WordPress Community.

Speak On It

In my pre-heart event life, I began public speaking in a formal setting completing over 40 presentations but had stepped off the stage years earlier in a company club. Back in 2014 while walking through the break room at WordCamp Los Angeles one of the lead organizers handed me a mic and asked me to speak. Afterward, he said, “you should present at a WordCamp.”

Four years later, I stood on stage at WordCamp Chicago sharing my WordPress journey and hoping to inspire others to never give up on going after your dreams. Until that weekend in Chicago, I hadn’t seen any African-American men onstage and felt it important to encourage diversity through my message of rebirth.

“Live as if you were to die tomorrow. Learn as if you were to live forever.”

Mahatma Gandhi

I’ve met the most incredible group of nurturing, giving, and talented people stretching back to Sara (Rosso) in Napa through Angela (Jin) or David (Bisset) on the WordCamp US team. Every time I needed confidence or a word of encouragement Cami (Kaos), Kathy (Drewien), Brandon (Dove), or someone in the Community was that steadying hand on my shoulder.

I think about these words often as inspiration, waking each morning to greet the sunrise full of ideas and promise. How can I give back? What can I do with WordPress today?

The post Second Chances: How A Trip Back Into The WordPress Community Saved My Life appeared first on HeroPress.

Agaric Collective: Drupal migrations reference: List of configuration options for destination plugins

Main Drupal Feed - Wed, 07/15/2020 - 06:45

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.

WPTavern: WordCamp Europe Goes Virtual for 2021, In-Person Conference to Resume 2022

Wordpress Planet - Tue, 07/14/2020 - 23:55

While much of the world is currently suspended in the uncertainty caused by the pandemic, WordCamp Europe delivered a surprisingly decisive announcement today regarding the status of the 2021 event in Porto. Organizers moved to make it a virtual conference, 10 months in advance of the planned dates, June 3-5, 2021:

After careful consideration, and following guidance from WordCamp Central, we have agreed to hold WCEU 2021 online.

Although it was a difficult decision, it also seems the right thing to do. Considering the continuing uncertainty regarding COVID-19, we are hesitant to draw so many individuals from so many different places into one physical space.

We understand that this decision will come as a disappointment to many. We know that this event is a much-needed social outlet for many in our community and that an online event isn’t quite the same as a physical event. We’re so sad to not be able to greet you all in person in Porto in June.

The announcement cited several positive aspects of going virtual, including eliminating the uncertainty for attendees and their travel arrangements, allowing for a larger global audience without the expense and risk, and having more time for creating a better online experience. The 2020 event had just three months to convert to a virtual conference but was able to reach more than 8,000 attendees.

In the absence of a vaccine ready for mass distribution or any proven commercially available therapeutics specifically designed to target the virus, it is impossible for organizers to nail down a safe timeline for a multinational event in 2021. Hugh Lashbrooke, who is assisting the WCEU organizing team as a mentor from WordCamp Central, identified risk mitigation as one of the primary factors in their decision.

“Attendee safety is a primary concern in WordCamp organizing,” Lashbrooke said. “While the pandemic is progressing differently in different regions of the world, it seems that large in-person events that bring together thousands of people from multiple countries in a single shared space are still a risky proposition — and it’s not clear when this will be safe again.”

WordCampers reacting to the news today seemed to understand the need for such a disruptive change, but most expressed deep disappointment.

“I’m sure the decision won’t have been taken lightly,” Simon Dickson said. “But WCEU is so important in terms of defining and sustaining the European – and indeed, global – WordPress community. With all due respect to online alternatives, two blank years will hit community spirit hard.”

The goal for WordCamp Europe is to resume the in-person event in 2022 and organizers have booked the Super Bock Arena (Pavilhão Rosa Mota) for June 2 – June 4, 2022. 

If WCEU can resume normal operations in 2022, it will be the first time in three years that the European WordPress community has had the opportunity to gather in-person in one place. One disappointed attendee said, “Understandable. As we say in Portugal: À terceira será de vez! Até 2022,” which roughly translates to the English saying, “Third time’s a charm.”

WordPress Community Team Is Working Towards Facilitating More Effective Events

Lashbrooke said adjusting to emerging world events has been hard on all WordCamp organizing teams this year, as well as sponsors, speakers, and attendees. WordCamp Asia was forced to cancel, WordCamp US has gone virtual, and many other smaller camps have gone online or been postponed. The WordPress Community team is discussing how they can improve online events to provide a better experience for the community. Some of the broader ideas for creating more effective events include the following:

  • Decouple online events from geography
  • Encourage events and workshops defined by topics, languages, etc.
  • Explore shorter, “snack-sized” online events
  • Experiment with the frequency of events

A peripheral discussion regarding sponsors is happening on Twitter, after recent online WordCamps failed to deliver a positive experience of virtual sponsor booths.

“If you want to offer sponsors a ‘Virtual Booth’ as a benefit of sponsorship, you’re going to have to do something during the main event to make that attractive and easy for attendees to attend — otherwise it’s not a sponsor benefit,” Matt Cromwell said.

“If attendees have to log off the regular WordCamp platform, then go find some other link to some other virtual platform the experience becomes arduous and full of friction for the attendee making it highly unlikely they’ll attend. WordCamps that are switching to virtual should look into more robust platforms like Hopin which allow for various rooms that are consolidated to the same platform for attendees.”

WordCamp Europe 2020 organizer Bernhard Kau said his team looked into using Hopin but found it wasn’t fully accessible.

“Hopin looked promising at first, not only for sponsors, but also for networking between attendees,” Kau said. “But it lacks basic accessibility. It’s unusable with keyboard only for example. I’d love to see it improve, so we could use it in the future.”

Lashbrooke said WordCamp Central has also considered Hopin, among other apps, while doing extensive research on accessible platforms.

“Right now, everyone’s still working on a way to make that work for everyone, and we’re lucky that our sponsors are so honest with us about their experiences, because it helps us improve,” Lashbrooke said.

“One thing that is of paramount importance to us as a team is that all WordPress events maintain a high level of accessibility, and unfortunately when it comes to streaming platforms we have very limited options when it comes to accessible streaming services. Zoom is about the only fully-accessible platform, so it’s the only option to use for sponsor booths.”

With ten months of lead time, WordCamp Europe organizers will have plenty of opportunities to experiment with new ideas to make the event more engaging for both attendees and sponsors. All the other WordCamps on the schedule through the end of the year have already been converted to online events. For the time being, it looks like virtual camps are here to stay.

“I really doubt we’ll be abandoning online events, after COVID-19 is more under control worldwide,” WordPress Community organizer Andrea Middleton said. “I think that we’ll need to figure out how in-person events and online events can best coexist, but it seems like we’ll have time to figure that out.”

Spinning Code: SCDUG July 2020 – Drupal in SC State Government

Main Drupal Feed - Tue, 07/14/2020 - 20:29

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.

WPTavern: Call for Block Plugins: The WordPress Block Directory Is Open for Business

Wordpress Planet - Tue, 07/14/2020 - 20:09
WordPress block directory.

Over the weekend, Alex Shiels announced an open call for plugin authors to begin submitting one-off block plugins to the official block directory. In the upcoming WordPress 5.5 update, slated for release on August 11, end-users will be able to search for, install, and add blocks directly from the editor. With little time left before release, will plugin authors make this a worthwhile feature for users?

“The Block Directory is a subset of plugins in the plugin directory that can be instantly and seamlessly installed from the Gutenberg editor with a single click,” wrote Shiels in the announcement. “We call these new plugins ‘block plugins’ and have worked hard to make it easier for people to contribute to this new feature coming to WordPress 5.5.”

WordPress plugin authors now have a new block validation tool at their disposal. The validator can check an SVN repository URL, Github URL, or plugin slug to determine if it is suitable for inclusion into the WordPress block directory. It is still under development, so plugin authors should report any issues they run into.

For existing plugins in the plugin directory, developers can publish them to the block directory after passing validation with the tool. Plugin authors can also remove their plugins from the block directory at the click of the button.

The block plugin guidelines are still under development. The draft ticket has been open since November 21, 2019. It has seen little activity in the months since. Presumably, there will be a finalized version on WordPress.org rather than GitHub before WordPress 5.5 lands.

Developers who want to begin building block plugins should follow the updated block development tutorial.

A Late Rallying Cry

Technically, plugin authors have been able to submit blocks to the directory for months. It was a bit of a hidden feature that few developers took advantage of. The user base was primarily Gutenberg plugin users who had enabled the experimental block directory search feature. Despite the small user base, it was an ideal time for plugin authors to begin experimenting and building an audience. It could have also been a great opportunity for relatively unknown developers to make their mark upon the WordPress world. There is still some time for that, but the community has not been actively encouraged to create blocks for the directory. With WordPress 5.5 looming ahead, the past few months seem like a missed opportunity.

Nick Hamze, one of the most prolific publishers of one-off blocks, is taking a break. He originally had plans to release 99 plugins throughout 2020, but the WordPress plugin review team asked him to dial things back a bit. His routine releases were putting a strain on the team. The problem is that he was one of the few plugin authors putting in the work to make the block directory a great thing.

As a former reviewer for the themes team, I understand how easy it is to get overwhelmed with a wave of new projects that need a code review. At the same time, I would be willing to bump Hamze’s work to the front of the line, regardless of how often he was releasing new plugins. It may be a bit unfair to other plugin authors, but few others were betting big on what will be one of WordPress 5.5’s highlights: a searchable block directory.

“If someone would have just given me the barest encouragement I would have kept going, but due to my experience, I stopped submitting blocks and won’t do it anymore in the future,” said Hamze.

If no one else was putting in the work, there should have been no harm in giving him a bit of priority or a helping hand. That way, when WordPress 5.5 launches, there is something to show for this feature.

Now, we are in the 11th hour, mere weeks before 5.5’s official release, with a meager offering of blocks — instead of hundreds of blocks, we are currently nearing the 60 mark. It is a last-minute rallying call to get plugin authors churning away before the final bell rings. Yet, WordPress just benched what was essentially its star player.

I have no doubt the block directory will continue to grow. More developers will buy into it, especially as full-site editing creates more possibilities in WordPress 5.6 later this year. Some authors will likely produce more blocks than the totality of the current number in the directory.

If the Gutenberg team had managed to squeeze the directory and management screens into WordPress 5.5 admin, it would have made for a far bigger splash. It would have been good visibility for block makers. WordPress will support a block directory search for now. However, there is no way for end-users to more casually browse blocks via their admin. There is no way to see the latest block plugin releases or view the most popular blocks. Some of these things may have made one-off block development a bit more enticing to plugin authors.

I am still optimistic that more plugin authors will jump onto the block bandwagon. It will just be a while before we start seeing the wealth of blocks that cover the entire spectrum of what users need.

WordPress.org blog: WordPress 5.5 Beta 2

Wordpress Planet - Tue, 07/14/2020 - 17:24


WordPress 5.5 Beta 2 is now available!

This software is still in development, so it’s not recommended to run this version on a production site. Consider setting up a test site to play with the new version.

You can test WordPress 5.5 beta 2 in two ways:

WordPress 5.5 is slated for release on August 11th, 2020, and we need your help to get there!

Thank you to all of the contributors that tested the beta 1 development release and provided feedback. Testing for bugs is an important part of polishing each release and a great way to contribute to WordPress. Here are some of the changes since beta 1 to pay close attention to while testing.

Some highlights

Since beta 1, 48 bugs have been fixed. Here is a summary of a few changes included in beta 2:

  • 19 additional bugs have been fixed in the block editor (see #23903 and #23905).
  • The Dashicons icon font has been updated (see #49913).
  • Broken widgets stemming from changes in Beta 1 have been fixed (see #50609).
  • Query handling when counting revisions has been improved (see #34560).
  • An alternate, expanded view was added for wp_list_table (see #49715).
  • Some adjustments were made to the handling of default terms for custom taxonomies (see #43517)

Several updates have been made to the block editor. For details, see #23903 and #23905.

Developer notes

WordPress 5.5 has lots of refinements to polish the developer experience. To keep up, subscribe to the Make WordPress Core blog and pay special attention to the developers’ notes for updates on those and other changes that could affect your products.

How to Help

Do you speak a language other than English? Help us translate WordPress into more than 100 languages!

If you think you’ve found a bug, you can post to the Alpha/Beta area in the support forums. We’d love to hear from you!

If you’re comfortable writing a reproducible bug report, file one on WordPress Trac, where you can also find a list of known bugs.

WordPress 5.5 Beta 2

Wordpress News - Tue, 07/14/2020 - 17:24


WordPress 5.5 Beta 2 is now available!

This software is still in development, so it’s not recommended to run this version on a production site. Consider setting up a test site to play with the new version.

You can test WordPress 5.5 beta 2 in two ways:

WordPress 5.5 is slated for release on August 11th, 2020, and we need your help to get there!

Thank you to all of the contributors that tested the beta 1 development release and provided feedback. Testing for bugs is an important part of polishing each release and a great way to contribute to WordPress. Here are some of the changes since beta 1 to pay close attention to while testing.

Some highlights

Since beta 1, 48 bugs have been fixed. Here is a summary of a few changes included in beta 2:

  • 19 additional bugs have been fixed in the block editor (see #23903 and #23905).
  • The Dashicons icon font has been updated (see #49913).
  • Broken widgets stemming from changes in Beta 1 have been fixed (see #50609).
  • Query handling when counting revisions has been improved (see #34560).
  • An alternate, expanded view was added for wp_list_table (see #49715).
  • Some adjustments were made to the handling of default terms for custom taxonomies (see #43517)

Several updates have been made to the block editor. For details, see #23903 and #23905.

Developer notes

WordPress 5.5 has lots of refinements to polish the developer experience. To keep up, subscribe to the Make WordPress Core blog and pay special attention to the developers’ notes for updates on those and other changes that could affect your products.

How to Help

Do you speak a language other than English? Help us translate WordPress into more than 100 languages!

If you think you’ve found a bug, you can post to the Alpha/Beta area in the support forums. We’d love to hear from you!

If you’re comfortable writing a reproducible bug report, file one on WordPress Trac, where you can also find a list of known bugs.

Jeff Geerling's Blog: Drupal VM 6 'Rectifier' is here!

Main Drupal Feed - Tue, 07/14/2020 - 17:17
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

Dropsolid: Dropsolid among the first exclusive partners providing Extended Support for Drupal 7, worldwide.

Main Drupal Feed - Tue, 07/14/2020 - 15:04
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

OpenLucius: 'Simple Like Button' released as a Drupal module | Why we used a custom AJAX form -and a custom entity.

Main Drupal Feed - Tue, 07/14/2020 - 14:11

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:

ComputerMinds.co.uk: A recipe for editing & translating over 100 fields

Main Drupal Feed - Tue, 07/14/2020 - 12:23

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


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

Specbee: A Brief Guide on Improving the FrontEnd Performance of your Drupal 8 Website with Advanced CSS/JS Aggregation

Main Drupal Feed - Tue, 07/14/2020 - 08:20
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

ADCI Solutions: Great examples of Drupal websites for universities

Main Drupal Feed - Tue, 07/14/2020 - 06:29

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".

 

WPTavern: Admin 2020 Reimagines WordPress Admin and Media Library

Wordpress Planet - Mon, 07/13/2020 - 23:21

Unless I’m trying to be aware of it, I don’t see the WordPress admin anymore. When you work inside it every day, it becomes a means to an end, like a subway ride to work. You scan your ticket (log in) and you’re on your way to whatever admin business is the order of the day. After awhile, you accept its appearance and no longer spend conscious thoughts critiquing it.

WordPress doesn’t overhaul its admin design very often, since it requires a massive effort from contributors. The beauty of this pluggable system is that anyone with the skills can change the design to suit their own aesthetic. That is what WordPress developer Mark Ashton has done with Admin 2020, a plugin that completely reskins the admin to give it a different look.

Browsing the Admin 2020 demo, you might not even know you were using WordPress. The design is built on top of UIkit, a lightweight UI framework that has a softer, rounder look to it. Users can switch between light and dark mode. Admin 2020 features white labeling, allowing users to upload their own logos and brand the dashboard for themselves. The admin area can also be radically simplified based on user role. The plugin allows for admin menu items to be renamed or toggled for visibility.

Admin 2020 has an Overview page that can sync with Google Analytics to show reports that can be filtered by date, including Users, Page Views, Sessions, and device breakdown. It also displays summaries of recent comments, popular pages, system info, new users, and other content-related data.

The plugin gives WordPress’ media library a new look, along with folders and filters for an alternative way to organize images. Ashton claims it is up to 50% faster than the classic WordPress media library. The gallery editor also adds filters, free draw, icons/shapes, text and other mask filters for enhancing images.

“A lot of what admin 2020 does is built on existing WordPress functions, it just uses them in a different way,” Ashton said. “Instant search for example leverages AJAX and you can search all of your content from one place.”

The Admin 2020 plugin started out as a personal passion project. After building everything from plugins to themes to a hospitality reservation management system using WordPress, Ashton thought he would try his hand at making an admin theme he would enjoy using.

“It was something I have always wanted and basically got tired of waiting for,” he said. “I’ve been using WordPress for my projects for many years and while I love the platform I have never enjoyed using the backend. I wanted to create something with a strong emphasis on modern UI but also something that brought useful features that would speed up my workflow.”

Ashton said supporting third-party extensions is one of the most challenging aspects of maintaining the plugin. Admin 2020 includes full support for popular plugins like Jetpack, WooCommerce, Elementor, Yoast SEO, and Divi Builder, but there are thousands of others that have not been tested.

“The process of supporting a plugin usually isn’t that difficult but it’s more the case of there are so many plugins out there,” Ashton said. “Some plugins rely heavily on their own CSS in which case they usually work fine in light mode but don’t look right in dark mode. Then you have plugins that use WP components and they usually work great right out of the box. Some plugins actually disable all custom backend styling, though – they are a real challenge to get around!”

Ashton launched Admin 2020 in April, so it is still relatively new to the commercial plugin scene. It is sold as a single plugin but is built in a modular way so that most parts of it can be disabled. The plugin’s tiered pricing begins at $15 for a single site license. He opted to pursue a fully commercial model as opposed to releasing a free plugin with paid upgrades.

“In short, I wanted the plugin to stay as streamlined as possible,” Ashton said. “I didn’t want to add yet more plugin notices at the top of admin pages bugging you to upgrade. I wanted people to experience the full version of Admin 2020.”

His strategy has been successful so far, as Admin 2020 has become a full-time project after just three months. The London-based company is a one-person effort at the moment, but Ashton is looking to bring another developer on.

“Active installs are around 2,000 now, and as a result I am very busy and Admin 2020 is a full time project,” he said. “I love working on the plugin though, there is a lot of scope on where this can go and the feedback has been great!”

When asked if he worries about the name becoming outdated in the coming years, Ashton said he is happy with the name but if he thinks of something more suitable it may change in the future. He believes there is a market for all kinds of different themes to transform the WordPress admin but isn’t currently planning to add more designs.

“Not everyone is the same, and good design looks different to everybody,” Ashton said. “I am not looking at other designs at the moment – more offering the ability to customize the design yourself through Admin 2020.”

Pages