Drupal Planet

Subscribe to canal de noticias Drupal Planet
Drupal.org - aggregated feeds in category Planet Drupal
Actualizado: hace 18 mins 50 segs

PreviousNext: Reusable style guide components using field formatters and twig embed

Jue, 11/16/2017 - 00:32
Share:

At PNX, style guide driven development is our bag. It’s what we love: building a living document that provides awesome reference for all our front end components. And Drupal 8, with its use of Twig, complements this methodology perfectly. The ability to create a single component, and then embed that component and its markup throughout a Drupal site in a variety of different ways without having to use any tricks or hacks is a thing of beauty.

by Jack Taranto / 16 November 2017 Create a component

For this example we are going to use the much loved collapsible/accordion element. It’s a good example of a rich component because it uses CSS, JS, and Twig to provide an element that’s going to be used everywhere throughout a website.

To surmise the component it’s made up of the following files:

collapsible.scss collapsible.widget.js collapsible.drupal.js collapsible.twig collapsible.svg

The .scss file will end up compiling to a .css file, but we will be using SASS here because it’s fun. The widget.js file is a jQuery UI Widget Factory plugin that gives us some niceties - like state. The drupal.js file is a wrapper that adds our accordion widget as a drupal.behavior. The svg file provides some pretty graphics, and finally the twig file is where the magic starts.

Let’s take a look at the twig file:

{{ attach_library('pnx_project_theme/collapsible') }} <section class="js-collapsible collapsible {{ modifier_class }}"> <h4 class="collapsible__title"> {% block title %} Collapsible {% endblock %} h4> <div class="collapsible__content"> {% block content %} <p>Curabitur blandit tempus porttitor. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Morbi leo risus, porta ac consectetur ac, vestibulum at eros. Praesent commodo cursus magna, vel scelerisque nisl consectetur et. Fusce dapibus, tellus ac cursus commodo, tortor mauris condimentum nibh, ut fermentum massa justo sit amet risus.p> {% endblock %} div> section>

This is a standard-ish BEM based component. It uses a js-* class to attach the widget functionality. We also have a {{ modifier_class }} variable, that can be used by kss-node to alter the default appearance of the collapsible (more on this later). There are two elements in this component title and content. They are expressed inside a twig block. What this means is we can take this twig file and embed it elsewhere. Because the component is structured this way, when it’s rendered in its default state by KSS we will have some default content, and the ability to show it's different appearances/styles using modifier_class.

Our twig file also uses the custom Drupal attach_library function which will bring in our components CSS and JS from the following theme.libraries.yml entry:

collapsible: css: component: src/components/collapsible/collapsible.css: {} js: src/components/collapsible/collapsible.widget.js : {} src/components/collapsible/collapsible.drupal.js : {} dependencies: - core/jquery - core/drupal - core/jquery.once - core/jquery.ui - core/jquery.ui.widget

This is a pretty meaty component so it’s got some hefty javascript requirements. Not a problem in the end as it’s all going to get minified and aggregated by Drupal Cores library system.

And there we have it - a rich javascript component. It’s the building block for all the cool stuff we are about to do.

Use it in a field template override

As it stands we can throw this component as-is into KSS which is nice (although we must add our css and js to KSS manually, attach_library() won’t help us there sadly - yet), but we want drupal to take advantage of our twig file. This is where twigs embed comes in. Embed in twig is a mixture of the often used include, and the occasionally used extend. It’s a super powerful piece of kit that lets us do all the things.

Well these things anyway: include our twig templates contents, add variables to it, and add HTML do it.

Because this is an accordion, it’s quite likely we’ll want some field data inside it. The simplest way to get this happening is with a clunky old field template override. As an example I’ll use field--body.html.twig:

{% for item in items %} {% embed '@pnx_project_theme/components/collapsible/collapsible.twig' %} {% block title %} {{ label }} {% endblock %} {% block content %} {{ item.content }} {% endblock %} {% endembed %} {% endfor %}

Here you can see the crux of what we are trying to achieve. The collapsible markup is specified in one place only, and other templates can include that base markup and then insert the content they need to use in the twig blocks. The beauty of this is any time this field is rendered on the page, all the markup, css and js will be included with it, and it all lives in our components directory. No longer are meaty pieces of markup left inside Drupal template directories - our template overrides are now embedding much richer components.

