Planet Drupal

Subscribe to flux Planet Drupal
Drupal.org - aggregated feeds in category Planet Drupal
Mis à jour : il y a 40 min 55 sec

Roy Scholten: UX meeting recap

mar, 23/08/2016 - 23:58

Two meetings every week since end of march this year. Safe to say we’ve found a consistent rhythm.

And it’s working. It’s become a useful way to check in on current priorities, review patches while screensharing (visuals, transitions, flows!), decide on next steps and generally discuss hard problems without having to type so much.

The agenda for today was
  1. Roadmap – The core roadmap was updated to current state of things. Use this page to get a bird’s eye view on where Drupal core is moving towards.
  2. Ideation process – The first part of going from idea to plan got positive feedback and helpful questions and suggestions. Maybe a few words from actual maintainers and then we can make it so.
  3. Status page – We have a beautiful new design that now needs review and more code to create a complete patch. If you know your core markup and CSS, go have a look!
  4. Block place design update – An issue that iterates the design of an initial commit. We quickly discussed what the feedback should be and I added a comment to that effect right then and there. It’s an example of managing scope, pushing to focus on the actual fix first, and defer new, potentially good ideas to a followup discussion.
  5. Sample content – Kevin shared his initial thoughts and ideas for adding sample content, structure and configuration to core. More questions then answers but that’s just where we’re at for now. You are welcome to add your questions and ideas, please do.

As always, most welcome to join if you’re interested. Find us in the ux channel of the Drupal Slack room, or follow @drupalux on the twitters.

Tags: drupaluxuxmeetingdrupalplanetSub title: Topics du jour, how we work, where you can help, the usual
Catégories: Elsewhere

Drupal Blog: Drupal 8.2, now with more outside-in

mar, 23/08/2016 - 21:14

Over the weekend, Drupal 8.2 beta was released. One of the reasons why I'm so excited about this release is that it ships with "more outside-in". In an "outside-in experience", you can click anything on the page, edit its configuration in place without having to navigate to the administration back end, and watch it take effect immediately. This kind of on-the-fly editorial experience could be a game changer for Drupal's usability.

When I last discussed turning Drupal outside-in, we were still in the conceptual stages, with mockups illustrating the concepts. Since then, those designs have gone through multiple rounds of feedback from Drupal's usability team and a round of user testing led by Cheppers. This study identified some issues and provided some insights which were incorporated into subsequent designs.

Two policy changes we introduced in Drupal 8—semantic versioning and experimental modules—have fundamentally changed Drupal's innovation model starting with Drupal 8. I should write a longer blog post about this, but the net result of those two changes is ongoing improvements with an easy upgrade path. In this case, it enabled us to add outside-in experiences to Drupal 8.2 instead of having to wait for Drupal 9. The authoring experience improvements we made in Drupal 8 are well-received, but that doesn't mean we are done. It's exciting that we can move much faster on making Drupal easier to use.

In-place block configuration

As you can see from the image below, Drupal 8.2 adds the ability to trigger "Edit" mode, which currently highlights all blocks on the page. Clicking on one — in this case, the block with the site's name — pops out a new tray or sidebar. A content creator can change the site name directly from the tray, without having to navigate through Drupal's administrative interface to theme settings as they would have to in Drupal 7 and Drupal 8.1.

Making adjustments to menus

In the second image, the pattern is applied to a menu block. You can make adjustments to the menu right from the new tray instead of having to navigate to the back end. Here the content creator changes the order of the menu links (moving "About us" after "Contact") and toggles the "Team" menu item from hidden to visible.

In-context block placement

In Drupal 8.1 and prior, placing a new block on the page required navigating away from your front end into the administrative back end and noting the available regions. Once you discover where to go to add a block, which can in itself be a challenge, you'll have to learn about the different regions, and some trial and error might be required to place a block exactly where you want it to go.

Starting in Drupal 8.2, content creators can now just click "Place block" without navigating to a different page and knowing about available regions ahead of time. Clicking "Place block" will highlight the different possible locations for a block to be placed in.

Next steps

These improvements are currently tagged "experimental". This means that anyone who downloads Drupal 8.2 can test these changes and provide feedback. It also means that we aren't quite satisfied with these changes yet and that you should expect to see this functionality improve between now and 8.2.0's release, and even after the Drupal 8.2.0 release.

As you probably noticed, things still look pretty raw in places; as an example, the forms in the tray are exposing too many visual details. There is more work to do to bring this functionality to the level of the designs. We're focused on improving that, as well as the underlying architecture and accessibility. Once we feel good about how it all works and looks, we'll remove the experimental label.

We deliberately postponed most of the design work to focus on introducing the fundamental concepts and patterns. That was an important first step. We wanted to enable Drupal developers to start experimenting with the outside-in pattern in Drupal 8.2. As part of that, we'll have to determine how this new pattern will apply broadly to Drupal core and the many contributed modules that would leverage it. Our hope is that once the outside-in work is stable and no longer experimental, it will trickle down to every Drupal module. At that point we can all work together, in parallel, on making Drupal much easier to use.

Users have proven time and again in usability studies to be extremely "preview-driven", so the ability to make quick configuration changes right from their front end, without becoming an expert in Drupal's information architecture, could be revolutionary for Drupal.

If you'd like to help get these features to stable release faster, please join us in the outside-in roadmap issue.

Thank you

