Subscribe to Drupal News feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 8 hours 4 min ago

Dropsolid: Drupal 8 config management (part 2)

Wed, 02/07/2018 - 10:01
07 Feb Config management in Drupal 8: the set-up (part 2/3) Niels A Drupal 8 Drupal

In the first part of this three-piece blogpost, we explained the existing options for managing your configuration across environments. We also shed some light on grey areas between configuration and content. In this part, I’ll be showing you how to set it all up.
 

Back to part 1     Skip to part 3

 

Setting up configuration management Configuring the splits

Start by installing the config split module, available here.

We like to keep our splits simple and clear. Currently, have four splits:

  • Blacklist: A split that doesn’t have a folder configured, so it doesn’t end up in our Git repository. This split usually has the same configuration as the config ignore module. The reason why will be explained in the part about config ignore.
  • Dev: A split that is used for our development environment-only configuration
  • Staging: A split that is used for our staging environment-only configuration
  • Live: A split that is used for our live environment only-configuration

Our blacklist configuration looks like this:

If you don’t fill in the folder name, the Config Split module will export the config to a table in the database. That way, it doesn’t pollute your Git commits. For our other splits we use a folder outside our docroot for security reasons - e.g. for a dev split: ../config/splits/dev

Another important value here is the weight of the split. This weight will be used when multiple splits are active. The weight defines the order in which conflicting settings from splits get resolved. I will explain this in the part about the settings files, a little further down this post.

For the active checkbox you can choose whatever you want, because we’ll overwrite it later using the settings.php file. 

We’ve only been actively using the complete split configuration because it is pretty straightforward in how it handles your configuration. The additional configuration is handy because you can use wildcards. In the case of our blacklist, for example, we wanted to exclude everything from webform by using “webform.*”

We haven’t come across any use cases where we needed the conditional split, because we have a split active on every environment or the environment just needs the configuration from the sync folder.

If you were to use it, the following use case would be perfect for it. For instance, you have some configuration you need on all environments but you want it to be different on one environment. In our example we want a different email to be set in the reroute e-mail settings on the staging environment. You would change it in the interface and then do a “drush csex staging” to export it to the config split staging folder. This will allow the config file to be present in the sync folder and in the split folder. 


Configuring ignore

 

First, install the config ignore module.

The important thing to know about this module is that it only ignores config on import. This is why we have currently set up a blacklist split. A new module called Config Export Ignore (available here) is also at your disposal, but we haven’t used it in our workflow because it doesn’t have a stable release yet. We will look into this in the future though, because the “blacklist” split feels like a hack in some way.

Our default config ignore settings look like this:

As you can see, you can also add some special rules to your ignore settings. The only downside is that config split does not support these special rules. You’ll have to tweak your blacklist split a little bit and make your peace with the added files in your repo, until we find or create a solution for this. 


The settings files

To get this working across all environments, you need to have a settings file that is aware of its environment. This can be done using an environment variable that you check or use different files that get deployed based on the environment. There you set which config should be active on which environment. Sometimes it happens that you need multiple splits to be active on a single environment. You need to consider these splits as layers of config that you want to manage across environments. 

Our settings.php file on our development environment is identical to our local environment. It contains the following lines:

// Set your config directory outside of your docroot for security $config_directories[CONFIG_SYNC_DIRECTORY] = '../config/sync'; // Configure config split directory $config['config_split.config_split.blacklist']['status'] = TRUE; $config['config_split.config_split.dev']['status'] = TRUE; $config['config_split.config_split.staging']['status'] = TRUE; $config['config_split.config_split.live']['status'] = FALSE;

You might think that setting the staging split to true on the dev/local environment might be a mistake, but this is very intentional. As we are mostly using the complete split settings, this means that a config file can only be in one place. So we leverage the weight of the splits to also have certain staging config on our dev/local environment active. 
For instance, if we only want the reroute e-mail module to be active on local/dev/staging environments, we would add it to the complete split settings of the staging split.

Our settings.php for our staging environment will look as follows:

// Set your config directory outside of your docroot for security $config_directories[CONFIG_SYNC_DIRECTORY] = '../config/sync'; // Configure config split directory $config['config_split.config_split.blacklist']['status'] = TRUE; $config['config_split.config_split.dev']['status'] = FALSE; $config['config_split.config_split.staging']['status'] = TRUE; $config['config_split.config_split.live']['status'] = FALSE;