There is a trick above though, and it’s the glue that brings this together. See how we have a namespace in the embed path - all drupal themes/modules get a twig namespace automatically which is just @your_module_name or @your_theme_name - however it points to the theme or modules templates directory only. Because we are doing style guide driven development and we have given so much thought to creating a rich self-contained component our twig template lives in our components directory instead, so we need to use a custom twig namespace to point there. To do that, we use John Albins Component Libraries module. It lets us add a few lines to our theme.info.yml file so our themes namespace can see our component templates:

component-libraries: pnx_project_theme: paths: - src - templates

Now anything in /src or /templates inside our theme can be included with our namespace from any twig template in Drupal.

Use it in a field formatter

Now let’s get real because field template overrides are not the right way to do things. We were talking about making things DRY weren’t we?

Enter field formatters. At the simple end of this spectrum our formatter needs an accompanying hook_theme entry so the formatter can render to a twig template. We will need a module to give the field formatter somewhere to live.

Setup your module file structure as so:

src/Plugin/Field/FieldFormatter/CollapsibleFormatter.php templates/collapsible-formatter.html.twig pnx_project_module.module pnx_project_module.info.yml

Your formatter lives inside the src directory and looks like this:

<?php namespace Drupal\pnx_project_module\Plugin\Field\FieldFormatter; use Drupal\Core\Field\FieldItemListInterface; use Drupal\Core\Field\FormatterBase; use Drupal\Core\Form\FormStateInterface; /** * A field formatter for trimming and wrapping text. * * @FieldFormatter( * id = "collapsible_formatter", * label = @Translation("Collapsible"), * field_types = { * "text_long", * "text_with_summary", * } * ) */ class CollapsibleFormatter extends FormatterBase { /** * {@inheritdoc} */ public function viewElements(FieldItemListInterface $items, $langcode = NULL) { $elements = []; foreach ($items as $delta => $item) { $elements[$delta] = [ '#theme' => 'collapsible_formatter', '#title' => $items->getFieldDefinition()->getLabel(), '#content' => $item->value, '#style' => NULL, ]; } return $elements; } }

And the hook_theme function lives inside the .module file:

<?php /** * @file * Main module functions. */ /** * Implements hook_theme(). */ function pnx_project_module_theme($existing, $type, $theme, $path) { return [ 'collapsible_formatter' => [ 'variables' => [ 'title' => NULL, 'content' => NULL, 'style' => NULL, ], ], ]; }

Drupal magic is going to look for templates/collapsible-formatter.html.twig in our module directory automatically now. Our hook_theme template is going to end up looking pretty similar to our field template:

{% embed '@pnx_project_theme/components/collapsible/collapsible.twig' with { modifier_class: style } %} {% block title %} {{ title }} {% endblock %} {% block content %} {{ content }} {% endblock %} {% endembed %}

Now jump into the field display config of a text_long field, and you’ll be able to select the collapsible and it’s going to render our component markup combined with the field data perfectly, whilst attaching necessary CSS/JS.

Add settings to the field formatter

Let's take it a bit further. We are missing some configurability here. Our component has a modifier_class with a mini style (a cut down smaller version of the full accordion). You'll notice in the twig example above, we are using the with notation which works the same way for embed as it does for include to allow us to send an array of variables through to the parent template. In addition our hook_theme function has a style variable it can send through from the field formatter. Using field formatter settings we can make our field formatter far more useful to the site builders that are going to use it. Let's look at the full field formatter class after we add settings:

class CollapsibleFormatter extends FormatterBase { /** * {@inheritdoc} */ public function viewElements(FieldItemListInterface $items, $langcode = NULL) { $elements = []; foreach ($items as $delta => $item) { $elements[$delta] = [ '#theme' => 'collapsible_formatter', '#title' => !empty($this->getSetting('label')) ? $this->getSetting('label') : $items->getFieldDefinition()->getLabel(), '#content' => $item->value, '#style' => $this->getSetting('style'), ]; } return $elements; } /** * {@inheritdoc} */ public function settingsSummary() { $summary = []; if ($label = $this->getSetting('label')) { $summary[] = 'Label: ' . $label; } else { $summary[] = 'Label: Using field label'; } if (empty($this->getSetting('style'))) { $summary[] = 'Style: Normal'; } elseif ($this->getSetting('style') === 'collapsible--mini') { $summary[] = 'Style: Mini'; } return $summary; } /** * {@inheritdoc} */ public function settingsForm(array $form, FormStateInterface $form_state) { $form['label'] = [ '#title' => $this->t('Label'), '#type' => 'textfield', '#default_value' => $this->getSetting('label'), '#description' => t('Customise the label text, or use the field label if left empty.'), ]; $form['style'] = [ '#title' => t('Style'), '#type' => 'select', '#options' => [ '' => t('Normal'), 'collapsible--mini' => t('Mini'), ], '#description' => t('See Styleguide section 6.1 for a preview of styles.'), '#default_value' => $this->getSetting('style'), ]; return $form; } /** * {@inheritdoc} */ public static function defaultSettings() { return [ 'label' => '', 'style' => '', ]; } }