I'd also like to thank everyone who contributed to these features and reviewed them, including Bojhanyoroypwolaninandrewmacphersongtamaspetycompzsofimajor,SKAUGHTnod_effulgentsiaWim Leerscatchalexpott, and xjm.

And finally, a special thank you to Acquia's outside-in team for driving most of the design and implementation: tkolearywebchicktedbowGábor Hojtsytim.plunkett, and drpal.

Acquia's outside-in team celebrating that the outside-in patch was committed to Drupal 8.2 beta. Go team!

Catégories: Elsewhere

myDropWizard.com: Survey Results From "Is Drupal Hard?"

mar, 23/08/2016 - 14:51

A few weeks ago, we had A Survey! Is Drupal Hard?

First of all, thank you for taking the time to answer (even though we had a short-lived technical snafu!). At myDropWizard, we believe in transparency and openness, so I'm going to share the unfiltered data with you - as well as what my thoughts are in interpreting this non-scientific study.

The Data

Some Issues

  1. Many of those answering would be biased towards Drupal
  2. The choices were somewhat arbitrary, and no doubt some were left out
  3. There was an initial bug in the survey keeping some good data out
  4. The choice "It's about what I would expect" is probably better labeled as something more along the lines of "an average web developer should be able to accomplish their needs in a reasonable amount of time"
Analysis

So, there were plenty of flaws in the data, but that won't keep me from drawing a few conclusions - and I'm anxious to hear what others feel as well.

Drupal 7 Still a Favorite

"0" respondents claimed it "impossible" to do complex things while coupled with the lowest number of "Never Used It / No Opinion" at 5.

Catégories: Elsewhere

Nuvole: Maintain local development configuration with Configuration Split

mar, 23/08/2016 - 14:21
Answering the most commonly asked question about Configuration Management in Drupal 8; and a preview of our DrupalCon training.

This post is an excerpt from the topics covered by our DrupalCon Dublin training: Drupal 8 Development - Workflows and Tools.

For the last two years we have been giving trainings and presentations at various Drupal events about configuration management and its new workflows in Drupal 8. One of the recurring questions has been:

How do I keep some configuration from being deployed? For example the devel module and its configuration?

Until now we have answered to use drush with the --skip-modules flag and then to gitignore the configuration for devel. But then you can't share the development configuration and the process is error prone when there are more modules and other configuration items that depend on the configuration you gitignore.

For some simpler cases where configuration needs to be different between environments (for example the error verbosity) the configuration override system allows to override the configuration in settings.php. This is a solution for some cases, however, you can not override which modules are enabled or override configuration that doesn't exist.

Enter: Configuration split!

Our new module Configuration split splits the configuration when exporting it with a special Drupal Console command. It can be configured to split out enabled modules and given blacklisted configuration and it will then separate all the configuration that is dependent on the listed modules or configuration. The module's settings also allow to set a folder to which the separated configuration will be exported to.

That way the configuration set which you use to deploy configuration between different environments is a subset of your development configuration and the trusty configuration system of Drupal 8 can be used unharmed. Of course when importing with the special command the split configuration is merged back, allowing you to keep your development configuration in place.

"To split" is a synonym for "to break" and as such "Configuration split" has a dangerous ring to it. This is on purpose because the exported subset is on purpose not what you have on your development site and not what you have locally tested. So you need to compensate that with a workflow that imports and verifies the configuration you are going to deploy. This is better than to import and export individual configuration because Drupal needs the whole set of configuration to do its checks.

How do I use it?

Download and enable the Configuration split module like any other module. Then configure it under admin/config/development/configuration/config_split. Set the split folder to a different folder than your normal config sync folder. If you want a prettier interface, consider using Chosen. Then use the Drupal Console command config_split:export and config_split:import to export and import respectively.

Let's look at the devel example from above. We typically version the configuration outside of the webroot in ../config/sync as seen by Drupal. (In the project root when starting a project with drupal-composer/drupal-project.) So the folder we specify for config_split would be ../config/dev. The module to filter would be Devel and the rest can be left empty. The devel.settings will be detected automatically. Note though that the system.menu.devel does not depend on the devel module and can not be detected automatically, but it is easy to add it to the blacklisted config and it could theoretically be deployed without breaking anything.

The config_split.settings.yml could look something like this:

folder: ../config/dev
module:
  devel: 0
theme: {  }
blacklist:
  - system.menu.devel

Finally the following command will export the configuration to the default sync directory without the devel module enabled and export the devel configuration into the dev directory.
web$ ../vendor/bin/drupal config_split:export

Now if you would import the configuration through the UI or with drush cim the devel module would be un-installed, and you can do that to see the site without its development configuration. However, If you want the development configuration to stay or become active and the devel module installed use the following command:
web$ ../vendor/bin/drupal config_split:import

How does it work internally?

We implemented a StorageWrapper that allows filters to interact with the configuration after it has been read and before it is written to the wrapped FileStorage during the import and export operation. The SplitFilter has a secondary storage and decides where to read from or write to. This is a very similar concept to what drush does with its --skip-modules flag since we will want to easily integrate this with drush in the future.

What comes next?

The module is still in an early development stage and some more additions in the scope of splitting configuration could be added. The subset without the split configuration could be verified after exporting it and we could warn the user if it couldn't be imported. Or for example we currently use only config_split.settings but if the need arises we could support multiple split configurations. Or we could add a "gray list" to ignore some configuration that exists rather than removing it when splitting, essentially making it a configuration override outside of the scope of Drupal's runtime. This could be useful when maintaining several sites that are almost the same but all have their little "special snowflake" configuration which in turn could be synchronized with the normal workflow.

