Drupal

Book Blocks

New Drupal Modules - 10 September 2018 - 10:30am

The built-in Book module has a couple of useful blocks but they were not what I needed. Here are a few more blocks that you might find useful as well. There is even one with the table of contents, navigation and add links all in one.

Categories: Drupal

Entity Router

New Drupal Modules - 10 September 2018 - 8:14am

Lookup entities by their paths/redirects and convert to a given format.

Use curl -X GET '/entity/router?path=<PATH>&_format=<FORMAT>'

- The value of the <PATH> can be an internal path of an entity, the redirect or its alias.

Examples:

Categories: Drupal

RedirectLess

New Drupal Modules - 10 September 2018 - 7:41am

Why sending a redirect when we can send the page behind the redirect and make the response faster and much more seamless for the client? This is what the RedirectLess module is for. It catches by default redirect responses for the HTTP redirects Found, See Other and Temporary Redirect and returns to the client the response behind them and takes care of updating the URL in the browser's address bar.

There is zero configuration needed.

Categories: Drupal

Views flexible pager

New Drupal Modules - 10 September 2018 - 7:37am

This module allows you to specify a specific number of results to show on the first page of your view.

When enabling the module, you will see an extra option 'Paged output, full pager, optional different number of items on first page' within the pager options of your view. You can then set the number of Initial items to show the view.

Categories: Drupal

Annertech: D is for Darmstadt; D is for Drupal Europe

Planet Drupal - 10 September 2018 - 5:38am
D is for Darmstadt; D is for Drupal Europe The Annertechies have been taking to the air for the past two days flying into Frankfurt en route to Darmstadt for Drupal Europe. As ever, we have brought our bags of knowledge with us to share out our goodies. Find out more about the sessions we're giving and other things we'll be doing at Drupal Europe.
Categories: Drupal

Addressfield Geosuggest

New Drupal Modules - 10 September 2018 - 1:53am

Provides a widget to fill out an address field using the ubilabs geosuggest react component.

Categories: Drupal

Weather City

New Drupal Modules - 10 September 2018 - 12:35am

Add a block with your city's time in a quick and easy way.
To configure it you must read the README.txt file

Categories: Drupal

Entity Reference Ajax Formatter

New Drupal Modules - 9 September 2018 - 9:33pm
ABOUT

Entity Reference Ajax Formatter provides a new configurable field formatter for entity reference fields. This formatter lets you select how many entities to render as well as providing some extra sorting options for display only. However the standout feature is an AJAX enabled Load More link. This lets you initially load say 3 references and then if the user wants to see more, click the link and display more inline.

The widget has the same option of selecting the desired view mode to render the entities with and provides 4 extra settings:

Categories: Drupal

Agiledrop.com Blog: AGILEDROP: Michel van Velde in the shoes of one of Deloitte's Fast 50 companies

Planet Drupal - 9 September 2018 - 5:50pm
Agiledrop is highlighting active Drupal community members through a series of interviews. Learn who are the people behind Drupal projects.  This week we talked with Michel van Velde. Read about what his company has achieved during one of the worst economic crisis in decades, what are his biggest contributions to Drupal community, and what his next personal project will be (a hint: it will involve drones).   1. Please tell us a little about yourself. How do you participate in the Drupal community and what do you do professionally? Michel van Velde, a proud father of two children, a daughter… READ MORE
Categories: Drupal

Joachim's blog: Drupal Code Builder: the analytical, adaptive code generator

Planet Drupal - 9 September 2018 - 2:26pm

It's now just over 10 years since webchick handed maintainership of the Module Builder project over to me. I can still remember nervously approaching her at the end of a day at DrupalCon 2008, outside the building where people were chatting, and asking her if she'd had time to look at the patches I'd posted for it. I was at my first DrupalCon; she'd just been named as the core co-maintainer for the work about to start on Drupal 7. No, she hadn't, she said, and she instantly came to the conclusion that she'd never have the time to look at them, and so got her laptop out of her rucksack and there and then edited the project node to make me the maintainer.

Given the longevity of the project, I am often surprised when I talk to people that they don't know what its crucial advantage is over the other Drupal code generating tools that now also exist. Drupal Code Builder, as it's now called, is fundamentally different from Drupal Console's Generator command, and the Drupal Code Generator library that’s included in Drush 9.

I feel that perhaps this requires a buzzword, to make it more noticeable and memorable.

So here is one: Drupal Code Builder is an analytical code generator.

I'm going to add a second one: the Drupal Code Builder Drush commands and Module Builder (which still exists, though is now just module that provides a Drupal-based UI for the Drupal Code Builder library) are adaptive.

What do I mean by those?

When you first install Drupal Code Builder, it has no information about Drupal hooks, or plugin types, or services. There is no data in the codebase on how to generate a hook_form_alter() implementation, or a Block plugin, or how to inject the entity_type.manager service.