There's a few niceties there: It allows us to set a custom label (for the whole field), it automatically assigns the correct modifier_class, it links to the correct section in the style guide in the settings field description, and it adds a settings summary so site builders can see the current settings at a glance. These are all patterns you should repeat.

Let's sum up

We've created a rich interactive BEM component with its own template. The component has multiple styles and displays an interactive demo of itself using kss-node. We've combined its assets into a Drupal library and made the template - which lives inside the style guides component src folder - accessible to all of Drupal via the Component Libraries module. We've built a field formatter that allows us to configure the components appearance/style. Without having to replicate any HTML anywhere.

The component directory itself within the style guide will always be the canonical source for every version of the component that is rendered around our site.

Tagged Twig

Posted by Jack Taranto
Front end developer

Dated 16 November 2017

Add new comment

DrupalEasy: DrupalEasy Podcast 198 - Dave Hall - Drupal Distributions and Puppies

Mié, 11/15/2017 - 22:53

Direct .mp3 file download.

Dave Hall (skwashd), Managing Director, Dave Hall Consulting joins Mike Anello to talk about the current state of Drupal distributions and what the future may hold.

Interview DrupalEasy News Sponsors
  • Drupal Aid - Drupal support and maintenance services. Get unlimited support, monthly maintenance, and unlimited small jobs starting at $99/mo.
  • WebEnabled.com - devPanel.
Follow us on Twitter Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Mediacurrent: Content as the Common Language of Web Development

Mié, 11/15/2017 - 17:21

If there’s one thing I learned while attending DrupalCon Baltimore 2017 this past spring, it’s that those of us involved in building the web are only getting more and more specialized in how we help build it. It boggles the mind to witness the sheer amount of new session tracks, new technologies, new design patterns, and new discussions that come up each year at DrupalCon.

Drupal blog: An update on the Layout Initiative for Drupal 8.4/8.5

Mié, 11/15/2017 - 14:39

This blog has been re-posted with permission from Dries Buytaert's blog. Please leave your comments on the original post.

Now Drupal 8.4 is released, and Drupal 8.5 development is underway, it is a good time to give an update on what is happening with Drupal's Layout Initiative.

8.4: Stable versions of layout functionality

Traditionally, site builders have used one of two layout solutions in Drupal: Panelizer and Panels. Both are contributed modules outside of Drupal core, and both achieved stable releases in the middle of 2017. Given the popularity of these modules, having stable releases closed a major functionality gap that prevented people from building sites with Drupal 8.

8.4: A Layout API in core

The Layout Discovery module added in Drupal 8.3 core has now been marked stable. This module adds a Layout API to core. Both the aforementioned Panelizer and Panels modules have already adopted the new Layout API with their 8.4 release. A unified Layout API in core eliminates fragmentation and encourages collaboration.

8.5+: A Layout Builder in core

Today, Drupal's layout management solutions exist as contributed modules. Because creating and building layouts is expected to be out-of-the-box functionality, we're working towards adding layout building capabilities to Drupal core.

Using the Layout Builder, you start by selecting predefined layouts for different sections of the page, and then populate those layouts with one or more blocks. I showed the Layout Builder in my DrupalCon Vienna keynote and it was really well received:

8.5+: Use the new Layout Builder UI for the Field Layout module

One of the nice improvements that went in Drupal 8.3 was the Field Layout module, which provides the ability to apply pre-defined layouts to what we call "entity displays". Instead of applying layouts to individual pages, you can apply layouts to types of content regardless of what page they are displayed on. For example, you can create a content type 'Recipe' and visually lay out the different fields that make up a recipe. Because the layout is associated with the recipe rather than with a specific page, recipes will be laid out consistently across your website regardless of what page they are shown on.

The basic functionality is already included in Drupal core as part of the experimental Fields Layout module. The goal for Drupal 8.5 is to stabilize the Fields Layout module, and to improve its user experience by using the new Layout Builder. Eventually, designing the layout for a recipe could look like this:

Layouts remains a strategic priority for Drupal 8 as it was the second most important site builder priority identified in my 2016 State of Drupal survey, right behind Migrations. I'm excited to see the work already accomplished by the Layout team, and look forward to seeing their progress in Drupal 8.5! If you want to help, check out the Layout Initiative roadmap.

Special thanks to Angie Byron for contributions to this blog post, to Tim Plunkett and Kris Vanderwater for their feedback during the writing process, and to Emilie Nouveau for the screenshot and video contributions.

myDropWizard.com: Agencies: Don't keep passwords in your wiki!

Mié, 11/15/2017 - 14:16

You spend so much time writing secure code, and doing security updates, but you're putting all of that in danger with your wiki. A huge percentage of agencies put passwords into wikis - and other shared resources!!!

Using a shared Google/Office document, spreadsheet - even with black text on a black background - isn't much better! So, think of "wiki" in this context as being any "low-cost, low-security, high-accessibility, super-convenient storage."

You are putting your agency AND your customers at risk by keeping passwords in your company wiki!

Read more to find out why, and a better way to do it!

Drupal Association blog: Q2 2017 Financial Statement Summary

Mié, 11/15/2017 - 13:32

The Drupal Association Board is responsible for the Drupal Association’s financial health and as part of their duty, they vote to approve monthly financial statements. The board met on September 23, 2017 at the board retreat that took place before DrupalCon Vienna and voted to approve the Q2 2017 financial statements that were prepared by our virtual CFO service, Summit CPA.

This blog walks you through our Q2 2017 Financials and how we performed against the two financial KPIs that we measure against each month:

  • Cash Reserve: Have a cash balance of 15-30% of Total Revenue

  • Net Income Profit Margin: End 2017 with a net income profit of 10%

Below is a summary of how we performed against our KPIs each month in the second quarter of 2017.

KPI Goal April May June Cash Reserve 15-30% 60% of goal 84% of goal 88% of goal Net Income Margin (NIM) % 10% 49.9% -29.8% -48.9%

The table above shows that Q2 was strong as a whole, due to the big income assist DrupalCon Baltimore gave.

With May and June below the KPI goal, we reviewed the entire quarter results as a whole. The quarter was buoyed by DrupalCon Baltimore which produced a majority of the $2,328,367 in April’s revenue and after its expenses, April landed $1,163,390 in net income. Following DrupalCon, May and June collectively accounted for $542,530 in revenue, producing a $214,711 net loss. When taken in total, we generated revenue of $2,870,897 and net income of $948,679. This equates to a NIM of 33.04% for the second quarter measuring above the net income margin goal.

You can see we did not achieve our cash reserve goal this quarter. The Drupal Association is still in its financial turn around so we did not meet our goal for the second quarter, however we are much closer to doing so than we have been in the past.

This chart below shows how cash reserves are building in Q2 and getting closer to hitting the cash reserve goal for this quarter.

Monthly Updates

April results toward our KPIs had us holding $1.2M in cash, which is 84% of the stated cash reserve goal.  Due to DrupalCon Baltimore reporting strong sales in both trainings and general conference tickets, we resulted in 49.9% of net income KPI.  Expenses for DrupalCon Baltimore came in lower, catering had significant savings of $50K.

For May, our cash reserve goal increased 11% through additional sales in Digital Sponsorships programs and DrupalCon ticket sales.  May expenses had DrupalCon Baltimore $15.8k less than forecasted, and IT had some savings in their budget as well, which helped cash reserves. 

June had costs from Baltimore which lowered net income by $70k than originally forecasted. This was seen in event production costs that were $100k higher than anticipated, along with an unanticipated $14k in professional expenses. Reducing the impact of those costs, income in other programs came in $55k higher, the majority being rebates from DrupalCon Baltimore. This impacted the cash reserve KPI, where we reached 88% of our goal.

We would not be able to do our mission-driven work without the support and contributions of our community. Contributions come in many forms, through the purchase of DrupalCon tickets and event sponsorships, through our Supporters and Members, Drupal.org sponsors, recruiters who post jobs on Drupal Jobs and many other fantastic ways our community supports the Drupal eco-system. We are deeply grateful for everyone who contributes their time, talent, and treasure to move Drupal forward.

Thank you!

File attachments:  june cash reserve.jpeg

Valuebound: Migrating Address Book in Drupal 8 website using Process plugin

Mié, 11/15/2017 - 11:17