It is important to understand that the configuration system of Drupal has limitations that are there for a good reason. Most of them are to ensure data integrity and robustness and reliability of the synchronisation and so on. In other words measures to protect you from accidentally breaking your site. Using tools like config_split or drush --skip-modules you circumvent some of these security and integrity checks so use them with caution.

Since the module is not required for the regular functioning of a Drupal 8 site (it can even be used to blacklist itself) it can already be used in the development process of your current projects already. Your feedback is welcome, see you in the issue queue.

Tags: Drupal PlanetDrupal 8DrupalConTrainingCode Driven Development
Catégories: Elsewhere

Rakesh's DSoC 16 blog: GSoC Final Submission

mar, 23/08/2016 - 10:59
GSoC Final Submission rakesh Tue, 08/23/2016 - 14:29
Catégories: Elsewhere

Dries Buytaert: Drupal 8.2, now with more outside-in

mar, 23/08/2016 - 09:10

Over the weekend, Drupal 8.2 beta was released. One of the reasons why I'm so excited about this release is that it ships with "more outside-in". In an "outside-in experience", you can click anything on the page, edit its configuration in place without having to navigate to the administration back end, and watch it take effect immediately. This kind of on-the-fly editorial experience could be a game changer for Drupal's usability.

When I last discussed turning Drupal outside-in, we were still in the conceptual stages, with mockups illustrating the concepts. Since then, those designs have gone through multiple rounds of feedback from Drupal's usability team and a round of user testing led by Cheppers. This study identified some issues and provided some insights which were incorporated into subsequent designs.

Two policy changes we introduced in Drupal 8 — semantic versioning and experimental modules — have fundamentally changed Drupal's innovation model starting with Drupal 8. I should write a longer blog post about this, but the net result of those two changes is ongoing improvements with an easy upgrade path. In this case, it enabled us to add outside-in experiences to Drupal 8.2 instead of having to wait for Drupal 9. The authoring experience improvements we made in Drupal 8 are well-received, but that doesn't mean we are done. It's exciting that we can move much faster on making Drupal easier to use.

In-place block configuration

As you can see from the image below, Drupal 8.2 adds the ability to trigger "Edit" mode, which currently highlights all blocks on the page. Clicking on one — in this case, the block with the site's name — pops out a new tray or sidebar. A content creator can change the site name directly from the tray, without having to navigate through Drupal's administrative interface to theme settings as they would have to in Drupal 7 and Drupal 8.1.

Making adjustments to menus

In the second image, the pattern is applied to a menu block. You can make adjustments to the menu right from the new tray instead of having to navigate to the back end. Here the content creator changes the order of the menu links (moving "About us" after "Contact") and toggles the "Team" menu item from hidden to visible.

In-context block placement

In Drupal 8.1 and prior, placing a new block on the page required navigating away from your front end into the administrative back end and noting the available regions. Once you discover where to go to add a block, which can in itself be a challenge, you'll have to learn about the different regions, and some trial and error might be required to place a block exactly where you want it to go.

Starting in Drupal 8.2, content creators can now just click "Place block" without navigating to a different page and knowing about available regions ahead of time. Clicking "Place block" will highlight the different possible locations for a block to be placed in.

Next steps

These improvements are currently tagged "experimental". This means that anyone who downloads Drupal 8.2 can test these changes and provide feedback. It also means that we aren't quite satisfied with these changes yet and that you should expect to see this functionality improve between now and 8.2.0's release, and even after the Drupal 8.2.0 release.

As you probably noticed, things still look pretty raw in places; as an example, the forms in the tray are exposing too many visual details. There is more work to do to bring this functionality to the level of the designs. We're focused on improving that, as well as the underlying architecture and accessibility. Once we feel good about how it all works and looks, we'll remove the experimental label.

We deliberately postponed most of the design work to focus on introducing the fundamental concepts and patterns. That was an important first step. We wanted to enable Drupal developers to start experimenting with the outside-in pattern in Drupal 8.2. As part of that, we'll have to determine how this new pattern will apply broadly to Drupal core and the many contributed modules that would leverage it. Our hope is that once the outside-in work is stable and no longer experimental, it will trickle down to every Drupal module. At that point we can all work together, in parallel, on making Drupal much easier to use.

Users have proven time and again in usability studies to be extremely "preview-driven", so the ability to make quick configuration changes right from their front end, without becoming an expert in Drupal's information architecture, could be revolutionary for Drupal.

If you'd like to help get these features to stable release faster, please join us in the outside-in roadmap issue.

Thank you

I'd also like to thank everyone who contributed to these features and reviewed them, including Bojhan, yoroy, pwolanin, andrewmacpherson, gtamas, petycomp, zsofimajor, SKAUGHT, nod_, effulgentsia, Wim Leers, catch, alexpott, and xjm.

And finally, a special thank you to Acquia's outside-in team for driving most of the design and implementation: tkoleary, webchick, tedbow, Gábor Hojtsy, tim.plunkett, and drpal.

Acquia's outside-in team celebrating that the outside-in patch was committed to Drupal 8.2 beta. Go team!
Catégories: Elsewhere

Liip: Drupal 8 accessibility features

lun, 22/08/2016 - 22:36