Consequently, the settings.php for our live environment looks like this:

// Set your config directory outside of your docroot for security $config_directories[CONFIG_SYNC_DIRECTORY] = '../config/sync'; // Configure config split directory $config['config_split.config_split.blacklist']['status'] = TRUE; $config['config_split.config_split.dev']['status'] = FALSE; $config['config_split.config_split.staging']['status'] = FALSE; $config['config_split.config_split.live']['status'] = TRUE;

Our Rocketship install profile (blog post in Dutch) has all these things preconfigured, which enables us to create more value for our clients.


Deploying changes

When you want to deploy changes to your environments, the only thing you need to do is make sure the config files that you’ve exported using ‘drush config-export’ are on the environment you want to deploy. Using a versioning system like Git can greatly help you manage those files across environments. 

When you are ready to deploy your changes, just run the “drush config-import” command on that environment. Settings up drush aliases can save you a lot of time when you want to execute drush commands on remote environments. Read more about them here on this Drupal.org page.

Once you have this in place, you’ll be able to easily manage your configuration across environments. Go check out part 3 if you want to explore a couple of real world use cases and issues we’ve encountered.
 

Revisit part 1     Read part 3

Dropsolid: Drupal 8 config management (part 1)

Wed, 02/07/2018 - 10:00
07 Feb Config management in Drupal 8: tackling common problems and use cases (part 1/3) Niels A Drupal Drupal 8

This is the first of a series of three config management blog posts. In this series, we’ll help you set up a good starting point and provide you with a few solutions for everyday configuration issues. The first part of this multi-part blog post will provide you a bit of context. The second part goes into the nitty gritty of configuration management, and the third part demonstrates some concrete use cases, pitfalls and their solutions!

 

Features and configuration management

Drupal 8 has been around for a while now and at Dropsolid we have substantial experience with large projects that use both the contributed Features module and the core configuration management system.

Essentially, Features leverages the configuration management system to package configuration with your module and overwrites certain rules for importing config from a packaged module after first install.

The alternative is to use configuration management from Drupal 8 core with the contributed Config Split and Config Ignore module.

Config split lets you set up rules for splitting your configuration per environment. Config ignore lets you ignore certain configuration to be imported.

The way you handle configuration fundamentally differs between both solutions. Features lets you whitelist the configuration you want to import. Configuration management from Drupal 8 core with addition of the mentioned contributed modules works more like blacklisting the configuration you don’t want to import. As a developer I have always found it easier to narrow down what I want to have control over, instead of what I don’t want to have control over. 

We’ve come to the conclusion that the latter option actually works faster, which means more value for the client, but only if you have a good configuration to start from. As it turns out, configuration that you don’t want to control, is more often shared between different projects than config that you do want to control.

 

Content and config: blurred lines

One of the most wonderful things about Drupal 8 is config entities, a uniform way of creating and saving configuration throughout your site. It has been leveraged by many contributed modules to give end users a great experience in configuring their website. 

The downside of these configuration entities is that they often cross the line between what is considered content and configuration. We consider content as everything a client needs to be able to change. A good example of this are webforms. Every webform you create is an instance of a configuration entity - whereas the submissions of the webform are instances of a content entity. If you want to know more about the difference between config and content entities, I advise you to read this article by Acquia.

We want clients to have full control over the kind of webforms they create, so they can use them effectively across their site to gather leads.

This brings us to the following issue. As a company we believe that a website is an ever-changing platform that grows over time. To have it grow at the speed that customers require, we need to work on multiple features with multiple teams at once. It needs to be stable and traceable. 

Part of this stability and traceability is having what we developers define as structural configuration being versioned (git) and easily deployable, all without hindering the client to keep on working on their content. 

Thanks to configuration management, config split and config ignore we’ve been able to achieve all this for Drupal 8!

Ready to set up your configuration? Read on in part two of the blog post series!
 

Read part 2

Lullabot: Drupal 8 Release Planning in the Enterprise

Wed, 02/07/2018 - 10:00

Yesterday, your CTO mandated that all new CMS builds would on Drupal 8 and that all existing CMS platforms would be consolidated to Drupal within the next three years. Great! Time to start prioritizing sites, hiring teams, and planning development and launch schedules.

The old methods of release planning don’t work anymore