Migration is a term, which all the developers who have started working in Drupal 8 have gone through once at least in their development cycle. Migration can be done of many things like site migration (i.e migrate from Drupal 7 to Drupal 8), user migration, content migration. In simple terms, we can migrate all types of entity in Drupal 8.

How this migration works:

Migrate works by reading a row from a source plugin then running each property through a pipeline of Process plugins thus, resulting in a row to a destination plugin.

Why we write Process plugin?

Each Process…

ADCI Solutions: Drupal Cafe #16: how it was?

Mié, 11/15/2017 - 08:50

Drupal is the big community where each member wants to share his or her experience with others. That’s why there are a lot of Drupal events. We held one of them.

 

Check how Drupal Cafes are done in Russia.

 

 

Appnovation Technologies: Expert Interview: Drupal Developer, Daniel Sipos

Mié, 11/15/2017 - 06:00
Expert Interview: Drupal Developer, Daniel Sipos What prompted you to write a book? And why did you pick module development as a central theme? Answer: To be honest, I had never thought about writing a book. I was always quite active in the Drupal community, often writing articles, and  there are quite a few people who know me for this and appreciate it. This publication came ab...

Electric Citizen: Drupal 8 DevOps: Automation for happier teams and clients

Mié, 11/15/2017 - 01:10

How the DevOps movement is pointing the way forward to higher quality Drupal projects, faster delivery, happier team members, and satisfied clients for projects of any scale

Over the past several years, the best practices surrounding Drupal DevOps have expanded and improved, including continuous integration, continuous delivery, continuous deployment, and automated testing. In turn more organizations are discovering the benefits of these automated tools and deployment methods:

  • Faster development – developers can deliver more work in less time and reduce project costs (or deliver more work for the same budget)
  • Higher quality – with repeatable builds and automated tests against live production content for every change we reduces stress and uncertainty surrounding deployments of new features and bug fixes
  • Transparent development cycles – frequent builds mean any team member can check on the progress of any task at any time
  • Better collaboration – team members and stakeholders can focus on the features that matter instead of collaborating over the mundane details of builds and deploys

Whether a site is under active development or already in production, these benefits result in less stress, higher quality projects, happier developers, and satisfied stakeholders.

Dries Buytaert: An update on the Layout Initiative for Drupal 8.4/8.5

Mié, 11/15/2017 - 00:57

Now Drupal 8.4 is released, and Drupal 8.5 development is underway, it is a good time to give an update on what is happening with Drupal's Layout Initiative.

8.4: Stable versions of layout functionality

Traditionally, site builders have used one of two layout solutions in Drupal: Panelizer and Panels. Both are contributed modules outside of Drupal core, and both achieved stable releases in the middle of 2017. Given the popularity of these modules, having stable releases closed a major functionality gap that prevented people from building sites with Drupal 8.

8.4: A Layout API in core

The Layout Discovery module added in Drupal 8.3 core has now been marked stable. This module adds a Layout API to core. Both the aforementioned Panelizer and Panels modules have already adopted the new Layout API with their 8.4 release. A unified Layout API in core eliminates fragmentation and encourages collaboration.

8.5+: A Layout Builder in core

Today, Drupal's layout management solutions exist as contributed modules. Because creating and building layouts is expected to be out-of-the-box functionality, we're working towards adding layout building capabilities to Drupal core.

Using the Layout Builder, you start by selecting predefined layouts for different sections of the page, and then populate those layouts with one or more blocks. I showed the Layout Builder in my DrupalCon Vienna keynote and it was really well received:

8.5+: Use the new Layout Builder UI for the Field Layout module

One of the nice improvements that went in Drupal 8.3 was the Field Layout module, which provides the ability to apply pre-defined layouts to what we call "entity displays". Instead of applying layouts to individual pages, you can apply layouts to types of content regardless of what page they are displayed on. For example, you can create a content type 'Recipe' and visually lay out the different fields that make up a recipe. Because the layout is associated with the recipe rather than with a specific page, recipes will be laid out consistently across your website regardless of what page they are shown on.

The basic functionality is already included in Drupal core as part of the experimental Fields Layout module. The goal for Drupal 8.5 is to stabilize the Fields Layout module, and to improve its user experience by using the new Layout Builder. Eventually, designing the layout for a recipe could look like this:

Closing thoughts

Layouts remains a strategic priority for Drupal 8 as it was the second most important site builder priority identified in my 2016 State of Drupal survey, right behind Migrations. I'm excited to see the work already accomplished by the Layout team, and look forward to seeing their progress in Drupal 8.5! If you want to help, check out the Layout Initiative roadmap.