The Drupal accessibility initiative started with some advancements in Drupal 7 to ensure that Drupal core followed the World Wide Web Consortium (W3C) guidelines: WCAG 2.0 (Web Content Accessibility Guidelines) and ATAG 2.0 (Authoring Tool Accessibility Guidelines).
Many elements introduced in Drupal 7 were improved and bugs discovered through intensive testing were addressed and integrated to Drupal 8 core as well. Let’s take a tour of the accessibility in Drupal 8 !

Contrasts improved

Drupal’s accessibility maintainers improved contrasts in core themes so people that suffer from colorblindness are able to visit websites clearly. It is also good when visiting the website under bright sunlight, on mobile for instance.

Color contrasts in Bartik theme in Drupal 7.43 and Drupal 8.

See the related WCAG 2.0 section about contrasts.

Alternative texts for images

The alternative text for images is really useful for blind people who use screen readers. They can understand the meaning of an image through short descriptive phrases. This alternative text is now by default a required field in Drupal 8.

The alternative text for an image is required by default in Drupal 8 content edition.

See the related WCAG 2.0 section about alternative texts.

More semantics

Many accessibility improvements are hard to see as it involves semantics. Drupal 8 uses HTML5 elements in its templates which add more meaning into the code. For instance, assistive technology such as screen readers can now interpret elements like <header>, <footer> or <form>.

Moreover, WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) additional markup really improved semantics using:

  • landmarks to identify regions in a page, for instance: role="banner" ;
  • live regions to indicate that an element will be updated, for instance: aria-live="polite";
  • roles to describe the type of widgets presented, for instance: role="alert";
  • properties: attributes that represent a data value associated with the element.

See the related WCAG 2.0 sections about semantics.

Tabbing order

Drupal 8 introduces the TabbingManager javascript feature. It enables to constrain tabbing order on the page and facilitates navigation with keyboards. It is really helpful to guide a non-visual user to the most important elements on the page and minimize confusion with screen readers.

See the related WCAG 2.0 section about keyboard operations.

Forms

Drupal 8 accessibility involves many improvements regarding forms in Drupal 8.

In Drupal 7, all errors were displayed by default on top of the form and fields were highlighted in red. It was not right for colorblind people to understand where the errors were.
In Drupal 8, there is an experimental option to enable form inline errors and an error icon is displayed next to the field. Nevertheless, note that this feature is not enabled by default as there are still some pending issues.

The error message is displayed below the field when the Form Inline Error module is enabled.

See the related WCAG 2.0 sections about error identification.

Regarding the form API, radios and checkboxes are now embedded in fieldsets to meet WCAG compliance. Indeed, grouping related elements will help screen readers to navigate in complex forms. Plus, all fields have a label associated with the right element using the “for” attribute.

Here is an example of HTML code for radio buttons:

Poll status Closed Active

See the related WCAG technical section about fieldsets

Tables and views

As Views UI module is in core now, it became accessible.
The views tables markup is more semantic. Data cells are associated with header cells through “id” and “headers” attributes. It is also possible to add a <caption> element to explain the purpose of the table and a <summary> element to give an overview on how the data is organized and how to navigate the table.
Plus, the “scope” attribute enables to explicitly mark row and column headings.

Here is an example of a table HTML code generated by a view:

Caption for the table Details for the table Description for details Title Content type Premo Quae Vero Article Capto Dolor Article

See the related WCAG section about tabular information.

Hidden elements

Using "display:none;" CSS styling can be problematic as it will hide elements for both visual and non-visual users and consequently, screen readers will not be able to read them.
Drupal 8 accessibility maintainers decided to standardize in the naming convention of HTML5 Boilerplate using different classes to hide elements:

  • “hidden“: hide an element visually and from screen readers;
  • “visually-hidden“: hide an element only visually but available for screen readers;
  • “invisible“: hide an element visually and from screen readers without affecting the layout.
Aural alerts

Users with visual impairment will not be able to see all visual updates of the page such as color changes, animations or texts appended to the content. In order to make these changes apparent in a non-visual way, Drupal provides the Drupal.announce() JavaScript method which creates an “aria-live” element on the page. This way, text appended to the node can then be read by a screen reading user agent.

Here is an example of a code using the aural alert:

Drupal.announce('Please fill in your user name', 'assertive');

The first parameter is a string for the statement, the second is the priority:

  • “polite“: this is the default, polite statements will not interrupt the user agent;
  • “assertive“: assertive statements will interrupt any current speech.

See the related WCAG technical section about how to use live regions to identify errors.

CKEditor WYSIWYG accessibility

Drupal community helped improving CKEditor accessibility.
First of all, the WYSIWYG editor now comes with keyboard shortcuts which are beneficial for both power users and keyboard-only users.
Drupal 8 implements more semantic elements. For instance, the user can create HTML tables with headers, caption and summary elements. <figure> and <figcaption> HTML5 tags are also available to add captions to images.
Moreover, every image added through CKEditor are required by default, as it is on image fields.

CKEditor module also introduces a language toolbar button so that users can select a part of text and specify the language used. Screen readers will be able then to choose the appropriate language for each content.

See the related WCAG technical section about language attributes.

Finally, there is an accessibility checker plugin for CKEditor. It is not in core yet as a CKEditor issue blocks its integration, you can find more information on the related Drupal issue queue. However, you will find a module that implements it currently: ckeditor_a11checker.

All these options will definitely help users to generate accessible contents.

Conclusion