Before you can generate code, you need to run a command or submit an admin form which will analyse your entire codebase, and store the resulting data on hooks, plugin types, services, and other Drupal structures (the list of what is analysed keeps growing.).

The consequence of this is huge: Drupal Code Builder is not limited to core hooks, or to the hooks that it's been programmed for. Drupal Code Builder knows all the hooks in your codebase: from core, from contrib module, even from any of your own custom code that invents hooks.

Now repeat that statement for plugin types, for services, and so on.

And that analysis process can, and should, be repeated when you download a new module, because then any Drupal structures (hooks, plugin types, etc) that are defined in new modules gets added to the list of what Drupal Code Builder can generate.

This means that you can use Drupal Code Builder to do something like this:

  1. Generate a new plugin type. This creates a plugin manager service class and declaration, an annotation class that defines the plugin annotation, and an interface and base class for the plugins.
  2. Re-run DCB's analysis.
  3. Generate a plugin of the type you've just made.

When I say that this technique of analysis makes Drupal Coder Builder more powerful than other code generators, I'm not even blowing my own trumpet: the module I was handed in 2008 did the same. Back then in the Drupal 6 era is needed to connect to drupal.org's CVS repository to download the api.php files that document a module's hooks (which is why the Drush command for updating the code analysis prior to Drush 9 is called mb-download). For Drupal 7, the api.php files were moved into the core Drupal codebase, so from that point the process would scan the site's codebase directly. For Drupal 8, I added lots more code analysis, of plugin types and services, but still, the original idea remains: Drupal Code Builder knows how to detect Drupal structures, so it can know more structures than can be hardcoded.

This analysis can get pretty complex. While for hooks, it's just a case of running a regex on api.php files, for detecting information about plugin types, all sorts of techniques are used, such as searching the class parentage of all the plugins of a type to try to guess whether there is a plugin base class. It’s not always perfect, and it could always use more refinement, but it’s a more powerful approach than hardcoding a necessarily finite number of cases. (If only plugin types were declared in some way, or if the documentation for them were systematic in the way hook documentation is, this would all be so much simpler, and much more importantly, it would be more accurate!)

My second buzzword, that UIs for Drupal Code Builder are adaptive, describes the way that neither of the Drush command nor the Drupal module need to know what Drupal Code Builder can build. They merely know the API for describing properties, and how to present them to the user, to then pass the input values to Drupal Code Builder to get the generated code.

This is analogous to the way that Form API doesn’t know anything about a particular form, just about the different kinds of form elements.

This isn’t as exciting or indeed relevant to the end-user, but it does mean that development on Drupal Code Builder can move quickly, as adding new things to generate doesn’t require coordinated releases of software packages for the UI. In fact, I think nearly every new release of Drupal Code Builder has featured some sort of new code generating functionality, while keeping the API the same.

For example, this used to be the UI for adding a route on Drupal and Drush:

A later release of Drupal Code Builder turned the UI into this, without the Drush command or Module Builder needing their code to be updated:

Similarly, an even later version of Drupal Code Builder added code analysis to detect all top-level admin menu items, and so the admin settings form generation now lets you pick where to place the form in the menu.

It would be nice to think that a couple of buzzwords could gain Drupal Code Builder more attention and more users, but I fear that Drupal Console’s generator has got rather more traction in Drupal 8, despite its huge limitation. It’s disappointing that Drush has now added a third code generator to the mix, to even further dilute the ecosystem, and that it’s just as limited by hardcoding.

So where do we go from here?

Well, people get attached to UIs, but they don’t care much about what powers them, especially in this day and age of Composer, where adding dependencies no longer creates an imposition on the end-user.

So I suggest the following: the code analysis portion of Drupal Code Builder could be extracted to a new package. It doesn’t depend on anything on the code generation side, so that should be fairly simple. It provides an API that supports analysis being run in batches, which could maybe do with being spruced up, but it’s good enough for a 1.0.0 version for now.

Then, any code generating system would be able to use it. Both Console and Drush could replace their hardcoded lists of hooks and plugins with analytical data, while keeping the commands they expose to the end-user unchanged.

I’ll be at DrupalEurope in Darmstadt, where I’ll be running a BoF to discuss where we go next with code generation on Drupal.

Categories: Drupal

Views dates

New Drupal Modules - 9 September 2018 - 1:45pm

This module provides different filters and arguments for date field for views infrastructure.
The work is in progress...

Categories: Drupal

Drop Guard: Win a free Drop Guard update package!

Planet Drupal - 9 September 2018 - 9:15am
Win a free Drop Guard update package!

 

 

Join the short quiz Drupal Planet Drupal Events announcements
Categories: Drupal

Commerce Payment Refund

New Drupal Modules - 9 September 2018 - 8:47am

Since the payment submodule of commerce2.x dose not support refund order state tracing, this module provide an entity to handle that.

Categories: Drupal