Most enterprise IT organizations are used to a “development” cycle followed by a “maintenance” cycle, at which point you start over again and rebuild with a new development cycle. This type of planning (which Dave Hansen-Lange called the “boom-bust cycle”) led to poor user experiences with Drupal 7 sites as they became stale with time and is impossible to use for a Drupal 8 site.

Drupal 8 has a different release cycle compared to previous Drupal releases. For example, Drupal 7 was released in January 2011, and ever since has only had bug fixes (with the occasional developer-only feature added). Drupal 5 became unsupported, and Drupal 6 entered it’s last phase of support (until Drupal 8 was released). Product owners of sites big and small found this release process stifling. The web is a very different platform today compared to January 2011—although Drupal 7 is pretty much the same. The slow release cycle also reduced willingness to contribute directly to Drupal after all, why spend time writing a new feature you can’t use until you migrate to Drupal 8?

Part of why Drupal 8’s development took the time it did was to allow for a faster release cycle for features. Now, new features are added in point release (while code compatibility with prior Drupal 8 releases is broadly maintained).

Furthermore, security updates are only reliable for the latest minor release. After a minor release, such as Drupal 8.4, security issues in the prior minor release (such as Drupal 8.3) will only be patched for a few weeks, if at all.  In other words, to keep your sites secure, you have to be on the latest point release.

Upgrading your site every six months is a cost of using Drupal 8.

However, it’s not just Drupal that requires more frequent upgrades. Docker, NodeJS, and PHP itself all have more aggressive support schedules than similar software may have had in the past. Here lies the core of release planning: synchronizing all of these release schedules with your business.

1. Build a schedule of key dates for your business

In the publishing industry, tentpole events such as tournaments, live events, or holiday specials drive production deadlines. In addition to tentpole events, identify conferences, retreats, and other dates where your team may not be available. If they overlap with an EOL of software in your stack, you can try to schedule an upgrade ahead of time.

There are two reasons to identify these early and socialize them with the rest of the business. First, these are times when you don’t want to schedule maintenance or deployments if you can help it. Second, these key dates are times to be prepared and aware of security release windows. For example, Drupal core security releases are usually on the third Wednesday of the month. If this overlaps with a high-traffic event, having a plan to deploy and test a security patch before the patch is issued will ensure your site is kept secure, and that technical teams aren’t stressed out during the process.

2. Build a schedule of your stack and its support windows

Too often, we see organizations mandate a specific tool (like Drupal or Docker) without budgeting time and money for recurring, required upgrades. Maintenance often means “respond to bug reports from our team and handle outages,” instead of “incrementally upgrade software to keep it in supported releases.”

Before development begins, teams should gather a list of all key software used in their expected production stack. Then, go to each software release page, and find out the start and end dates of support for the current and next few releases. Use this to create a Gantt chart of support windows.

Here’s an example of one I created for a client that was deploying Drupal 8, PHP, Nginx, nodejs, Docker, and Ubuntu for their sites. In their case, they weren’t using Ubuntu packages for any of the other software, so they had to track each component directly.

undefined

Having such a chart makes prevents surprises. For example, if a site is using nodejs 6.x, we can see that it’s going to EOL just after Drupal 8.5 is released. It would make sense for a developer to work on upgrading to nodejs 8.x over the December holiday break so that the team isn’t juggling upgrading two core components at the same time.

This type of chart also gives teams the power to know if a given technology stack is maintainable for their organization. If it’s a small team maintaining a large Drupal site, they may not have the bandwidth or expertise to keep up with updates elsewhere in the stack. That may mean they have to stick with LTS releases, or avoid software without an LTS available.

For Drupal 8, that may mean that it is not a fit for your organization. If your budget only allows an initial build and then very minimal maintenance, Drupal 7 or another CMS may be a better fit (at least until Drupal 8 has an LTS). Or, for event and marketing sites, consider using a static site generator like Jekyll, so that when development ends the site can be “serialized” into static HTML and served with a basic stack using LTS software only.

3. Have a top-down process for handling security and feature updates

Many times we see software update requests coming from the development team, and then bubbling up to product owners and managers, meaning management will often prioritize new features with immediate business value before critical updates. Of course, this ignores the fact that a functioning and secure website is the foundation for addressing the needs of the business. And, it places developers in an awkward position where they are responsible for cleaning up any security breaches that occur.