Drupal core maintainers accomplished great enhancements regarding accessibility in Drupal 8. These accessibility features will definitively be beneficial to keyboard-only users, low-vision users and colorblind people but will also be good for the usability and the SEO of your website.
Nevertheless, there is still work to be done to make Drupal 8 core fully accessible and Drupal needs contributors to tackle the remaining issues.

If you want to learn more about Drupal 8 accessibility, you can watch the presentation about “How Drupal 8 makes your website more easily accessible” given by Mike Gifford, one of the main accessibility core maintainer for Drupal.

Catégories: Elsewhere

OpenLucius: 14 Cool Drupal 8 modules for site builders | August 2016

lun, 22/08/2016 - 20:44

Here’s what struck me last month about Drupal modules. This month I have chosen to focus on Drupal 8 as this is slowly becoming the go-to version - partly because many required modules have been migrated and grown up.

1. Require Login
Catégories: Elsewhere

Chromatic: Create a Custom Views Sort Plugin with Drupal 8

lun, 22/08/2016 - 18:46

Having recently grokked custom views sorting in Drupal 7, I took a leap to investigate how to create this functionality in Drupal 8. The documentation out there is scarce at best. As a starting point, I decided to replicate Dave Vasilevsky’s task where he makes a custom views sort plugin for ordering upcoming and past events in D7. The requirement was to show future events in chronological order (i.e. show future events nearest the current date ahead of later future events) before showing past events in reverse chronological order (i.e. most recent past events first followed by earlier past events).

Screenshot from Vasilevsky's post

Create content type and view:

First order of business is to create an Event content type with a date field and a new view of events using fields in the display format. Here is a gist with the configuration yaml files for importing an Event content type with a body and field_event_date field and an Events view.

Looking at the results returned from this view as is, all the events are shown in haphazard order:

Now let’s create a custom views sort plugin. Since we need to alter the query for sorting event results by an event date field in a special way, a new sort handler needs to be added to the view by extending the field table for field_event_date. Using hook_views_data_alter() allows us to add this custom sort handler.

Declare the sort in hook_views_data_alter(): /** * Implements hook_views_data_alter(). */ function mymodule_views_data_alter(array &$data) { $data['node__field_event_date']['event'] = array( 'title' => t('Custom event sort'), 'group' => t('Content'), 'help' => t('Sort events by past/future, then distance from now.'), 'sort' => array( 'field' => 'field_event_date_value', 'id' => 'event', ), ); }

In this particular case, the date field that was added to the Event content type has a machine name of field_event_date. This generated a new table in the database called node__field_event_date that holds the actual value of the datetime field of an Event node. This datetime field is a column called field_event_date_value - this is the field on which we need to perform our custom sorting. Since we added the field_event_date as a field to the view, it will be joined to the base node_field_data table that gets queried for matching Event nodes.

In hook_views_data_alter(), we’re altering the query for the node__field_event_date table by extending it with a new event array that adds some basic information like title, group, and help which we’ll see in the views UI when we go to select the custom sort. The new event array more importantly adds a sort key with the field_event_date_value as the field we want to sort on plus the id of the plugin (in this case a new sort plugin class named ‘event’) we will use to add the custom sorting functionality.

