Drupal News

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

Main Drupal Feed - Tue, 02/06/2018 - 13: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?

Main Drupal Feed - Tue, 02/06/2018 - 09: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.

Appnovation Technologies: Simple Website Approach Using a Headless CMS: Part 1

Main Drupal Feed - Tue, 02/06/2018 - 08:00
Simple Website Approach Using a Headless CMS: Part 1 I strongly believe that the path for innovation requires a mix of experimentation, sweat, and failure. Without experimenting with new solutions, new technologies, new tools, we are limiting our ability to improve, arresting our potential to be better, to be faster, and sadly ensuring that we stay rooted in systems, processes and...

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

Main Drupal Feed - Tue, 02/06/2018 - 04: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

Main Drupal Feed - Mon, 02/05/2018 - 23: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

Varbase Theme

Drupal Themes - Mon, 02/05/2018 - 11:48

Tanara Theme for Drupal

Drupal Themes - Sun, 02/04/2018 - 10:36

Tanara Theme for Drupal

Kanekes Theme for Drupal

Drupal Themes - Sun, 02/04/2018 - 10:31

Kanekes Theme for Drupal

Acquia Lightning Blog: Using the Configuration Installer with Lightning

Main Drupal Feed - Fri, 02/02/2018 - 17:07
Using the Configuration Installer with Lightning Adam Balsam Fri, 02/02/2018 - 12:07

Installing a site with existing config has been a bit of a moving target in Drupal 8. At different times, I've recommended at least three different approaches. I won't go into too much detail, but basically we've used the following at times:

  • Manually change site UUIDs (Sloppy)
  • Use --config-dir option with drush site-install (Only supports minimal profile)
  • Use patch from Issue #2788777 (Config needs to be stored in profile directory)

You can read more about previous approaches here. The one thing that hasn't changed is the user story:

As a user I want to be able to install Drupal from a package of configuration that is maintained in git.

The issue that most closely addresses this user story is #1613424 "Allow a site to be installed from existing configuration". That issue is currently postponed on another thorny issue which involves the special way that Drupal treats dependencies of profiles. In the meantime, alexpott has provided a standalone install profile that handles installing a site from existing config. This is the Configuration installer profile.

It takes a minute to wrap your head around the concept because when you use the Configuration installer profile, you don't end up with a site running the Configuration installer profile. At the end of the install, your site will be running the profile that is defined in the config you provided the Config installer.

So for a new project, you would initially install using the profile of your choice. Then, once you have exported your config, you would use the Config installer for subsequent installs.

Considerations
  • For ease of use, your settings file should not be writable by the installer and should not contain the install_profile key. If your settings file contains your profile, you'll get an exception when trying to run the install. And if it is writable, Drupal will write that value every time you do install.
  • The Config installer profile requires two patches in order to work properly with Drush 9.
  • Config must not have direct dependencies on a profile. Lightning 3.0.1 requires the patch in issue #2933445 to be compliant.
Instructions
  1. For new sites, install using the profile or sub-profile of choice.
$ drush site-install lightning
  1. Ensure that the install_profile key is not present in your settings.php file. Drupal will write this value by default, but it is not required in Drupal >= 8.3.0. You can prevent Drupal from writing it by disallowing write access to the settings file. If the installer wrote the profile during initial installation, you can manually delete it. Then revoke write access:
$ chmod 444 docroot/sites/default/settings.php
  1. Define the following patches in your composer.json file if you are using config_installer < 1.6.0 and/or lightning < 3.0.2.
"patches": { "drupal/config_installer": { "2916090 - Support Drush 9": "https://www.drupal.org/files/issues/drush9-support-2916090-6.patch", "2935426 - Drush 9: Call to undefined function drush_generate_password": "https://www.drupal.org/files/issues/config_installer-drush_9_call_undefined_function_drush_generate_password-2935426-2.patch" }, "drupal/lightning_layout": { "2933445 - user.role.layout_manager has dependency on Lightning": "https://www.drupal.org/files/issues/2933445.patch" } },
  1. Add the Configuration installer profile to your codebase.
$ composer require drupal/config_installer
  1. Export your site's configuration.
$ drush config-export
  1. Use the Configuration installer profile in all subsequent site installs. The resulting install will run on the profile used in step 1.
$ drush site-install config_installer

drunken monkey: Some more (updated) tips for PhpStorm live templates

Main Drupal Feed - Fri, 02/02/2018 - 11:19

A few years ago I started using the PhpStorm IDE for PHP development, was immediately smitten and, after a bit of use, wrote a blog post with some tips I found for makig better use of the tools PhpStorm gives you.

In the four years since then there have been some new developments. Firstly, of course, Drupal 8 was finally released – and, consequently, the one complaint I had back in 2013 about the $MODULE$ variable only working in the module file itself became more of a problem. (Also, I added one more live template that's very useful for Drupal 8.)
But secondly, a few weeks ago PhpStorm finally added scripting support for live templates, so it's now possible to write more powerful templates that way – and fix the $MODULE$ variable.

The new di live template

In general, when writing OOP code for Drupal 8 (that is, for almost all Drupal 8 code) you should use dependency injection as much as possible. There's several different styles for doing that, I'm using one which uses setter methods and calls them in create() (instead of adding all injected objects to the constructor). This makes inheritance easier and keeps the constructor “cleaner” – and becomes much easier with a good live template:

  /**
   * The $NAME$.
   *
   * @var $INTERFACE$|null
   */
  protected $$$PROP_NAME$;

  /**
   * Retrieves the $NAME$.
   *
   * @return $INTERFACE$
   *   The $NAME$.
   */
  public function get$UC_PROP_NAME$() {
    $plugin->set$UC_PROP_NAME$($container->get('$SERVICE$'));

    return $this->$PROP_NAME$ ?: \Drupal::service('$SERVICE$');
  }

  /**
   * Sets the $NAME$.
   *
   * @param $INTERFACE$ $$$VAR_NAME$
   *   The new $NAME$.
   *
   * @return $this
   */
  public function set$UC_PROP_NAME$($INTERFACE$ $$$VAR_NAME$) {
    $this->$PROP_NAME$ = $$$VAR_NAME$;
    return $this;
  }

Variable definitions:

Name Expression Skip if defined VAR_NAME N SERVICE N INTERFACE clipboard() Y NAME underscoresToSpaces(VAR_NAME) Y UC_NAME underscoresToCamelCase(VAR_NAME) Y UC_PROP_NAME capitalize(PROP_NAME) Y

Usage:

  1. Copy the service interface's FQN to your clipboard.
  2. Put the service ID either into a secondary clipboard (e.g., middle mouse button on Linux) or remember it.
  3. Execute live template (at the position where you want the getter and setter).
  4. Input variable name (in snake_case), then input service name.
  5. Move the property definition and the create() line (temporarily stored as the first line of the getter in the template) to their appropriate places.
  6. In the code, alway use the getter method for accessing the service.
Fixing the $MODULE$ variable

Since the code for this is quite complex, we better just put it into a separate file. So, first download the script file and save it to some known location, then simply use the (absolute) path to the script file as the argument for groovyScript(), like this:

This can be used for all the live templates that contain a $MODULE$ variable (though it will, of course, be less useful for the procedural ones, than for the simple m template).

Pages