Instead, software updates should be visible to and scheduled by the project managers, ensuring that time is available in the right sprint to test and deploy updates, preventing the development team from being overcommitted or opening your site up to a security breach. For example, let's say a team is using two-week sprints, with a sprint set to start on February 19, 2018. A quick look at the release cycle overview for Drupal 8 shows that 8.5.0-rc1 will be tagged on February 21st. Creating a ticket for that sprint ahead of time will ensure the upgrade won’t be forgotten.

It can be more difficult to handle software—like Drupal contributed modules or npm packages—that doesn't have a defined release schedule. In those cases, having a recurring “update everything” ticket can help. Assuming one team manages an entire deployment, a successful schedule might look like:

  • Sprint 1: Update all Drupal contributed modules
  • Sprint 2: Update all npm packages
  • Sprint 3: Update all system-level packages
  • Sprint 4: Update all Drupal contributed modules
  • … etc.

Remember, just because you schedule software updates doesn’t mean that you have to deploy them to production if QA goes poorly. But, if you do find issues, at least you can try and address them before, and not during a security patch.

4. Promote the new features you deploy to your colleagues and users

After doing all of this work, you should tell your end users and stakeholders about the gains you’ve made in the process. Show editorial users how Drupal 8.4’s Inline Form Errors gives them a better display of form errors on content they write. Tell your stakeholders how your API servers respond 15% faster to mobile clients. High-five your developers when they can remove a patch they’d been manually applying to the site.

For larger teams, newsletters and blogs are a great way to communicate these improvements. They are especially useful for core development teams, who write and maintain software shared throughout an enterprise.

With a solid grasp of how upstream release schedules affect your product, you will be able to reduce the need for unexpected delays and budget requests. If you’re interested in exploring this further with your team, we’d be glad to help.

InternetDevels: Examples of great business & finance websites built with Drupal

Wed, 02/07/2018 - 07:51

Examples of great business & finance websites built with Drupal In the world of business and finance, a website should as reliable as a Swiss watch, unbreakable like an armored safe, irresistibly attractive like George Washington’s portrait on a banknote, fast like a business-class car — the list could go on. And Drupal fits all these and other requirements! The ability to easily integrate the site with third-party systems, output data to any application and “lock and seal” the site in terms of security — these advantages alone put Drupal at the head of the pack.

Read more

Matt Glaman: Drupal 8 controller callback argument resolving explained

Wed, 02/07/2018 - 06:00
Drupal 8 controller callback argument resolving explained mglaman Wed, 02/07/2018 - 05:00 Drupal 8 has a robust routing system built on top of Symfony components. Robust can be taken in many ways. It's powerful and yet magical, making it confusing at times. There is a lot of great documentation on Drupal.org which covers the routing system, route parameters, and highlights of the underlying functionality. But the magic isn't fully covered. So, let's explore.

Droptica: Droptica: Ideal IDE and Linux configuration for work with PHP and Drupal

Wed, 02/07/2018 - 03:35
The projects implemented by Droptica require a large amount of coding in PHP. Taking advantage of various tool and configurations allows us to streamline the process and make it far more convenient and pleasant. In this post, we wanted to share our experiences and describe an ideal software configuration for coding in PHP (mainly in Drupal) from our standpoint at Droptica. The base software that we use includes Linux (most people use Ubuntu) and PHPStorm as IDE. We also use Docker for setting up and running services like Apache, MySQL, Solr, etc. 

Agiledrop.com Blog: AGILEDROP: Top Drupal blog posts from January

Wed, 02/07/2018 - 03:01
Each month, we revisit our top Drupal blog posts of the month, giving you the chance to check out some of our favourites. Here’s a look at the top blog posts from January.     First one on the list is New features for TMGMT by Sascha Grossenbacher from MD Systems. They were working on several new features for The Translation Management Tool, and this blog post is revealing some of the new functionality.    We continue our list with Never "Just" a Patch by AmyJune Hineline, know as “Volkswagenchick” from Hook 42. In the years contributing back to the project, AmyJune has learned that we… READ MORE

Zhilevan Blog: What's new in Drupal 8.5

Wed, 02/07/2018 - 01:48
  It's long time Drupal 8 has been released, it's in the middle of the way but it's going to get matured. Drupal 8.5 is going to release on  March 7, 2018. good features are going to released, significant improvements. you can the list of them Drupal Core RoadMap(8.5 + 8.6)   