Special thanks to Angie Byron for contributions to this blog post, to Tim Plunkett and Kris Vanderwater for their feedback during the writing process, and to Emilie Nouveau for the screenshot and video contributions.

Agiledrop.com Blog: AGILEDROP: Hosting services specialised for Drupal

Mar, 11/14/2017 - 23:20
Drupal works on most hosting providers that support PHP, MySql and related technologies. However, I would not recommend using a general shared hosting solution to anyone. At AGILEDROP we have two practices: either we set up a bespoke hosting environment or deploy websites to hosting platforms that are specialized in Drupal. Why specialization matters? We like to work with companies that have specialized in hosting Drupal web applications.  Specialised companies provide: Best results. If hosting companies are specialized in one technology, they are are going to do that best because they… READ MORE

Agaric Collective: How to declare hexadecimals on a PHPDoc Block

Mar, 11/14/2017 - 17:30

TL;DR: For PHP Hexadecimals, Decimals and Octals are all Integers, so they must be declared as @param integer

While I was working on a patch I had to write the docblock of a function which received a hexadecimal number and I wasn't sure what I was supposed to put in the @type param.

I went to Drupal's API documentation and comments standards page to see which is the best type for this param and I found the following:

Data types can be primitive types (int, string, etc.), complex PHP built-in types (array, object, resource), or PHP classes.

Alright, a hexadecimal number is not a complex PHP built-in type nor a PHP Class so it must be a primitive type, so I went to the PHP documentation page to see which primitives PHP has and I found the following:

  • boolean
  • integer
  • float (floating-point number, aka double)
  • String

So there wasn't a specific reference for a Hexadecimal number...

The solution:

In the end Pieter Frenssen helped me (Thanks!) with this, and he showed me that in PHP, it doesn't matter what the base number is and it can be an octal, hexadecimal or a decimal, for PHP they all are integers (which makes sense but I wanted to be sure) and he shared this small snippet where we can see that PHP sees the numbers as integers and the base doesn't matter:

$ php -a Interactive shell php > var_dump(gettype(0x0f)); string(7) "integer" php > var_dump(0x08 === 8); bool(true)

So if you are writing the documentation of a function in which one of its params is a hexadecimal number you must declare it as Integer.

Elevated Third: Elevated Third’s CEO Featured as a Drupal Expert

Mar, 11/14/2017 - 16:21
Elevated Third’s CEO Featured as a Drupal Expert Elevated Third’s CEO Featured as a Drupal Expert Ayla Peacock Tue, 11/14/2017 - 11:21

Elevated Third’s CEO, Jeff Calderone, recently shared his insights with Clutch on Drupal, how to choose a platform and how to choose the right web developers to build your website. This is part of a series of interviews that Clutch has been conducting to educate businesses on the options they have when building a website.

Clutch is a B2B ratings and reviews website that ranks digital agencies to help business buyers choose the best partner for their next dev project. We’re currently ranked as a top 5 Drupal Development firm and a top 5 Denver web designer in their research.

Drupal is one of the most popular opensource CMSs. Its community of developers ensures that the platforms continues to evolve and improve. According to Jeff:

“Drupal is great because it gives you a lot of functionality out of the box, the core functionality that’s been built by thousands of developers over time. It’s really solid, tested, and secure. The modules that are created by the community are really where the power comes and where it stands out. We can start with a key suite of modules and core functionality and often get our clients 60-70% of the way to where they want to go, but then be confident that we can build custom modules and functionality to get them the rest of the way, and oftentimes, replicate the functionality of a fully custom website for much less because we’re using the opensource community that has created all this functionality over time.”

Each business has different needs for their website. When it comes to choosing a website platform, Jeff offered:

“Especially if they’re in the B2B space and have that longer sales cycle, I think they need to pick a platform that is going to be able to grow with them and integrate with their existing legacy systems as well as connect with marketing automation and Salesforce and CRM in a way that is user proof. Personalization is coming. Voice activation is coming. All of those exist in some form already. Building on a platform like Drupal allows you to get something up and running quickly and be modular both now and in the future and add onto a solid core as these technologies and trends become actual.”

Another challenge that companies face is choosing the right partner for their project. According to Jeff the key to finding the right company is:

“Focusing on an agency that’s going to understand your business and solve the right problem as opposed to just developers who are going to build what they’re told to build… There are a lot of shops that have good developers that will build whatever you tell them to. We focus on providing that strategic insight. Half our agency is strategy and UX and design and helping the company to solve the right problem trusting that the other side of our shop, the Drupal developers, can implement and build those things that we recommend… It’s key to have that integrated approach and not just one or the other.”

If your business goals and website requirements are planned out early on, choosing the right platform and partner for your company will be simple. To learn more about Drupal, you can read the full interview here.

Acro Media: Video: Making Migration to Drupal Commerce 2 Easier

Mar, 11/14/2017 - 15:47

Moving to a new e-commerce platform can be a massive undertaking, but Drupal is making it simple. Whether you currently use Commerce 1, Ubercart, Shopify, or Magento, there is (or will soon be) an easy way to move over to Commerce 2 and see what it can offer you. Watch the latest High5 video here to learn more.

What moving means

There are a ton of different parts that make up your e-commerce site: products, product variations, orders, customers, account balances, user logins, etc. One of the first things you need to decide is which parts you're going to migrate. Maybe you want to pull order data, but not discounts, which can be notoriously difficult to move over. Products are obviously essential, but moving tax rules over is not nearly as crucial, since you could probably set those up yourself (and if you work with a third party for that anyway, migrating tax rules is a waste of time).

What migrate tools can do

Migrating your site manually is incredibly labor-intensive and prone to failure (you try moving 10,000 products manually without screwing any of them up.) Automating the process with migrating tools that have been thoroughly tested will give you a lot more consistency when moving your data around. And the best part is that this is all open source; we're releasing these tools so that anyone can migrate their site on their own at no charge.

How the tools were developed

We started from the most common stuff (products, orders) and worked our way out to customers and discounts and product classes and all the rest. We have sample sets that we test for each of those aspects. So we have full databases of Ubercart sites, for instance, that we migrate over so we can see which parts are missing and what needs to be improved. We continually work to build those missing pieces and fill out all those edge cases.

What's ready and what's coming

We have all the basics done for Ubercart; if you want to do an Ubercart to Commerce 2 migration right now, you can do it, though you might have to do a little bit of configuring and customizing to get the edge cases. We're trying to get to a point where you can literally just push a button and have everything move over, but that's still a couple months away. Commerce 1 is close to that, Magento is pretty basic, and Shopify is more of a prototype right now.

Chromatic: Taxonomy Term Shuffles - Hook Updates with Batch API in Drupal 7

Mar, 11/14/2017 - 14:00

Clare breaks down how to reassign nodes from one taxonomy term to another. Code samples included.

Promet Source: WordPress vs. Drupal for Web Accessibility, SEO & Performance

Mar, 11/14/2017 - 07:08
Wordpress vs. Drupal - How do I choose a CMS for my web development project? The age old question - or at least decades old question of Wordpress vs. Drupal is one we encounter on an almost daily basis. When deciding between the two content management systems, it may not be a question of which is better, but rather which is the best fit for your specific project. In this article I'll walk through some of the key factors to considering when deciding between Wordpress and Drupal for your web development projects.

Appnovation Technologies: Guaranteed Delivery using Dead Letter Queue

Mar, 11/14/2017 - 06:00
Guaranteed Delivery using Dead Letter Queue When an enterprise implements messaging, Guaranteed Delivery (Messages are persistent and are not lost even when the system crashes) becomes an imminent requirement. When implementing messaging, ensuring Guaranteed Delivery means answers to the following: Where does the message get sent when a condition is not met? Can each individual ...

CiviCRM Blog: CiviCRM Entity 2.0-beta-11 Released - New Admin config page

Lun, 11/13/2017 - 20:52

Today, Skvare has released a new version of CiviCRM Entity, 2.0-beta11.  This release contains a new feature, an admin configuration page which allows site administrators to disable exposure of entity types to Drupal.

CiviCRM Entity is a Drupal module which exposed CiviCRM API entity types as native Drupal entity types, providing Views, Rules, Entity Reference field integration, and Drupal native pages and forms for each. It supports both CiviCRM 4.6 LTS and CiviCRM 4.7.

Previous versions of CiviCRM Entity allowed developers to control access to Drupal based pages and forms for entity types, but there was no way for administrators to control what entity types were available in Views, Rules, or Entity Reference fields. As CiviCRM Entity has evolved over the past 2 years, over 45 entity types have been supported, including all the major financial record types. There are cases where many of these entity types are not used in Views, Rules, etc.., and admins may not want to make data of these entity types available to be used in Views by lower-ranking administrative users.  Disabling an entity type in CiviCRM Entity does not affect the Core Views integration. However it will not make any of the additions that CiviCRM Entity provides, and for types not supported by CiviCRM Core, integration can now easily be toggled on/off.

