Inhalt abgleichen
Drupal.org - aggregated feeds in category Planet Drupal
Aktualisiert: vor 2 Minuten 59 Sekunden

Xeno Media: Web Accessibility Part I: Do we still need to ask?

18. Dezember 2017 - 22:06

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”

Tim Berners-Lee, 1997

What exactly is web accessibility?

Web accessibility is the removal of technical impediments that could limit access to or interaction with a website by any person with disabilities. The goal of a web accessible site is to allow all users equal access to all content and functionality. 

Some disabilities that web accessibility can address
  • Visual: Visual impairments up to and including complete blindness, various common types of poor vision, color blindness

  • Motor Skills: Difficulty using hands, tremors, Bradykinesia, loss of detailed muscle control, etc., due to conditions such as Parkinson’s, MS, stroke, and other movement disorders

  • Auditory: Hearing impairments up to and including total deafness and including the hard of hearing

  • Cognitive: Cognitive impairment and learning disabilities (Dyslexia, Dyscalculia, etc.) that may affect memory, attention, problem-solving and logic skills.

Temporary Disabilities

When developing with accessibility in mind there will almost certainly be some unexpected good fortune.  For example: if a person breaks her primary hand, and is forced to wear a cast, she may temporarily lose the ability to operate a mouse. The developer didn’t plan to cater to the temporarily disabled, but well designed keyboard navigation could surely save the day for such an accident victim.