ADCI Solutions: Cloud hosting platforms. Part two: Acquia Cloud

Tue, 02/06/2018 - 22:32

Acquia Cloud is one of the modern hosting platforms that can enhance your work in a number of ways. If you consider yourself a good Drupal developer, you must know what possibilities Acquia Cloud provides.

Isolated environments, git support, extensive documentation, and even the Acquia Insight tool for website’s performance evaluation - Acquia Cloud has it all.

 

Learn more about Acquia Cloud

 

PreviousNext: New in core: a layout builder for Drupal 8.5.0

Tue, 02/06/2018 - 20:14

Drupal 8.5.0 will come with a new experimental module, Layout Builder.

What is layout builder? Well its basically panelizer in core.

Watch the screencast for a quick run down of how to setup, configure and use it.

by Lee Rowlands / 7 February 2018 Tagged Drupal 8, Layouts, Blocks

DrupalCon News: Sneak peek at DrupalCon Speakers

Tue, 02/06/2018 - 13:41

Our full session list will be announced on February 21 - but we just couldn’t wait to tell you about a few of the sessions that have us really excited.

Aten Design Group: Drupal 8 Views: Entity Reference Exposed Filter as a Select List

Tue, 02/06/2018 - 12:18

I have two content types: Art and Artist. The first content type, Art, has an entity reference field to the second content type, Artist. I have a view named “Art” which shows all Art content with an exposed “Artist” filter that lets a user pare down their results. For example, a user might use the “Artist” filter to only show art by Cleon Peterson. By default this exposed filter will be rendered by Views as an empty text input, which is pretty much entirely useless! Users may not know of Cleon Peterson and wouldn’t know to search for him.

A much better solution would be to show the options available for this filter as a select list.

This is exactly the problem I was faced with while working on The Octopus Initiative, a soon-to-launch Drupal 8 project by the Museum of Contemporary Art Denver that allows citizens of Denver the opportunity to take art from the museum home with them.

The solution

Let’s jump into the code.  You’ll need to either create a new module or add the code below from mca_artwork.module to the .module file of an existing one.  I created a new module called “MCA Artwork” and placed it in my project’s modules/custom directory.  My file structure looks like this:

- mca_artwork - mca_artwork.info.yml - mca_artwork.module

Here’s my mca_artwork.info.yml:

name: MCA Artwork type: module description: Customizes Artwork Display core: 8.x package: Custom

And here’s the mca_artwork.module file, where the magic happens:

<?php   /** * @file * Contains mca_artwork.module. */   use Drupal\Core\Form\FormStateInterface;   /** * Implements hook_form_FORM_ID_alter(). * * Alters the artist options on artwork pages. */ function mca_artwork_form_views_exposed_form_alter(&$form, FormStateInterface $form_state, $form_id) {   // If not the view we are looking, move on if ($form['#id'] != 'views-exposed-form-the-art-block-1') { return FALSE; }   // Query nodes $storage = Drupal::getContainer()->get('entity_type.manager')->getStorage('node'); $nids = $storage->getQuery();   // Gather published artist nodes and sort by title $nids = $nids->condition('type', 'artist') ->condition('status', 1) ->sort('title') ->execute();   // If there are no nodes, move on if (!$nids) { return FALSE; }   // Start building out the options for our select list $options = []; $nodes = $storage->loadMultiple($nids);   // Push titles into select list foreach ($nodes as $node) { $options[$node->id()] = $node->getTitle(); }   // Start building out our new form element $artist_field = 'artist'; $form[$artist_field]['#type'] = 'select'; $form[$artist_field]['#multiple'] = FALSE;   // Specify the empty option for our select list $form[$artist_field]['#empty_option'] = t('Artist');   // Add the $options from above to our select list $form[$artist_field]['#options'] = $options; unset($form[$artist_field]['#size']); }

If you read through the comments in the above code, you’ll see we are essentially doing the following things:

  1. We load all published artist nodes, sorted by name
  2. We create an array of Artist names keyed by node id. These will be our select list options.
  3. We change the existing artist form input to a select list and populate it with our new options array.

It turns out this is a common UX need in Drupal 8 Views.  My comrade at Aten, John Ferris, also ran across this problem for a recently-launched Drupal 8 project he worked on for the Center for Court Innovation, a non-profit seeking to to create positive reforms in the criminal justice system.  The code snippet for The Octopus Initiative was largely adapted from his work on the Center for Court Innovation.

For the Center for Court Innovation site, the Chosen JS library was added to provide an interface for searching through a larger list of items.

In summary, the module I created for The Octopus Initiative provides a useful UX over what Drupal Views offers out-of-the-box.  If you have a larger number of items in your select list, then you may consider adding something like Chosen JS to make it easier to sort through, as was done for the Center for Court innovation.  Whatever you do, don't leave your users stranded with an empty text element!

Acro Media: Introducing the Urban Hipster (UH) Demo for Drupal Commerce 2

Tue, 02/06/2018 - 11:51

Because Drupal has so many options and so much flexibility, it can be a bit intimidating to newcomers. It doesn't show you examples of what it can do, and it kind of seems to do nothing by default. We realized people needed to be shown just how cool it really is, so we built a demo site to do just that. Check it out here: http://commerce.acromedia.com

The setup

We focused on making it only with out-of-the-box stuff, restricting ourselves to the features and functionality that exist within Drupal Commerce ecosystem itself. No custom code or modifications other than normal theming. That's right: Using only what's available out there now, we came up with a pretty amazing ecommerce site, if we do say so ourselves.

One caveat: we did make a custom theme for the demo, which you'll probably want to do anyway. There are the default Drupal themes, but most people are going to want to create a custom one. But that's a relatively simple task for a front-end developer; you don't need a back-end developer as well.

All the other setup can be done through basic Drupal UI point-and-click configuration. If you're somewhat savvy with configuring Drupal, you can do it all yourself in a very short time, and produce a truly phenomenal site.

Sometimes you need some guidance

Many people wonder how it could possibly be so easy. We've been getting a lot of questions like, "How did you build this big amazing catalog?" And the truth is we didn't actually do that much. We just enabled and configured the functionality that was already available. Drupal has this great Search API (and associated modules, Solr and Facets) that lets you do a ton of search customizations for anything that's stored in Drupal (blog articles, users, products, whatever), so all you have to do is tweak the configurations and you get this amazing catalog.

It's not that hard, but it's not that intuitive either; you just need a little guidance and direction. Sometimes just seeing an example is enough to make you realize how easy it can be. And that's exactly what the demo provides. It features a checkout, tax configurations, some shipping options, and even a sample payment system. You can click around and check it out without fear of breaking things, the database resets every night.

When you go to the demo site initially, a popup is preseted with a bunch of guided tours, but you are of course free to ignore that and just play around with it yourself. We're also releasing a bunch of tutorial videos to help you. We also have a resources page that shows a lot of the different features you can check out.

Plus, all the source code for the demo, including the custom theme, is available on GitHub. Within the repo is a full database dump so you can set up the entire thing yourself locally (see the README.md). AND one of the Commerce module maintainers, Bojan Živanović, is taking some of the content and configuration from the demo and turning it into an installable demo store module.

It's seriously awesome. Check it out!

Chat with us

If you'd like a personalized tour to discuss how Drupal Commerce fits into your omnichannel solution, give us a shout. We're happy to show and tell.

Web Wash: How to Use Webform Predefined Options in Drupal 8

Tue, 02/06/2018 - 08:00

Webform allows you to create powerful forms in Drupal without writing any custom code. One feature I want to show you today is predefined options.

Predefined options ease the creation of forms by offering common lists such as days, months, time zones, titles, etc...

For example, if you want to add a select list where users choose a country, instead of manually entering in all countries yourself, use the predefined one that comes with the module.

Webform comes with around 30 predefined lists which can be added to radio buttons, checkboxes, select list and menus. You can also create your own.

If you have a website that will use the same set of options on multiple forms, look at creating a predefined options list to save time.

In this tutorial, you'll learn how to create and use predefined options.

Dries Buytaert: To PESOS or to POSSE?

Tue, 02/06/2018 - 04:43

Yesterday I shared that I uninstalled the Facebook application from my phone. My friend Simon Surtees was quick to text me: "I for one am pleased you have left Facebook. Less Cayman Island pictures!". Not too fast Simon. I never said that I left Facebook or that I'd stop posting on Facebook. Plus, I'll have more Cayman Islands pictures to share soon. :)