Create the plugin to handle the new sorting: <?php namespace Drupal\mymodule\Plugin\views\sort; use Drupal\views\Plugin\views\sort\Date; /** * Basic sort handler for Events. * * @ViewsSort("event") */ class Event extends Date { /** * Called to add the sort to a query. */ public function query() { $this->ensureMyTable(); $date_alias = "UNIX_TIMESTAMP($this->tableAlias.$this->realField)"; // Is this event in the past? $this->query->addOrderBy(NULL, "UNIX_TIMESTAMP() > $date_alias", $this->options['order'], "in_past" ); // How far in the past/future is this event? $this->query->addOrderBy(NULL, "ABS($date_alias - UNIX_TIMESTAMP())", $this->options['order'], "distance_from_now" ); } }

This sort handler basically extends the Date sort plugin which can be found in core (/core/modules/views/src/Plugin/views/sort/Date.php). All that we’re overriding is the query() function to add our custom sorting, effectively running two sorts (future and past) on the results based on the current date.

Since we need to sort differently for future and past events, we convert the datetime formatted value of field_event_date_value into a unix timestamp and run comparisons against the current date.

We can then alter the query by adding custom ORDER BY clauses to the SQL statement. When we go to add the new sort, the new query will look like:

Let’s see all this in action through the views UI. Back in our view, click on Add next to "SORT CRITERIA". Our new custom sort should be visible in the list:

In the next part of the ajax form, since we didn’t override any of the Date form options, we’ll see the order and granularity options. Just leave all the defaults as is and click "Apply".

Now we should see our new custom sort in the UI:

Finally we’ll see our events sorted with future events in chronological order and past events in reverse chronology:

The theory behind how to accomplish this task in Drupal 8 is not that much different from Drupal 7. In both cases, we need to add the custom sort handler in a hook_views_data_alter() and override the query. The difference in D8 is everything uses the plugin system so the syntax for extending the base Date sort class varies from extending the default sort handler in D7.

And there you have it - a custom views sort plugin in D8!

Catégories: Elsewhere

Tag1 Consulting: Tag1 Quo and Drupal 6 Long Term Support

lun, 22/08/2016 - 16:42
Tag1 Quo and Drupal 6 Long Term Support Jeremy Mon, 08/22/2016 - 07:42 Or, What We Did This Summer

It’s been an exciting summer, building our first product with Drupal 8. When we originally made the decision to offer Long Term Support for Drupal 6, we were thinking about a few of our clients that were a little behind on their upgrade plans, and had envisioned a mostly manual process.

Catégories: Elsewhere

Acquia Developer Center Blog: Progressively Decoupled Drupal Approaches

lun, 22/08/2016 - 16:34

Progressive decoupling, a concept outlined last year in Dries Buytaert’s first post about decoupled Drupal, is a compelling approach to building Drupal's front end where content editors, site assemblers, and front-end developers maintain contiguous experiences. For content editors and site assemblers, progressive decoupling allows for contextualized interfaces, content workflow, site preview, and other features to remain usable and integrated with Drupal as a whole.

Tags: acquia drupal planet
Catégories: Elsewhere

BlackMesh: Our Ongoing Commitment to Security: Partnering with Tag1 Consulting

lun, 22/08/2016 - 15:22

As you may already know, the BlackMesh team is committed to ensuring developers can focus on their website goals without worrying about scalability, infrastructure, and – in particular – security. That’s why we’re thrilled to have partnered with leading Drupal security agency Tag1 Consulting to provide our Drupal clients a comprehensive tool for managing site updates.

What?

The new Tag1 Quo is a hosted security dashboard that provides up-to-the-minute snapshots of a client’s security status and potential vulnerabilities. Basically, this innovative tool provides Drupal users consolidated and critical security updates for their websites. Tag1 Quo features include essentials for a website’s success, such as self-service monitoring, security notifications for out-of-date modules, and patch and release delivery.

How?

Tag1 Quo automatically monitors upstream releases and security advisories in collaboration with module maintainers and other Drupal 6 long term support (LTS) providers. The Tag1 team of Drupal security experts review and decide which issues affect the client, carefully backporting those that are applicable to their site. Quo then delivers timely notifications to the client’s inbox. Quo users can choose to either leverage pre-patched releases or quickly apply the patches themselves to bring their website up-to-date and secure against all known vulnerabilities. For extra peace of mind, the Quo dashboard provides at-a-glance visualization of all client websites, highlighting all outstanding updates across them.

Tag1 Quo Dashboard

Why?

Though D6 was phased out earlier this year, Tag1 Consulting continues to provide long-term D6 support to those who need it. As a way to adequately manage the significant maintenance and monitoring of these systems, the Tag1 team developed Tag1 Quo.

If you are currently managing a D6 site, signing up for Tag1 Quo is a no-brainer. It provides affordable long-term support for all of your core and contributed modules and themes, tested and delivered by an approved LTS provider, backed by a team of renowned Drupal experts.

Your Security. Your Options …

Even if you don’t maintain a D6 site, you’ll still want to check it out.

Depending on your needs and budget, Tag1 Quo offers three different plan options. Tag1’s roadmap includes upcoming support for D7 and D8, WordPress 4.6 and 4.7, application programming interface (API) access, upgrade planning, and more.

Signing up for Tag1 Quo means less time spent on maintenance and security – and that means more time focusing on your goals and overall mission. Whenever BlackMesh teams up with companies like Tag1, we’re advancing our commitment to your security. Contact us to learn more about how we can make the Tag1 Quo dashboard solution fit your needs.

 

Like this article? Follow us on Facebook and share your thoughts!

SecurityDrupal
Catégories: Elsewhere

Blair Wadman: How to create a custom block and assigning to a region in Drupal 8

lun, 22/08/2016 - 08:12

One of the many changes in Drupal 8 is adding a block to a region. The block interface has been pretty consistent over the years, so changes to how it works can be confusing at first. You do something over and over again and then “Wait a minute! Things have moved, what do I do?!”. But never fear, the new way of adding blocks to regions is pretty straight forward once you get your head around it.

Catégories: Elsewhere

PreviousNext: Drupal 8 FTW: Is it a test or is it a form? Actually, its both

lun, 22/08/2016 - 03:25

As you'd be aware by now - Drupal 8 features lots of refactoring of from procedural code to object-oriented.

One such refactoring was the way forms are build, validated and executed.

One cool side-effect of this is that you can now build and test a form with a single class.

Yep that's right, the form and the test are one and the same - read on to find out more.

Catégories: Elsewhere

Roy Scholten: Content workflow initiative, the concept map

dim, 21/08/2016 - 21:34

Mapping out the moving parts of the content workflow initiative we arrived at this high level grouping of related activities:

  • Create content
  • Review & approve content
  • Publish content
  • Manage the creation, review and publishing process
  • Configure the tools that enable all of the above

For either single items of content or a set of multiple items, bundled in a workspace.

Create content

Everything related to creating new, editing existing content in the first place.

Roles
  • Author
  • Copy writer
  • Photo/image editor
Tasks & activities
  • Review assignments
  • Create content
  • Format content
  • Preview content
  • Request review
  • Edit content based on feedback
  • Review other people’s content
  • Review existing, live content
Review & approve content

All the things that need to happen to get new content ready for publication. Here’s a more elaborate example of a moderation workflow using a workspace.

Roles
  • Editor
  • Marketing associate
  • Archivist
Tasks & activities
  • Review content, give feedback
  • Edit content
  • Preview content
  • Get notified of content conflicts
  • Adapt content for different channels
  • Analyse impact of content changes
  • Review existing content
  • Recover content
Publish content

Actual publication of content and managing its life cycle from then on.

Roles
  • Section editor
  • Legal
  • Compliance
Tasks & activities
  • Define/specify content packages
  • Review content (packages)
  • Audit (legal, compliance)
  • Preview content
  • Approve revivisions
  • (un)publish content items
  • (un)publish content packages
  • Schedule (un)publishing of content
  • Archive/delete content
Manage content workflow

Set the strategic agenda, coordinate with other business units, oversee all of the above.

Roles
  • Managing editor
  • Marketing executive
  • Support & maintenance
Tasks & activities
  • Define content strategy
  • Content planning
  • Coordinate with the business
  • Coordinate with IT
  • Coordinate content delivery
  • Define content assignments
  • Schedule content production
  • Monitor progress
  • Review audit trail
Configure content workflow tools

Providing the tools and processes to enable all of the above.

Roles
  • Administrator
  • Developer
Tasks & activities
  • Configure workflows for content moderation
  • Configure content workspaces
  • CMS configuration: content types, roles & permissions, notification settings…
  • Technical development

Have a look at the visual definition of a workspace and a more fleshed out example of a moderation workflow as well.

Hope this helps clarify the main concepts, activities and relationships in the workflow initiative.

Tags: drupaluxworkflow initiativedrupalplanetSub title: Must not make spelling mistakes or I have to start over again
Catégories: Elsewhere

Danny Englander: Drupal 8 Development: How to Import an Existing Site Configuration Into a New Site

dim, 21/08/2016 - 02:31

Disclaimer: The steps in this tutorial are not recommend for a live site and are experimental!

Recently, I ran into an issue in my local Drupal 8 development environment where uninstalling a module failed. I was getting errors related to the module in question in both the UI and in drush. My bad for not having a recent DB backup for my local, the one I had was too old to use. (I've since fixed that with an automated backup script!) Double my bad for having installed a not-ready-for-primetime module.

That being said, my local site had a ton of configuration and custom entities and I really wanted a clean database. I first attempted to use Features to transport all my config to a new install but kept getting an "Unmet Dependancies" error and was not able to get to the bottom of it. (There are a number of Drupal 8 Features issues open related to this.) I didn't understand this error as I was simply using the same root folder with a new database.

Features aside, I knew that by nature, an existing site configuration export can't be imported into another site, this makes sense at face value. But I got to thinking, "well, I just want to take all this nice config and pop it into a brand new site" -- less anything relating to the aforementioned bad module.

Get the site UUID

I did more searching and sure enough there is roundabout way to do what I was intending. It involves a few drush commands, drush cget and drush cset. The first command is to get the existing UUID from your present site.

drush cget system.site uuid

This will print out the Site UUID as:

'system.site:uuid': bfb11978-d1a3-4eda-91fb-45decf134e25

Once you get this, be sure to run drush cex one last time which will export the current configuration.

Install and reset

Once I had the current UUID, I put my settings files back to default, created a new database and installed Drupal 8 from scratch. Once the new site installed, I updated my settings.local.php to point to my existing configuration files:

/sites/default/files/config_......./sync/

If your remote is on Pantheon, the local config path would be like this:

/sites/default/files/config/

Once this was set, all I had to do was reset the new site UUID to my old one that I derived from the drush cget command by running this:

drush cset system.site uuid bfb11978-d1a3-4eda-91fb-45decf134e25

This resets the new site's UIID to the old site's UUID and that will allow you to run your config import.

Import the existing config

Now it was time to run drush cim which imports your site configuration. Running the command the first time gave me a rather nasty looking error.

The import failed due for the following reasons: [error] Entities exist of type Shortcut link and Default. These entities need to be deleted before importing.

This might seem like a scary error but it just has to do with admin Shortcut links and there is a core issue open for this. At any rate this was a new site so I didn't really care about deleting these. I did more searching and discovered an obscure drush command to "fix" this:

drush ev '\Drupal::entityManager()->getStorage("shortcut_set")->load("default")->delete();'

Once I did that, my configuration imported like a charm, all 300 config files and several dozens of entities. I didn't see any errors after that, and everything was perfect now.

Summary

I am not sure there would be many use cases for doing what is outlined here but it did solve a specific issue, your milage may vary. I would be suspect of using this method for an existing site that has lots of things already built out. Keep in mind, I imported my existing config into a brand new site install.

Tags 
  • Drupal
  • DevOps
  • Drupal 8
  • Drush
  • Drupal Planet
Resources 
Catégories: Elsewhere

Anchal: GSoC'16 - Porting Comment Alter Module

dim, 21/08/2016 - 02:00

For the last 3 months I’ve been working on Porting the Comment Alter module to Drupal 8 as my GSoC’16 project under mentorship of boobaa and czigor. This blog is an excerpt of the work I did during this time period. Weekly blog posts for the past 12 weeks can be accessed here.

Achievements

Creating schema for the module: Implemented hook_schema() to store the old and new entity revision IDs along with the parent entity type as altered by a comment. The revision IDs are used to show the differences over comments. The parent entity type is used to delete the entries from the comment_alter table when any revision of the parent entity is deleted, because in Drupal 8 we can have same revision IDs from different entity types. So to remove entries of particular entity type we need the entity type.

Using ThirdPartySettings to alter field config edit form - Implemented hook_form_FORM_ID_alter() for field_config_edit_form. This provides an interface to:

  1. Make any field comment alterable - Makes it possible to select any field we want to be altered by the comment. Currently all the Drupal core provided fields works well with the module.

  2. Hide alteration from diff - If the comment alterable option is enabled, then this option hides the differences shown over the comments. Instead of the differences, a link to the revision comparison is displayed for nodes. For the rest of the entities a “Changes are hidden” message is shown.

  3. Use latest revision - When a module like Workbench makes the current revision of an entity not the latest one, this option forces the Comment Alter module to use the latest revision instead of the current one. This option is present on the comment field settings.

  4. Adds Diff link on comments - Adds a Diff link on comments which takes us to the comparison page of two revisions, generated by the Diff module.

  5. Comment altering while replying to a comment - By default comment alterable fields can not be altered while replying to a comment. This option allows altering of fields even while replying to comments.

Adding pseudo fields: Implemented hook_entity_extra_field_info() to add one pseudo field for each comment alterable field on respective comment form display, and one pseudo field on comment display to show the changes made at the comment. Using these pseudo fields the position of the comment alterable fields can be re-ordered in the comment form. This gives site-builders flexibility to alter the position of any alterable fields.

Attaching comment alterable fields’ widgets on comment form: Comment alterable field widgets are retrieved from the form-display of the parent entity and they are attached to the comment form only after ensuring that there are no side effects. To support same name fields on both comment and parent entity, #parent property is provided so that the submitted field values for our alterable field widgets appears at a different location, not at the top level of $form_state->getValues(). All these added fields are re-orderable. Column informations and old values are also stored to the form at this stage, to later check if there were any changes made on the comment alterable fields.

Adding submit and validation callback for the altered comment form: First the submitted values are checked against the old values to see if the values of the alterable field changed at all or not. If they changed, then the parent entity values are updated and this is done by building the parent entity form display and copying the altered field values into it. Then the form is saved. In case the parent entity doesn’t support revisions, then do nothing else just save the parent entity with altered values. Otherwise create a revision and store the comment ID, old and new revision IDs and parent entity type in the comment alter database table, which is used to show the differences on comments using the Diff module.

Showing differences on comments: Using the Diff module and comment alter database table, the differences are shown over a particular comment. Only possible if the parent entity supports revisions. Diff module is used to get the differences between the two revisions and then those differences are rendered on comments in table format along with some custom styling.

Adding PHPUnit tests: Added automated unit tests to check the functionality of the module for different field types and widgets. The tests are written for EntityTestRev entity types to keep them as generic as possible. This was the toughest part for me as I was stuck at some places in tests for quite a while as thses tests took lot of time to run and debugging them really is hard. But in the end I’m happy that I was able to complete all the tests.

Screencast/Demo video: Created a demo video showing how the Comment Alter module works, along with a simple use case.

What’s left?

My mentors asked me to skip the Rules Integration part because the Rules module doesn’t have a stable or a beta release yet, only their first alpha release is there. So, the Rules Integration part is postponed till we get a stable or beta release.

Some important links

Thank you!

Catégories: Elsewhere

Roy Scholten: Getting something in the box

sam, 20/08/2016 - 23:53

First impressions matter. The first glance has a lot if impact on further expectations. Drupal core doesn’t do well there. As webchick points out, after installation the opening line is “you have no content”.

Yeah, thanks.

This empty canvas makes Drupal appear very limited in functionality. Which is the exact opposite of how Drupal is advertised (flexible, extensible, there’s a module for that!)

This is not news. The issue for adding sample content is over 10 years old. The image I posted earlier is from a core conversation 6 years ago. Eaton and moi presented on Snowman in Prague 3 years ago.

But now we do have Drupal 8, with essential features available right out of the box. We have a new release schedule that encourages shipping new features and improvements every 6 months. And we’re settling on a better process for figuring out the part from initial idea to fleshed out plan first, before implementing that plan.

So lets work together and come up with a plan for sample content in core. Which means answering product focussed questions like:

  • Audience: who do we make this for?
  • Goals: what do these people want to achieve?
  • Features: which tools (features) to provide to make that possible?
  • Priorities: which of those tools are essential, which are nice to haves?

But purpose first: audience and goals.

We’re always balancing product specifics with framework generics in what core provides. Pretty sure we can do something more opiniated than our current default “Article” and “Page” content types without painting ourselves in a corner.

We’ll discuss this topic during upcoming UX meetings and in the UX channel in drupal.slack.com (get your automatic invite here).

Tags: drupalonboardingdrupalplanetSub title: Tabula rasa is not an effective onboarding strategy
Catégories: Elsewhere

ImageX Media: Complete Content Marketing with Drupal

sam, 20/08/2016 - 02:11

At its most basic, content marketing is about maintaining or changing consumer behaviour. Or more elaborately, it’s “a marketing technique of creating and distributing valuable, relevant and consistent content to attract and acquire a clearly defined audience -- with the objective of driving profitable customer action.”

Catégories: Elsewhere

ImageX Media: Want to be a Content Marketing Paladin? Then Automate Your Content Production Workflows with These (Free) Tools

sam, 20/08/2016 - 02:07

Flat-lining content experiences and withering conversion rates can be the kiss of death to almost any website. When content experiences deteriorate one issue seems to make an appearance time and time again: the amount of time and resources required to produce and manage content marketing initiatives. Among the many best practices and strategies that will accelerate growth includes the all-powerful move towards productivity automation. 

Catégories: Elsewhere

Pages