Having all entity types enabled can affect performance in some aspects. Generally, this does not affect cached page load for normal users, but anytime you clear the cache, or the Views cache, having 45 entity types can cause cache rebuild to be intensive, not to mention all the additional menu paths that are generated for the Admin menu. Disabling entity types that you do not use will streamline admin user performance, and make the site in total that much faster by reducing memory footprint.

For existing users of CiviCRM Entity, the module can be upgraded as per Drupal standard, and there are no necessary config changes to make.  There are updates that need to be run by going to "/update.php" or running "drush updatedb" from the command line. These updates simply set up a configuration variable, and do not affect the CiviCRM database.  All available entity types are enabled by default for new or upgraded installations.

All submodules that are packaged with the CiviCRM Entity will automatically enable entity types that are required by the submodule and will enforce that these entity types remain enabled as long as the submodule is enabled.

Usage

You will find an admin configuration page at "admin/structure/civicrm-entity/settings". A user with a role with 'administer CiviCRM Entity' permission is required to access and manage the settings on this page.

It is important to remember to enable all entity types used by your site's configuration and 3rd party modules. This page does not check if an entity type is required by an existing View, Rule, Entity Reference field. Disabling an entity type will break functionality in any rule, view, or field that requires it, so proceed with caution.  However, re-enabling will restore functionality for those entities.

For developers of 3rd party modules or custom modules making use of CiviCRM Entity, you are responsible for ensuring an entity type is always available. This requires only a hook_form_alter() implementation to disable the necessary configuration page checkbox, or adding a validation or submit handler to the form.

Future

We consider CiviCRM Entity for Drupal 7 to be feature complete, and it has been quite some time since there was a major bug found. We plan to release a non-beta stable 2.0 version at the end of this year. This upcoming stable release will be regarded as a Long Term Support release, and any major changes or updates will move to a 3.x branch. The primary focus of new development will now shift to the Drupal 8 version development. We will continue to support the 7.x-2.x branch throughout the life of Drupal 7 for bug fixes and minor feature updates.  We will support for CiviCRM 4.6 LTS for its lifetime, and most likely beyond.

DrupalExtensions

Joachim's blog: Drupal Code Builder unit testing: bringing in the heavy stuff

Lun, 11/13/2017 - 19:49

I started adding unit tests to Drupal Code Builder about 3 years ago, and I’ve been gradually expanding on them ever since. It’s made refactoring the code a pleasant rather than stressful experience.

However, while all generator types are covered, the level of detail the tests go into isn’t that deep. Back when I wrote the tests, they mostly needed to check for hook implementations that were generated, and so quick and dirty regexes on the generated code did the job: match 'mymodule_form_alter' in the generated code, basically. I gradually extended those to cover things like class declarations and methods, but that approach is very much cracking at the seams.

So it’s time to switch to something more powerful, and more suited to the task.

I’ve already removed my frankly hideous attempt at verifying that generated code is correctly-formed PHP, replacing it with a call to PHP’s own code linter. My own code was running the generated PHP code files through eval() (yes, I know!) to check nothing crashed, which was quick and worked but only up to a point: tests couldn’t create the same function twice, as eval()ing code that contains a function declaration brings it into the global namespace, and it didn’t work at all for classes where while tests were being run, as the parent classes in Drupal core or contrib aren't present.

It's already proved worthwhile, as once I'd converted the tests, I found an error in the generated code: a stray quote mark in base field definitions for a content entity, which my approach wasn't picking up, and never would have.

The second phase is going to be to use PHPCS and Drupal Coder to check that generated code follows Drupal Coding Standards. I'm currently getting that to work in my testing base class, although it might be a while before I push it, as I suspect it's going to complain about quite a few nipicks in the generated code that I'll then have to spend some time fixing.

The third phase (this is a 3-phrase programme, all the best ones are) is going to be to look into using PHP-Parser to check for the presence of functions and methods in the code, rather than my regex-based approach. This is going to allow for much more thorough checking of the generated code, with things such as method order in the code, service injection, and more.

After that, it'll be back to some more refactoring and code clean-up, and then some more code generators! I have a few ideas of what else Drupal Code Builder could generate, but more ideas are welcome in the issue queue on github.

Tags: drupal code builder

Páginas