AimTell Integration

New Drupal Modules - 8 September 2018 - 2:06pm

Provides integration with the AimTell service.

Categories: Drupal

UUID extra

New Drupal Modules - 8 September 2018 - 11:49am

The module provides two main functionalitities

* A field formatter for UUID fields, so you can configure entity displays to show UUIDs
* A field widget for UUID fields, so you can copy UUIDs while editing content.

Categories: Drupal

Twitter Oauth

New Drupal Modules - 8 September 2018 - 11:26am

Allows for creation of custom blocks which display results from the Twitter search API. Once installed, this module adds a custom block type called "Twitter Search". This block allows you to use Twitter's standard search operators in order to specify what types of search results to pull back.

Categories: Drupal

REST perview beautifier

New Drupal Modules - 8 September 2018 - 10:29am

This module provides a better preview display for Views REST export by "beautifying" JSON and xml output. It's fully based on javascipt and uses external js libraries.

Known issue:
A page refresh is needed when you change format settings (eg: switching from json to xml).

Categories: Drupal

mark.ie: Creating a Card Component in PatternLab and Mapping to Drupal the "right" way

Planet Drupal - 8 September 2018 - 5:51am
Creating a Card Component in PatternLab and Mapping to Drupal the "right" way

Yes, I know, there's more than one way to integrate PatternLab with Drupal. Here's how I create a card component and map it to Drupal.

markconroy Sat, 09/08/2018 - 13:51

Here's the task - create a card component with fields for:

  1. Card Image
  2. Card Title
  3. Card Body
  4. Card Link URL
  5. Card Style (sets a colour for a border-top on the card)
  6. Card Size (sets the width of the card)

In PatternLab, here's what our Twig file might look like (with explanations after it):

The classes array at the top allows us to set variations for our card, depending on values chosen by the editor. So, if there is an image, we add a class of .card--has-image; if a style is chosen, we add a class of that style, for example: .card--medium (I create options for small, medium, large, and full - with 'small' being the default - corresponding on large screens to a width within their container of 33%, 50% 66% and 100% respectively).

Next, we set our {{ element }}. This allows us to have the card wrapped in an a tag or a div tag. We check to see if the link field has been filled in and, if so, we use the a element, but if not, we use the div element instead. This will render HTML like one of the following:

Following this, we check if there is an image and, if so, we render our image div. Checking first allows us to have nice bem-style classes, but also means we don't end up rendering emtpy divs. Although, when it comes to Drupal, what's another div!

We then do the same for the title and body.

The funny looking part at the end about cache was inspired by an article about Drupal block cache bubbling by PreviousNext. The specific code came from this Drupal.org issue. The PreviousNext article says to render the {{ content }} variable with our fields set to 'without', because without the {{ content }} variable rendering, caching is not working properly (I don't know enough about caching to explain more). However, on a content type with loads of fields, it's very cumbersome to add every field in with {{ content|without('field_image', 'field_tags', 'field_other', etc) }}. Instead, I put that {{ catch_cache = content|render }} at the bottom of each of my content patterns - node, block, paragraphs, etc, then don't need to add it later in Drupal.

The SCSS for this looks like this:

We can do the site building very easily with the paragraphs module. Create a paragraph of type card, add the fields

  1. Card Image - media image
  2. Card Title - text (plain)
  3. Card Body - text (long, formatted)
  4. Card Link URL - link
  5. Card Style (sets a colour for a border-top on the card) - text (list)
  6. Card Size (sets the width of the card) - text (list)

Then, in our paragraph--card.html.twig file, we write the following code:

What the above does is checks if the card paragraph has values in its fields and then sets variables if it does. This means we don't render empty divs.

You will also notice that I render each fields full content for image, title, and body. This is to keep all the Drupal goodness we have in the attributes object - for accessibility and to make sure things like contextual links/quick edit still work.

You will often see the same template written like this:

I find doing that leads to fields such as {{ content.field_image }} always returning true because of Drupal's rendering system. So, even if we don't have an image, we'll still have an image div, whereas doing an explicit check before we {% include %} our variable seems much safer.

That's it - PatternLab + Drupal integrated beautifully (I think) the "right" way (according to me - you might differ).

Categories: Drupal

Workbench Tabs

New Drupal Modules - 7 September 2018 - 1:47pm

Workbench Tabs integrates local task tabs and Drupal messages into the Toolbar. This means that custom themes don't need to place and style the local tasks, prevents long Drupal messages from breaking the layout during development, and improves editorial usability by placing the "Edit", "View", and "Revisions" tabs in a consistent location.

Categories: Drupal

Rules for Teams

New Drupal Modules - 7 September 2018 - 11:29am

Provides a way for the Rules module to send messages to Microsoft Teams. Only a limited subset of what is available in Teams is currently supported.

Categories: Drupal

Pages

Subscribe to As If Productions aggregator - Drupal