As a majority of my friends and family communicate on Facebook and Twitter, I still want to share updates on social media. However, I believe I can do it in a more thoughtful manner that allows me to take back control over my own data. There are a couple of ways I could go about that:

  • I could share my status updates and photos on a service like Facebook or Twitter and then automatically download and publish them to my website.
  • I could publish my status updates and photos on my website first, and then programmatically share them on Facebook, Twitter, etc.

The IndieWeb movement has provided two clever names for these models:

  1. PESOS or Publish Elsewhere, Syndicate (to your) Own Site is a model where publishing begins on third party services, such as Facebook, and then copies can be syndicated to your own site.
  2. POSSE or Publish (on your) Own Site, Syndicate Elsewhere is a publishing model that begins with posting content on your own site first, then syndicating out copies to third party services.


Here is the potential impact of each strategy:

PESOS POSSE Dependence A 3rd party is a required intermediary within the PESOS approach. When the 3rd party platform is down or disappears completely, publishers lose their ability to post new content or retrieve old content. No dependence, as the 3rd party service is an optional endpoint, not a required intermediary. Canonical Non-canonical: the data on the 3rd party is the original and copies on your domain may have to cite 3rd party URLs. Canonical: you have full control over URLs and host the original data. The 3rd party could cite the original URL. Quality Pulling data from 3rd parties services could reduce its quality. For example, images could be degraded or downsized. Full control over the quality of assets on your own site. Ease of use, implementation and maintenance 3rd party platforms make it really easy for users to publish content and you can still benefit from that. For example, you can easily upload images from your phone. The complexity inherent to the PESOS approach includes developing an infrastructure to curate archival copies to your own domain. The POSSE strategy can be significantly more work for the site owner, especially if you want comparable ease of use to 3rd party platforms. A higher level of technical expertise and time investment is likely required.

The goal of this analysis was to understand the pros and cons of how I can own my own content on https://dri.es. While PESOS would be much easier to implement, I decided to go with POSSE. My next step is to figure out my "POSSE plan"; how to quickly and easily share status updates on my Drupal site, how to syndicate them to 3rd party services, how to re-organize my mailing list and RSS feed, and more. If you have any experience with implementing POSSE, feel free to share your takeaways in the comments.

Valuebound: How to Implement Faceted search with Solr in Drupal 8?

Mon, 02/05/2018 - 23:48

Sometimes we need to implement a search functionality that looks similar to some of the renowned e-commerce site search (like Amazon, Flipkart and so on) as per the category, types and all.  For this kind of search, Facet is a good option. So what exactly Faceted search is?

Facet is a module, in Drupal 8, that provides a facility to arrange all the search results as per the category. Basically, it is an arrangement of search results based on categories, content type on indexed terms and content type.

Why we use Facets?

There are various reasons a Facet can be used:

  • It provides a drill-down search facility.
  • It can be used with default search and Solr as well.
  • It shows a number of item count for each…

Roy Scholten: Core strengths

Mon, 02/05/2018 - 18:28
06 Feb 2018 Core strengths

The Designing Connected Content book has arrived. “Plan and model digital products for today and tomorrow.” I have yet to dive in but I see Drupal screenshots and lists of field types like entity reference, long text (formatted), boolean, number (float), etc.

Today a content strategist collegue asked me about that list builder thing in Drupal. Show items of type x, filtered by y, sorted by x and only show fields 1, 3 and 6 of each item. And is it available for Drupal 8 as well?

Yes, that’s 1. Field UI and 2. Views module, which are both part of the Drupal core package.

We take Drupal core features for granted that other systems are still struggling with. They are also features people struggle with in Drupal because of hard to use user interfaces. I would love to see research and design work happen around how we can improve Field UI and Views UI.

Tags book designing connected content drupalplanet content modeling

aleksip.net: Using Pattern Lab in Drupal 7 theme development

Mon, 02/05/2018 - 13:09
After working almost exclusively with the latest and greatest version of Drupal since 2015, I am now facing some Drupal 7 projects. I didn’t want to give up using atomic design and Pattern Lab, so I decided to create a .tpl.php PatternEngine for Pattern Lab.

Ixis.co.uk - Thoughts: Last Month in Drupal - January 2018

Mon, 02/05/2018 - 06:00
Finally, after what felt like months, January has come to an end. This means it is time for our monthly blog series, Last Month in Drupal. January has seen a plethora of Drupal news and here we pick out the best bits just for you.

Pages