Why does web accessibility matter?
  • It’s the right thing to do.

    Here’s a chance to make a positive difference in many people’s lives. Improving a site’s accessibility will make that site better for all users and will likely improve its position in the SERPs (Search Engine Result Pages). So be a good citizen and contribute to web accessibility! Make the web a better place for everyone!

  • It may be required.

    There are various state and federal laws regarding web accessibility.

    Some organizations and businesses have faced legal action for non-compliance with accessibility guidelines. Even if you were to win such a challenge, the cost in legal fees and in lost time would be substantial. Why risk exposing your business to the possibility of a legal challenge.

  • It’s good for business.

    According to the U.S. Census Bureau’s 2002 Survey of Income and Program Participation (SIPP), there are 51.2 million people with disabilities in the United States. That’s 18.1% of the U.S. population! Those folks need goods and services too, some of which are very specialized.

    Millions of people with disabilities shop, travel, buy cars, buy homes, eat out, go out and participate in most of the same activities as their fully-abled friends, neighbors and family. Web developers are in a unique position to work towards the good of all to advocate for and to help facilitate these behaviors. We all benefit.
     

  • Web accessibility is becoming easier to achieve and more unified with web standards as time passes.
  • More to come

    This series on Web accessibility will continue with the following:

    Part II: What guides accessibility efforts?

    This post will highlight the laws and governance related to web accessibility efforts.

    Part III: Tools and techniques for web accessibility

    Here we will provide a primer on assistive technologies and tools you and your developers can use to make your site more accessible.

    Part IV: Case studies

    This post will highlight two real-world applications where we have worked closely with clients to achieve highly-accessible websites. 

     

    Evolving Web: Writing a Custom Migration Source Plugin in Drupal 8

    18. Dezember 2017 - 20:01

    Usually, Drupal migrations get run at the beginning of a project to get all your content into Drupal. But sometimes, you need to create a migration that runs on a regular basis. For example, you have an external database of courses and programs maintained by a university that needs to be displayed on a Drupal site. Another example: you have a database of book data that needs to be pulled into Drupal nightly.

    When working with migrations where the source files are updated every day, it can get really tedious to download the updated source files manually each time the migration runs.

    In this tutorial, we'll write a source plugin based on the CSV source plugin which will allow us to automatically download CSV files from a remote server via SFTP before running migrations. This article was co-authored by my colleague David Valdez - gracias David for your contribution.

    The Problem

    In a project we worked on recently, we had the following situation:

    • CSV files are updated by a PowerShell script every night on the client's server.
    • These CSV files are accessible via SFTP.

    Our task is to download the CSV source files over SFTP and to use them as our migration source.

    Before We Start The Plan

    The goal is to avoid downloading the file manually every time we run our migrations. So we need a way to doing this automatically everytime we execute a migration. To achieve this, we create a custom source plugin extending the CSV plugin provided by the Migrate Source CSV module, which will download CSV files from a remote server and pass it to the CSV plugin to process them.

    The Source Migrate Plugin

    To start, let's create a custom module and call it migrate_example_source and implement a custom migrate source plugin by creating a PHP class inside it at /src/Plugin/migrate/source/MigrateExampleSourceRemoteCSV.php

    We start implementing the class by simply extending the CSV plugin provided by the migrate_source_csv module: namespace Drupal\migrate_source_csv\Plugin\migrate\source; use Drupal\migrate_source_csv\Plugin\migrate\source\CSV as SourceCSV; use phpseclib\Net\SFTP /** * @MigrateSource( * id = "migrate_example_source_remote_csv" * ) */ class MigrateExampleSourceRemoteCSV extends SourceCSV {}

    Adding the annotation @MigrateSource is very important because that is what will make the migrate module detect our source plugin. In our plugin, we use the phpseclib/phpseclib libraries to make SFTP connections. Hence, we need to include the libraries in our project by running the following command in the Drupal root:

    composer require phpseclib/phpseclib

    Our plugin will download the source CSV file and will simply pass it to the CSV plugin to do the rest. We do the download when the plugin is being instantiated like this:

    /** * {@inheritdoc} */ public function __construct(array $configuration, $plugin_id, $plugin_definition, MigrationInterface $migration) { // If SFTP connection parameters are present. if (!empty($configuration['sftp'])) { // A settings key must be specified. // We use the settings key to get SFTP configuration from $settings. if (!isset($configuration['sftp']['settings'])) { throw new MigrateException('Parameter "sftp/settings" not defined for Remote CSV source plugin.'); } // Merge plugin settings with global settings. $configuration['sftp'] += Settings::get('sftp', []); // We simply download the remote CSV file to a temporary path and set // the temporary path to the parent CSV plugin. $configuration['path'] = $this->downloadFile($configuration['sftp']); } // Having downloaded the remote CSV, we simply pass the call to the parent plugin. parent::__construct($configuration, $plugin_id, $plugin_definition, $migration); }

    In the constructor we are using global SFTP credentials with Settings::get(). We need to define the credentials in settings.php like this:

    $settings['sftp'] = array( 'default' => [ 'server' => 'ftp.example.com', 'username' => 'username', 'password' => 'password', 'port' => '22', ], );

    Once we have the credentials of the FTP server we use a downloadFile() method to download the remote CSV file. Here's an extract of the relevant code:

    protected function downloadFile(array $conn_config) { ... // Prepare to download file to a temporary directory. $path_remote = $conn_config['path']; $basename = basename($path_remote); $path_local = file_directory_temp() . '/' . $basename; ... // Download file by SFTP and place it in temporary directory. $sftp = static::getSFTPConnection($conn_config); if (!$sftp->get($path_remote, $path_local)) { throw new MigrateException('Cannot download remote file ' . $basename . ' by SFTP.'); } ... // Return path to the local of the file. // This will in turn be passed to the parent CSV plugin. return $path_local; }

    Note: The code block above has been simplified a bit. If you see the actual source plugin, there are some lines of code which make things more compatible with the migration_lookup plugin.

    This method creates an SFTP connection, downloads the file to a temporary location and returns the path to the downloaded file. The temporary file path is then passed to the Migrate Source CSV and that's it! Finally, to use the plugin in our migration we just set our plugin as the source/plugin:

    id: migrate_example_content label: 'Example content' ... source: plugin: migrate_example_source_remote_csv # Settings for our custom Remote CSV plugin. sftp: settings: sftp path: "/path/to/file/example_content.csv" # Settings for the contrib CSV plugin. header_row_count: 1 keys: - id ...

    The code for this plugin and the example module is available at migrate_example_source. Great!

    + more awesome articles by Evolving Web

    Electric Citizen: Essential SEO Tune-Up for your Drupal 8 Website

    18. Dezember 2017 - 17:49

    Drupal is well known for being a Search Engine Optimization (SEO) friendly Content Management System (CMS) and Drupal 8, the latest version, is the best by far. Many of the essential requirements for SEO best practices are already baked into the core software architecture, and with a little knowledge and some basic configuration anyone can tune up their website to become faster, drive more traffic, and perform better in the search engine rankings.

    Promet Source: Promet Source Announces Partnership with Drupal Open Y

    18. Dezember 2017 - 17:39
    Promet Source is proud to announce that we have teamed up with OpenYMCA.org, an open-source digital platform for marketing and e-commerce, as a Drupal development partner. Through this partnership, we are committed to the Open Y philosophy, community, and platform.

    OSTraining: Embed a Youtube Player as Media Asset Into CKEditor in Drupal 8

    18. Dezember 2017 - 16:19

    The new Media capabilities in Drupal allow you create a media library with all kinds of media assets and use these assets everywhere. One way to use them is to embed these assets directly into CKEditor.

    You can pull these assets from Youtube or Vimeo with the Video Embed Field module, so you only need to store the URL on your Drupal site.This will come in handy for a lot of site editors. Let’s start!

    Dcycle: Migrating Webforms from Drupal 7 to Drupal 8

    18. Dezember 2017 - 2:00

    I recently needed to port hundreds of Drupal 7 webforms with thousands of submissions from Drupal 7 to Drupal 8.

    My requirements were:

    • Node ids need to remain the same
    • Webforms need to be treated as data: they should be ignored by config export and import, just like nodes and taxonomy terms are. The reasonining is that in my setup, forms are managed by site editors, not developers. (This is not related to migration per se, but was a success criteria for my migration so I’ll document my solution here)
    Migration from Drupal 7

    I could not find a reliable upgrade or migration path from Drupal 7 to Drupal 8. I found webform_migrate lacks documentation (I don’t know where to start) and migrate_webform is meant for Drupal 6, not Drupal 7 as a source.

    I settled on a my own combination of tools and workflows to perform the migration, all of them available on my Github account.

    Using version 8.x-5.x of webform, I started by enabling webform, webform_node and webform_ui on my Drupal 8 site, this gives me an empty webform node type.

    I then followed the instructions for a basic migration, which is outside the scope of this article. I have a project on Githubwhich I use as starting point from my Drpual 6 and 7 to 8 migrations. The blog post Custom Drupal-to-Drupal Migrations with Migrate Tools, Drupalize.me, April 26, 2016 by William Hetherington provides more information on performing a basic migration of data.

    Once you have set up your migration configurations as per those instructions, you should be able to run:

    drush migrate-import upgrade_d7_node_webform --execute-dependencies

    And you should see something like:

    Processed 25 items (25 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_node_type' Processed 11 items (11 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_user_role' Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_user_role' Processed 95 items (95 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_user' Processed 109 items (109 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_node_webform'

    At this point I had all my webforms as nodes with the same node ids on Drupal 7 and Drupal 8, however this does nothing to import the actual forms or submissions.

    Importing the data itself

    I found that the most efficient way of importing the data was to create my own Drupal 8 module, which I have published on Dcycle’s Github account, called webform_d7_to_d8. (I have decided against publishing this on Drupal.org because I don’t plan on maintaining it long-term, and I don’t have the resources to combine efforts with existing webform migration modules.)

    I did my best to make that module self-explanatory, so you should be able to follow the steps the README file, which I will summarize here:

    Start by giving your Drupal 8 site access to your Drupal 7 database:

    $databases['upgrade']['default'] = array ( 'database' => 'drupal7database', 'username' => 'drupal7user', 'password' => 'drupal7password', 'prefix' => '', 'host' => 'drupal7host', 'port' => '3306', 'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql', 'driver' => 'mysql', );

    Run the migration with our without options:

    drush ev 'webform_d7_to_d8()'

    or

    drush ev 'webform_d7_to_d8(["nid" => 123])'

    or

    drush ev 'webform_d7_to_d8(["simulate" => TRUE])'

    More detailed information can be found in the modlue’s README file.

    Treating webforms as data

    Once you have imported your webforms to Drupal 8, they are treated as configuration, that is, the Webform module assumes that developers, not site builders, will be creating the forms. This may be fine in many cases, however my usecase is that site editors want to create and edit forms directly on the production, and we don’t want them to be tracked by the configuration management system.

    Jacob Rockowitz pointed me in the right direction for making sure webforms are not treated as configuration. For that purpose I am using Drush CMI tools by Previous Next and documented on their blog post, Introducing Drush CMI tools, 24 Aug. 2016.

    Once you install in your ~/.drush folder and run drush cc drush, you can use druch cexy and druch cimy and instead of drush cim and drush cex in your conguration management process. Here is how and why:

    Normally, if you develop your site locally and, say, add a content type or field, or remove a content type of field, you can run drush cex to export your newly created configuration. Then, your colleagues can pull your code and run drush cim to pull your configuration. drush cim can also be used in continuous integration, preproduction, dev, and production environments.

    The problem is that drush cex exports all configuration, and drush cim deletes everything in the database which is not in configuration. In our case, we don’t want to consider webforms as configuration but as data, just as nodes as taxonomy terms: we don’t want them to be exported along with other configuration; and if they exist on a target environment we want to leave them as they are.

    Using Drush CMI tools, you can add a file such as the following to ~/.drush/config-ignore.yml:

    # See http://blog.dcycle.com/blog/2017-12-18 ignore: - webform.webform.*

    This has to be done on all developers’ machines or, if you use Docker, on a shared Docker container (which is outside the scope of this article).

    Now, for exporting configuration, run:

    drush cexy --destination='/path/to/config/folder'

    Now, webforms will not be exported along with other configuration.

    We also need to avoid erasing webforms on target environments: if you create a webform on a target environment, then run drush cim, you will see something like:

    webform.webform.webform_9521 delete webform.webform.webform_8996 delete webform.webform.webform_8991 delete webform.webform.webform_8986 delete

    So, we need to avoid deleting webforms on the target environment when we import configuration. We could just do drush cim --partial but this avoids deleting everything, not just webforms.

    Drush CMI tools provides an alternative:

    drush cimy --source=/path/to/config/folder

    This works much like drush cim --partial, but it allows you to specify another parameter, –delete-list=/path/to/config-delete.yml

    Then, in config-delete.yml, you can specify items that you actually want to delete on the target environment, for example content types, fields, and views which do not exist in code. This is dependent on your workflow and they way to set it up isdocumented on the Drush CMI tools project homepage.

    With this in place, we’ll have our Drupal 7 webforms on our Drupal 8 site.

    I recently needed to port hundreds of Drupal 7 webforms with thousands of submissions from Drupal 7 to Drupal 8.

    Sooper Drupal Themes: Try The SooperThemes Drupal 8 Experience With Our First Beta Release. Refinements for D7, One more thing..

    16. Dezember 2017 - 20:02
    Drupal 8 Products Now Feature-Complete with New Media Library

    A few months ago we released our first Alpha release on Drupal 8. Now we have full support for image re-usability thanks to the Entity Browser module and are ready to release our first beta! The beta hits feature-parity with the Drupal 7 products so you can start upgrading your websites if you're willing to be an early adopter. Download the beta here to test our Drupal themes and Drupal Drag and Drop builder:

    Drupal 8 Beta Download

    The result of our work with Entity Browser is a slick interface to search and select images. It's really a step up from Drupal 7's Media Browser. Entity Browser is becoming the standard for media management in Drupal 8 and we've made some contributions and customizations to get the interface up to our design standards. Here's a little demo video:

    Shooting For Early January Release Of All Drupal 8 Themes And Modules It's going to be a hell of  a lot of work to get all 15 demos running on our Drupal 8 framework. The demos use different (probably some untested) features and additional contrib modules on top of what the main demo uses. This means there's not just the work of migrating and testing hundreds of content items but also different interactions between Glazed Builder and several modules. We're aiming for an early January release but can't make a hard guarantee. However, since the beta releases will be backwards compatible you can already start building our Drupal 8 projects if you're with being a beta tester and you don't need the demos that are yet to be ported.  Refinements and Minor Bug Fixes: Patch Release On D7 Products

    We've been cleaning out out some minor bugs for Glazed Theme and Glazed Builder, trying to get the bug counter to zero before we release on Drupal 8. You can check the release notes for a full report but here's the management summary:

    Glazed theme:
    • Added support for Navbar module (backport from D8 navbar)
    • Fixed issue with page titles hidden between page title background image
    • Fixed issue with secondary header region expanding when sticky footer option is enabled
    • Fixed issue of body scrolling while swiping mobile menu backdrop
    • Updated all colors to reflect 2018 Glazed branding
    Glazed Builder
    • Fixed layout bug for websites using non-bootstrap theme with Glazed Builder
    • Updated design of image selection widget
    • Fixed issue with color picker
    • Added category selection to icons widget
    • Made icon search much faster (dropped jQuery ui from widget)
    • Fixed bug with Carousel element prev/next pager in Bottom-Left position
    • Updated all colors to reflect 2018 Glazed branding
    Something Extra For The Holidays:

    Something else was released this month that we're very excited about.. after many years of using Font Awesome 4 we now finally have Font Awesome 5 Pro! Because SooperThemes is a backer of this million dollar Kickstarter project we can now provide you with the Pro version of this enormous icon kit. Font Awesome 4 is not going anywhere, and will continue to exist along with Font Awesome 5 solid, light, and regular stroke icons.

    On top of that we also added the 900-icon Google Material Design icon kit! We thought it would be a nice contrasting option compared to the more round lines of Font Awesome. Material Icons are more tightly drawn and perhaps more suited if you're going for a stark, hard-edged look.

    We're super excited for everyone who's been waiting and emailing us about our Drupal 8 products, we're now confident you can start your Glazed project if your project's release is scheduled for january/february! If you're just curious you can spin up our Drupal 7 admin demo here: http://trysooperthemes.com/. To try our Drupal 8 beta release you'll have to sign up. Subscriptions start at just $78 USD and are guaranteed by our 20 day refund period.

    Join SooperThemes To Get Full Access

    Happy holidays! If you've got sales questions about our Drupal 8 products feel free to email us or drop a comment here. For feedback from testing the beta please use the feedback thread in our support forum.

    MTech, LLC: Migrate (almost) goes stable in Core

    15. Dezember 2017 - 16:06
    Migrate (almost) goes stable in Core

    For those following along from the sidelines, Drupal 8 core has 3 modules that make up the migrate sub-system. For the past few years, the community has been working very hard to get these to a stable state an out of their "experimental" designation. Drum role please... as very soon the first of these modules is going to do just that. Go stable. The migrate module (also known as the API module) should have its last critical release blocker committed in the next few days. At which point, this module can be called stable.

    Admin User Fri, 12/15/2017 - 08:06

    Agiledrop.com Blog: AGILEDROP: What makes Drupal SEO friendly

    15. Dezember 2017 - 13:51
    To achieve the highest ranking in the search engine, the website has to be SEO friendly. Google SERP (Search Engine Results Page) has one of the most important roles growing businesses with the help of a website. Drupal is a very powerful system that ensures search website optimization with its modules. It gives us the ability to control all the elements of the web pages with the help of already installed automation tools for SEO, which places it at the very top of SEO friendly CMSs. Let's look at some examples.   SEO-friendly URLs Because search engines search for keywords in URLs, they… READ MORE

    Amazee Labs: Estimations - Amazee Agile Agency Survey Results - Part 7

    15. Dezember 2017 - 12:46
    Estimations - Amazee Agile Agency Survey Results - Part 7

    This is part 7 of our series processing the results of the Amazee Agile Agency Survey. Previously I wrote about defining work, this time let’s focus on estimations. How do you estimate and who does estimations in your teams?

    Josef Dabernig Fri, 12/15/2017 - 11:46

    First, we asked about how teams estimate. 43.3% of the contestants answered “Estimation is done in days/hours”, 20% say “Estimation is done in story points based on complexity” and 16.7% mentioned, “Estimations in done in story points based on effort”. The remaining answers of 3% each varied in different degrees of combined estimations, i.e. teams would estimate on a higher level using story points and compare then against hour based task estimations. Also one of the 30 contestants answered that they don’t do estimates at all. For some background information, you can refer to this article on story points.

    At Amazee we do two different kinds of estimations. We estimate in days for the offers that we create and put a general price tag below the contract. This is intended to fix a budget but not to guarantee an exact feature set to be delivered. When we go to the implementation phase, teams estimate Jira tickets using story points. The story points are based both on complexity and effort, based on our velocity we can related story points to a price tag and compare against the initial offer and how much budget is left.

    We also asked about who is involved in estimation. 50% say that “the entire team does all estimations”, 36.7% mentioned that “a tech lead does high-level estimates, the team estimates on a lower level”. 6.7% say that “a tech lead does all estimates”.

    For us, at Amazee we tend towards having a tech lead doing high-level estimates and having the team estimate on individual stories and tasks which get prepared for a sprint to work. The tech lead role can be fulfilled by any developer of a Scrum team and may change however the team and the team lead decide it would work best. More complex offers get challenged by multiple developers, more straightforward suggestions will be estimated by only one developer together with the PO. All proposals get reviewed by management. When the team does estimations, we do them along with the entire Scrum team. In some instances, we will limit the number of people in estimation meetings to find a balance between shared knowledge and how much time can be spent discussing as a group of people.

    How do you estimate? Please leave us a comment below. If you are interested in Agile Scrum training, don’t hesitate to contact us.

    Stay tuned for the next post where we’ll look at client interactions.

    Chromatic: Announcing a New Decoupled Drupal Project: FamilyCircle.com

    14. Dezember 2017 - 23:36

    FamilyCircle.com provides expert advice about teens, family, food, style and home life, from the editors of Family Circle Magazine. When the time came to design and deploy a headless Drupal/Node.js platform, Meredith Corporation called on Chromatic’s expertise to help lead the way.

    WeKnow: Managing a Distributed Team

    14. Dezember 2017 - 22:20
    Managing a Distributed Team

    weKnow is a fully distributed company, something we proclaim loudly and proudly to our partners and potential clients when engaging with them. It’s a characteristic that gives us the competitive edge because it highlights weKnow’s core values and the character of every individual that works at here.

    I decided to write this because our clients are always amazed by how seamless our operations and projects run. They always seem amazed by the fact that we span 12 countries and cover 6 time zones, yet seamlessly integrate into their projects from kickoff to completion without a hitch. This is how we keep things running smooth…

    kabarca Thu, 12/14/2017 - 20:20

    DrupalBASE: The information itself is useless

    14. Dezember 2017 - 20:58

    The information itself is useless.

    Quite original start for a web-published text, isn't it? Still the confirmation is true. Solutions don't demand information, solutions demand clearly organized data. No matter what is the domain – in every situation people tend to organize data in a readable well-understandable formats.

    Multiple mechanisms of collecting and storing the data are developed, and technologies continue to progress. But the key question of data presentation often remains ignored.

    WeKnow: How we approached building the new weKnow site

    14. Dezember 2017 - 20:39
    How we approached building the new weKnow site

    It’s been a little over a year since weKnow came to life as a rebranding for Anexus, which allowed me to join the company as a new business partner. My main goal within the company is directing our efforts to explore new fields and technologies (that’s right, we are not just a Drupal shop anymore!)

    As a web solution provider, having a website that accurately reflects what we do is a challenging task, because usually our plate is full with client work, and it’s not uncommon to put your own website at the end of the queue. This is why last year we decided to put together a basic landing page while setting aside some time to work on the company image as part of the rebranding.

    jmolivas Thu, 12/14/2017 - 18:39

    Promet Source: Implementing ADA Section 508 for Local Government: A Developer's Journey to Web Accessibility

    14. Dezember 2017 - 16:15
    My name is Katherine Shaw and I am a front end web developer at Promet Source. I'd like to start by sharing a little bit of my background, as it has helped me to understand why accessibility, on the web and in the world around us, is such an important issue. I am an advocate for web accessibility and in today's blog, I'll be share how I became so passionate about implementing ADA Section 508 best practices into my work as a developer, which all began when I was working for local government.

    Electric Citizen: Twig for Drupal 8 Development: Twig Templating Part 2 of 2

    14. Dezember 2017 - 15:12

    In the recent post Twig for Drupal 8 Development: Twig Templating Part 1, we covered some Drupal Twig templating basics like debugging, custom templates, inheritance, variables, filters, attributes, and macros. This post will cover more advanced topics. You will learn about preprocessing variables, expanding the available templates with theme suggestion, Drupal 8 Views and Twig, and the Twig Tweak module.

    Tim Millwood: Drupal Service ID Collectors

    14. Dezember 2017 - 11:29
    Drupal Service ID Collectors

    Since Drupal 8 we've had services. This also brought the concept of a service collector or tagged services. This allows services to be tagged with a specific tag, then a service collector can collect all services with the a given tag and use whichever service "applies".

    As you could imagine loaded all of these tagged services when loading the service collector service can be a performance nightmare, which is why Drupal 8.4.0 brought us service ID collector functionality.

    Tagging a service with the service_id_collector tag will pass all services with a given tag as the last parameter in the constructor. This will be an array of service IDs ordered by the priority. You will then need to use the ClassResolver service to lazily instantiate the collected service IDs.

    my_module.services.yml
    my_module.negotiator:
      class: \Drupal\my_module\MyModuleNegotiator
      arguments: {'@class.resolver'}
      tags:
        - { name: service_id_collector, tag: my_module_negotiator }
    my_module.negotiator.foo:
      class:\Drupal\my_module\FooNegotiator
      arguments: {'@entity_type.manager'}
      tags:
        - { name: my_module_negotiator, priority: 100 }
    my_module.negotiator.bar:
      class:\Drupal\my_module\BarNegotiator
      arguments: {'@entity_type.manager'}
      tags:
        - { name: my_module_negotiator, priority: -100 }
    my_module.negotiator.baz:
      class:\Drupal\my_module\BazNegotiator
      arguments: {'@entity_type.manager'}
      tags:
        - { name: my_module_negotiator, priority: 0 }

    MyModuleNegotiator.php
    /**
     * The negotiator for my module.
     */
    class MyModuleNegotiator {

      /**
       * The class resolver service.
       *
       * @var \Drupal\Core\DependencyInjection\ClassResolver
       */
      protected $classResolver;

      /**
       * The negotiator service IDs.
       *
       * @var array
       */
      protected $negotiatorServiceIds;
     

      /**
       * Constructs the negotiator.
       *
       * @param \Drupal\Core\DependencyInjection\ClassResolver $class_resolver
       *   The class resolver service.
       * @param array $negotiator_service_ids
       *   The negotiator service IDs.
       */
      public function __construct(ClassResolverInterface $class_resolver, array $negotiator_service_ids) {
        $this->classResolver = $class_resolver;
        $this->negotiatorServiceIds = $negotiator_service_ids;
      }
     

      /**
       * Run the negotiators.
       */
      public function runNegotiators() {
        foreach ($this->negotiatorServiceIds as $negotiator_service_id) {
          $negotiator = $this->classResolver->getInstanceFromDefinition($negotiator_service_id);
          if ($negotiator->applies()) {
            $negotiator->run();
          }
        }
      }
    }

    timmillwood Thu, 14/12/2017 - 09:29 Tags drupal planet drupal-planet drupal8 Add new comment

    myDropWizard.com: CiviCRM secrets for Drupalers: Email Campaigns

    14. Dezember 2017 - 4:14

    We're Drupalers who only recently started digging deep into CiviCRM and we're finding some really cool things! This series of videos is meant to share those secrets with other Drupalers, in case they come across a project that could use them. :-)

    Most Drupalers at one time have had to deal with either sending e-mail newsletters directly from Drupal, or integrating with a 3rd party tool like Mailchimp or Constant Contact.

    CiviCRM has built in e-mail newsletter functionality, and if you add to it the WYSIWYG e-mail builder Mosaico you can build really rich, responsive e-mail campaigns!

    Watch the video here:

    Video of CiviCRM secrets for Drupalers #1: E-mail Campaigns

    Some highlights from the video:

    • A sneak peek at Round Earth: our project that bundles Drupal 8 + CiviCRM
    • Drupal 8 + CiviCRM vs. "only" Drupal
    • A quick walk-through on how to quickly and easily create an email campaign
    • Plus, we mention a couple of current "gotchas" that could save you frustration!

    Please leave a comment below!

    FFW Agency: The ABC's of Drupal: Region, Revision, Role

    14. Dezember 2017 - 2:03
    The ABC's of Drupal: Region, Revision, Role Ray Saltini Thu, 12/14/2017 - 00:03

    For anyone who's ever looked up a definition of a Drupal term and still wondered what it means, here are some practical explanations you can use to navigate the Drupal-verse. This is the latest in a series on Drupal-specific terminology.

    Region

    Regions divide Drupal pages into different sections. Each section contains information that determines the positions of various elements. These elements can include menus, headers, footers, and sidebars. The elements in each Region are called Blocks. (For more information on Blocks, see Aliases, Blocks, and Content Types.)

    A Drupal site's active theme keeps information on the number, name, and location of each Region. Different themes can have different Regions. Typically, administrative themes have fewer regions spaced in wide columns across a page. The themes that face a site's end-users often have more complex layouts, which means more Regions. (To learn more about Themes, see Article, Base Theme, Content.

     

    Together, Blocks and Regions make up Drupal's core's primary layout functionality. This combination is a simple yet powerful solution that has been steadily expanded with each major version of Drupal. 

    As a note: Drupal Regions can be overridden by contributed modules such as Panels. Regions can also be overridden by custom page templates that apply to specific URLs or URL alias patterns. While the use of Panels can increase overhead and complexity, it makes additional layouts and landing page capabilities available to site builders. Layouts made with Panels are saved in the site's database, which mitigates the risk of rolling custom code by editing a site's theme files.

    Revision

    A Drupal Revision is a saved version of a set of changes to a piece of Drupal content created with a Content Entity. Revisions apply to any piece of content on a site, including Articles, Basic Pages, and custom content types.

    After a piece of content is created, any changes or updates made to the content are saved in new versions, or Revisions. Drupal does this rather than editing an existing published version. These versions are stored indefinitely each time a set of changes is saved, and can be found on a content item's administrative interface. Users can save revisions in unpublished draft form, to be published at a later date. Previous versions can also be republished, which allows content authors to revert content to an earlier state.

    Drupal's core revision feature supports a powerful workflow functionality that can be custom-configured to align with an organization's processes for content approval. Revision functionality can also be extended with the contributed Diff module to highlight changes between various drafts.

    Role

    Roles assign various permissions to a Drupal site's users. This includes the ability to edit and manage content and configure settings. Roles are typically grouped into sets of permissions that are determined by a user's expertise in the organization. A Role is a user-defined set of permissions that can be granted to groups of individuals. Typical Drupal user roles include Administrator (preconfigured), Content Creator, and Content Manager.

    Anonymous and Authenticated are two special preconfigured user states that are accessed through the user administrative pages. Anonymous users are typically granted only the most basic permissions. By definition, Authenticated users are those that are known to the system. Authenticated users have an account and unique email address that associated with a cookie that resides locally in their browser.

    When new functionality is added to Drupal, additional permissions are typically added to the system. These permissions can then be assigned to new or existing roles.

    What Next?

    If you've got questions about specific Drupal terms, let us know. Drop a request for a definition in the comments and we'll add it to our next ABCs of Drupal post. 

    Comments