Inhalt abgleichen
Drupal.org - aggregated feeds in category Planet Drupal
Aktualisiert: vor 29 Minuten 48 Sekunden

Agiledrop.com Blog: AGILEDROP: Interview with our Commercial director, Iztok Smolic

24. November 2017 - 9:11
We have sat down with our Commercial director, Iztok Smolic and ask him a couple questions. Enjoy the interview.    When did you start working at AGILEDROP and what were your initial responsibilities? I am one of the co-founders of AGILEDROP, so I am with the company from its beginning. In the early days, all of us wore many hats. In my case, 60% of the time I was working on the development and the other 60% I was communicating with new clients and wrote proposals (yes, I did some overtime). As we grew I was able to focus on the thing I was best at, that was advising to clients and being… READ MORE

PreviousNext: Securing Drupal: Storing API Tokens in Lockr

24. November 2017 - 1:20
Share:

As seen in the recent Uber hack, storing secrets such as API tokens in your project repository can leave your organisation vulnerable to data breaches and extortion. This tutorial demonstrates a simple and effective way to mitigate this kind of threat by leveraging Key module to store API tokens in remote key storage.

by Nick Santamaria / 24 November 2017

Even tech giants like Uber are bitten by poor secret management in their applications. The snippet below describes how storing AWS keys in their repository resulted in a data breach, affecting 57 million customers and drivers.

Here’s how the hack went down: Two attackers accessed a private GitHub coding site used by Uber software engineers and then used login credentials they obtained there to access data stored on an Amazon Web Services account that handled computing tasks for the company. From there, the hackers discovered an archive of rider and driver information. Later, they emailed Uber asking for money, according to the company.

Uber could have avoided this breach by storing their API keys in a secret management system. In this tutorial, I'll show you how to do exactly this using the Key module in conjunction with the Lockr key management service.

This guide leverages a brand-new feature of Key module (as of 8.x-1.5) which allows overriding any configuration value with a secret. In this instance we will set up the MailChimp module using the this secure config override capability.

Service Set-Up

Before proceeding with the Drupal config, you will need a few accounts:

  • Mailchimp offer a "Forever Free" plan.
  • Lockr offer your first key and 1,500 requests for free.

These third-party services provide us with a simple example. Other services are available.

Dependencies

There are a few modules you'll need to add to your codebase.

composer require \   "drupal/key:^1.5" \   "drupal/lockr" \   "drupal/mailchimp"Configuration
  1. Go to /admin/modules  and enable the MailChimp, Lockr and Key modules.
  2. Go to /admin/config/system/lockr
  3. Use this form to generate a TLS certificate that Lockr uses to authenticate your site. Fill out the form and submit.
  4. Enter the email address you used for your Lockr account and click Sign up.
  5. You should be now be re-prompted to log in - enter the email address and password for your Lockr account.
  6. In another tab, log into the MailChimp dashboard
    1. Go to the API settings page - https://us1.admin.mailchimp.com/account/api/
    2. Click Create A Key
    3. Note down this API key so we can configure in Drupal in the next step.
  7. In your Drupal tab, go to /admin/config/system/keys and click Add Key
  8. Create a new Key entity for your MailChimp token. The important values here are:
    1. Key provider - ensure you select Lockr
    2. Value - paste the API token you obtained from the MailChimp dashboard.
  9. Now we need to set up the configuration overrides. Go to /admin/config/development/configuration/key-overrides and click Add Override
  10. Fill out this form, the important values here are:
    1. Configuration type: Simple configuration
    2. Configuration name: mailchimp.settings
    3. Configuration item: api_key
    4. Key: The name of the key you created in the previous step.

... and it is that simple.

Result

The purpose of this exercise is to ensure the API token for our external services are not saved in Drupal's database or code repository - so lets see what those look like now.

MailChimp Config Export - Before

If you configured MailChimp in the standard way, you'd see a config export similar to this. As you can see, the api_key value is in plaintext - anyone with access to your codebase would have full access to your MailChimp account.

api_key: 03ca2522dd6b117e92410745cd73e58c-us1 cron: false batch_limit: 100 api_classname: Mailchimp\Mailchimp test_mode: falseMailChimp Config Export - After

With the key overrides feature enabled, the api_key value in this file is now null.

api_key: null cron: false batch_limit: 100 api_classname: Mailchimp\Mailchimp test_mode: false

There are a few other relevant config export files - lets take a look at those.

Key Entity Export

This export is responsible for telling Drupal where Key module stored the API token. If you look at the key_provider and key_provider_settings values, you'll see that it is pointing to a value stored in Lockr. Still no API token in sight!

dependencies:  module:    - lockr    - mailchimp id: mailchimp_token label: 'MailChimp Token' description: 'API token used to authenticate to MailChimp email marketing platform.' key_provider: lockr key_provider_settings:  encoded: aes-128-ctr-sha256$nHlAw2BcTCHVTGQ01kDe9psWgItkrZ55qY4xV36BbGo=$+xgMdEzk6lsDy21h9j…. key_input: text_field Key Override Export

The final config export is where the Key entity is mapped to override MailChimp's configuration item. 

status: true dependencies:  config:    - key.key.mailchimp_token    - mailchimp.settings id: mailchimp_api_token label: 'MailChimp API Token' config_type: system.simple config_name: mailchimp.settings config_item: api_key key_id: mailchimp_tokenConclusion

Hopefully this tutorial shows you how accessible these security-hardening techniques have become. 

With this solution implemented, an attacker can not take control of your MailChimp account simply by gaining access to your repository or a database dump. Also remember that this exact technique can be applied to any module which uses the Configuration API to store API tokens.

Why? Here are a few examples of ways popular Drupal modules could harm your organisation if their configs were exposed (tell me about your own worst-case scenarios in the comments!).

  • s3fs - An attacker could leak or delete all of the data stored in your bucket. They could also ramp up your AWS bill by storing or transferring terabytes of data.
  • SMTP - An attacker could use your own SMTP server against you to send customers phishing emails from a legitimate email address. They could also leak any emails the compromised account has access to.

What other Drupal modules could be made more securing in this way? Post your ideas in the comments!

Go forth, and build secure Drupal projects!

 

Tagged DrupalSouth, Drupal Security, Security, APIs

Posted by Nick Santamaria
Systems Operations Developer

Dated 24 November 2017

Add new comment

Acro Media: Video: How to Prepare for Peak Traffic Days

24. November 2017 - 0:10

Is your commerce site ready for the big time? We're talking about Black Fridays, product launches, back-to-school weeks, and any other time you are going to get exponentially more traffic than you would normally get. A lot of people just assume their site/server/staff can handle such increased volume, but unless you've tested it by running 10 or 20 or 50 times the traffic through it, you really don't know.

The problem is that scaling doesn't work in a linear way. Let's say you're currently using 10 percent of your server's capacity. Simple math would indicate that you could handle 10 times as much traffic and be at 100% of capacity, so you should be fine.

But it doesn't necessarily work that way in the real world. It could be that there is some sort of hidden flaw that flares up when that volume of traffic comes through: maybe you hit some sort of race condition, or a caching system starts to cycle too fast, or you get a database bottleneck and everything gets backed up behind it. It could be some little glitch that's easily fixed and everything goes back to normal—but if you fix it halfway through the biggest sales day of the year, it's too late.

So how can you get ready?

1. Do performance testing.

Your goal should be to mimic live as much as possible. You don't just want to run the test on your local server. You want to spin up a similar environment, or maybe spin something up at 1/10th of the scale and hit it hard with lots of capacity. Or do it through Amazon and only run it for an hour or something to save on cost.

Once you have your environment, you have to try to simulate actual traffic. You don't want to just hit the home page repeatedly, because that's not how your customers interact with your site. They go through the checkout, and click around on product pages, and search, and log in to their account. They do a whole bunch of random stuff, and you have to try to mimic that. You can't do it perfectly, but you want to hit all the parts of your site and throw a bit of randomness in there to try to get as close to the real experience as possible.

In a perfect world, you would have gone through a similar event like Black Friday already and learned from it. But maybe you're a first-timer. Or maybe you're launching a big new product unlike anything you've had before, and it's backed by a TV spot, and you're expecting a massive volume of sales to follow. So test your site and be sure.

2. Prepare for stock issues.

Stock problems can obviously be much worse in a high-volume situation. On a slow day, if an order goes through when you are out of stock, maybe you could just call that person and say oops, sorry, but it's going to take a couple days to fill that order.

But if you have a huge burst of traffic, you might sell 20 items when you only have two in stock. And you can't even get 18 on your next order, and it's going to take six weeks to get that many, and now you have a real problem.

So if that happens, what do you do? How are you handling out-of-stock issues? Do you have messaging to say this is going to be delayed? Are you going to shift customers to alternate recommended products? These are all things you need to consider.

3. Set staffing levels appropriately.

You don't want to be in a situation where your website can handle the traffic, but your human workers cannot. In a physical store, everyone knows they need to up the number of sales staff to deal with a huge crush of shoppers. But when it comes to the website, sometimes people forget that someone still needs to put 10 times as many items in boxes, and deal with 10 times as many email complaints, and talk to 10 times as many customers via live chat.

How does your current process scale? How fast does it take you to do an order? Maybe you need to think about automated shipping, or standardized box sizes, or any one of a number of other things that will make your staff's lives easier during high-volume times.

Conclusion

As you can see, there are quite a few things that you can do to make sure your opperating smoothly during those peak sales days throughout the year. Some of these things you can do yourself. Some of them you might need some technical support. If support is what you need, or you'd like to discuss this further, contact us. We've been through it all before and can share our experience.

Amazee Labs: Sustainable Drupal & React Maintenance - Video

23. November 2017 - 15:55
Sustainable Drupal & React Maintenance - Video

As mentioned in my previous post, I’ll be sharing the videos of the various talks by Amazees at Drupal Camp Cape Town 2017, over the upcoming weeks. 

Jason Lewis Thu, 11/23/2017 - 14:55

First up we have Head of Global Maintenance at Amazee Labs, Bryan Gruneberg, who spoke about "Maintainability and Longevity - Keeping customers and developers happy". Maintaining strong, robust sites that evolve with the client’s needs is of utmost importance to us and was a topic that received a lot of interest from Camp attendees. 

Enjoy the Video!

Droptica: Droptica: Drupal node grants

23. November 2017 - 15:00
Everyone who codes in Drupal will sooner or later encounter the need to define tighter control of access to content. The standard mechanisms of roles and permissions are very flexible, but they may be insufficient in complex projects. When access to nodes starts to depend on, for example, fields assigned to a given user, then you have to take advantage of more advanced solutions. In Drupal 7 and 8 we can use a hook – hook_node_access() or a so-called grants mechanism.

Valuebound: Configuring Memcache with Drupal 8 to reduce database load

23. November 2017 - 14:59

Developers often come across a situation where they are required to reduce database load by caching DB objects in RAM. Here Memcache improves Drupal application performance by moving standard caches out of the database and by caching the results of other expensive database operations. 

Note that Drupal doesn’t support Memcache by default, and for this, we need to install it on the server. Let’s see how to install Memcache on the server and configure it with Drupal 8 to reduce the load on the database with every page load.

Let’s see how to install Memcache on server

Open the terminal on your local machine and run the following codes:

Step 1: sudo apt-get…

Agaric Collective: Global Training Day - fun and accesible to all!

23. November 2017 - 14:23

When you think of training, perhaps you remember an event that you were sent to where you had to learn something boring for your job. The word training does not usually make people smile and jump for joy, that is unless you are talking about Drupal training. These gatherings spread the Drupal knowledge and increase diversity in the community of Drupal developers.

Join us for Global Training Day on November 29th. It will be help online from 9 AM to 4 PM EST. - https://groups.drupal.org/node/517886

Sign up now.

A link to the live workshop on Zoom will be provided when you sign up!

The Drupal Association coordinates four dates each year as Global Training Days, designed to offer free and low-cost training events to new-to-Drupal developers and to create more Drupal talent around the world. The community is growing exponentially as more people learn how fun and easy it is to get involved and be productive. Volunteer trainers host these global events in person and online. In 2016, a Global Training Days Working Group was established to run this program. There is a Global Training Days group on Drupal.org that lists trainings around the world - https://groups.drupal.org/global-training-days

Coming up, we have Global Training Day on November 29th. Mauricio Dinarte will be leading the training online. As an introduction to Drupal a person needs to learn certain things that are specific to Drupal and some are not that intuitive. It is important to cover the very basics in terminology and process. An introductory class can include many things, but this list is what Mauricio covers during the day long event:

  • Drupal installation requirements and process
  • Nodes
  • Content types
  • Fields
  • Blocks
  • Theme regions
  • Views
  • User and permissions
  • Menus
  • Taxonomy

The outcome of a day of training is that everyone walks away understanding the main moving parts of Drupal and a bit about what they do. Of course you will not become a developer overnight, but you will have enough information to build a simple site and then explore more of Drupal on your own. You can follow up with many online tutorials and by joining the Drupal group in your area and attending the meetings. At meetings you will connect with other people at different levels of skill and you will be helped and helpful at the same time! If there is no Drupal group in your area, I suggest you start one. It can start as easily as posting online that you will be at a specific location doing Drupal at a certain time of day - you will be surprised at who may show up. If no one shows up the first time, try again or try a different location. One of the best things about Drupal is the community and how large and connected we are. If you start a group, people will usually help it grow. Bringing new people to Drupal is not only good for increasing the size of the member base, it also brings diversity and reaches people that may never have had an opportunity or access to a free training. The trainings are usually held at a University in or near a city which attracts people from different backgrounds and cultures. We can also reach people that are not in a city or near a school by sharing online.

Have you ever thought about volunteering at a Global Training Days event? We have a blog about organizing your own Global Training Days workshop that can get you started. This is a great way to get to know the people in the community better, up your skills and perhaps share something you have learned. I learned much about programming by assisting developers at sprints and trainings. This is where the real fun begins. Learning does not have to be stressful, and in the Drupal community people are friendly and welcoming. No question is stupid and even those with no experience have valuable skills. Developers love people without prior experience because they make the perfect testing candidates for UI and UX. The down side is that Drupal is so captivating that you will probably not remain a newbie for very long, so enjoy it while it lasts.

One of the true highlights of Global Training Days is seeing all the people around the world gain valuable skills and share knowledge. We hope you can join us.

Tim Millwood: Dreditor for Firefox

23. November 2017 - 11:33
Dreditor for Firefox

Last week I switch from years of using Chrome to Firefox 57 because of all the hype about it being fast, and that I'd been suffering from Chrome using up to 10GB of ram. The big issue I hit though was I didn't have Dreditor and there seemed to be no way to install it. I decided to go on using Firefox without Dreditor, and loading Chrome every time I needed to do an in depth patch review.

Then yesterday I saw the latest Commit Strip cartoon, where in a reply @williambl suggested Chrome Store Foxified for converting Chrome plugins to Firefox. First thing I thought was to try the Dreditor Chrome plugin, and it worked.

This morning Berdir suggested "maybe someone will release that thing as a public extension". So I went digging on addons.mozilla.org and found I could download the XPI file Chrome Store Foxified created during the conversion.

So here it is:
Download Dreditor for Firefox now!
MD5SUM: 2b7455e057ac6a84bd01423b0984c21d

timmillwood Thu, 23/11/2017 - 09:33 Tags drupal planet drupal-planet drupal dreditor Add new comment

Amazee Labs: GraphQL for Drupalers - the queries

23. November 2017 - 10:59
GraphQL for Drupalers - the queries

GraphQL is becoming more popular every day. Now that we have a beta release of the GraphQL module (mainly sponsored and developed by Amazee Labs) it's easy to turn Drupal into a first-class GraphQL server. In this second post of the series, we'll describe they way Drupal fields are represented in GraphQL and look at a few examples.

  Blazej Owczarczyk Thu, 11/23/2017 - 09:59

Last week we talked about the new structure of the GraphQL package. We have also looked at the tools bundled with the module - the explorer and the voyager - and we've explored how to fetch a username. Now let's use GraphiQL to assemble queries that are a bit more complex.

The Naming

GraphQL naming conventions are slightly different than Drupal's.

  • Fields and properties are in camelCase. This means that field_image in Drupal becomes fieldImage in GraphQL and the revision_log property becomes revisionLog.
  • Entity types and bundles use camelCase with the first letter capitalized so taxonomy_term becomes TaxonomyTerm and the tags vocabulary becomes TaxonomyTermTags. As we can see bundles are prefixed with the entity type name.
The structures

While fields and properties both translate to the same GraphQL structure called Field, entity types and bundles, despite sharing the naming convention, don't. The former is implemented as GraphQL Interfaces and the latter are GraphQL Types (implementing these Interfaces). As an example: 

This query contains fields from 3 different GraphQL structures that build upon one another.

  • entityId and entityCreated come from the Entity Interface. These fields are available for all entity objects. nodeById query returns a Node Interface which extends Entity Interface.
  • title and status are defined in the Node Interface and are available for all nodes, regardless of their content type.
  • fieldSubtitle is a field (field_subtitle in Drupal) that has been added to the Article content type. It's not a part of neither Node nor Entity Interfaces, it is only available in the NodeArticle Type. nodebyId can return any node, not just Article, so we need to wrap the fieldSubtitle in a GraphQL Fragment.

If we paste the query into GraphiQL (/graphql/explorer) we'll get a result similar to this one:

The Fragments

GraphQL Fragments, as the name implies, are just pieces of a query. They mostly serve two purposes:

  1. Executing part of a query conditionally - only when the result is of a specified type. In the example above fieldSubtitle will be evaluated only when the node with id 1 is an Article. If it turns out to be a Basic Page, the fragment will be omitted and the response will just be one field shorter without raising any exceptions.
  2. Reusability. A fragment can be given a name and be used more than once.

There are two fragments in this query. The first one starting on line 3 is an inline fragment. We need it because fieldCategory and fieldTags are only attached to Articles and nodeById can return any node.

The other one, defined on line 18, is a named fragment thanks to which we don't need to repeat the sub-queries for fieldCategory and fieldTags.

This is how the result could look like. Node 1 is an Article, it has 2 tags in one category term.

The Aliases

There might be situations when we want to use the same field more than once in a single query, to fetch node 1 and 2 simultaneously for instance. We can do that thanks to GraphQL Aliases

Here we're calling nodeById twice, each time with different arguments and aliases. The former will appear under nodeOne key in the result and the latter will be available under nodeTwo. We've also transformed the inline fragment holding the article fields into a named fragment and used it in both queries to reduce unnecessary repetition.

That's it for this post. In the next one, we'll see how to retrieve the values of Drupal fields and properties.

 

Agiledrop.com Blog: AGILEDROP: Top 5 reasons to use Drupal

23. November 2017 - 10:41
Drupal has become one of the most popular CMS around the world. Since it is written in PHP, very popular web programming language, it is also attractive to developers. It has nearly forty thousand modules and more than two thousand different themes, so it's no wonder that developers and designers like to work with it. It is suitable for all types of websites, from those advanced and heavier portals for communities to lighter, simpler personal web pages. Most importantly, it's great for ambitious websites (link to blog post about this). What are other benefits we recognize? It is open… READ MORE

Promet Source: Last Chance for Drupal 7 & Drupal 8 Training in 2017!

22. November 2017 - 23:39
Ready to level up your skills before the New Year?

OSTraining: Smart Cropping of Media with Image Widget Crop Drupal Module

22. November 2017 - 21:23

Sometimes, in your Drupal site, you may need to crop images with a predefined aspect ratio but with different size values within a certain range. This is where the Image Widget Crop module is your tool for the job.

It can be used in a great variety of Drupal sites. From image galleries to educational sites with illustrations.

In this tutorial, you’ll be using the contrib Image Widget Crop module in conjunction with the new media features for images available in Drupal core.  

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

22. November 2017 - 19:57

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

Over the past weeks I have shared an update on the Media Initiative and an update on the Layout Initiative. Today I wanted to give an update on the Workflow Initiative.

Creating great software doesn't happen overnight; it requires a desire for excellence and a disciplined approach. Like the Media and Layout Initiatives, the Workflow Initiative has taken such an approach. The disciplined and steady progress these initiative are making is something to be excited about.

8.4: The march towards stability

As you might recall from my last Workflow Initiative update, we added the Content Moderation module to Drupal 8.2 as an experimental module, and we added the Workflows module in Drupal 8.3 as well. The Workflows module allows for the creation of different publishing workflows with various states (e.g. draft, needs legal review, needs copy-editing, etc) and the Content Moderation module exposes these workflows to content authors.

As of Drupal 8.4, the Workflows module has been marked stable. Additionally, the Content Moderation module is marked beta in Drupal 8.4, and is down to two final blockers before marking stable. If you want to help with that, check out the Content Moderation module roadmap.

8.4: Making more entity types revisionable

To advance Drupal's workflow capabilities, more of Drupal's entity types needed to be made "revisionable". When content is revisionable, it becomes easier to move it through different workflow states or to stage content. Making more entity types revisionable is a necessary foundation for better content moderation, workflow and staging capabilities. But it was also hard work and took various people over a year of iterations — we worked on this throughout the Drupal 8.3 and Drupal 8.4 development cycle.

When working through this, we discovered various adjacent bugs (e.g. bugs related to content revisions and translations) that had to be worked through as well. As a plus, this has led to a more stable and reliable Drupal, even for those who don't use any of the workflow modules. This is a testament to our desire for excellence and disciplined approach.

8.5+: Looking forward to workspaces

While these foundational improvements in Drupal 8.3 and Drupal 8.4 are absolutely necessary to enable better content moderation and content staging functionality, they don't have much to show for in terms of user experience changes. Now a lot of this work is behind us, the Workflow Initiative changed its focus to stabilizing the Content Moderation module, but is also aiming to bring the Workspace module into Drupal core as an experimental module.

The Workspace module allows the creation of multiple environments, such as "Staging" or "Production", and allows moving collections of content between them. For example, the "Production" workspace is what visitors see when they visit your site. Then you might have a protected "Staging" workspace where content editors prepare new content before it's pushed to the Production workspace.

While workflows for individual content items are powerful, many sites want to publish multiple content items at once as a group. This includes new pages, updated pages, but also changes to blocks and menu items — hence our focus on making things like block content and menu items revisionable. 'Workspaces' group all these individual elements (pages, blocks and menus) into a logical package, so they can be prepared, previewed and published as a group. This is one of the most requested features and will be a valuable differentiator for Drupal. It looks pretty slick too:

An outside-in design that shows how content creators could work in different workspaces. When you're building out a new section on your site, you want to preview your entire site, and publish all the changes at once. Designed by Jozef Toth at Pfizer.

I'm impressed with the work the Workflow team has accomplished during the Drupal 8.4 cycle: the Workflow module became stable, the Content Moderation module improved by leaps and bounds, and the under-the-hood work has prepared us for content staging via Workspaces. In the process, we've also fixed some long-standing technical debt in the revisions and translations systems, laying the foundation for future improvements.

Special thanks to Angie Byron for contributions to this blog post and to Dick Olsson, Tim Millwood and Jozef Toth for their feedback during the writing process.

Agaric Collective: Display forms in a modal dialog with Drupal 8

22. November 2017 - 18:54

Drupal 8 has a great AJAX form API which includes some tools to create modal dialogs using the jQuery modal library. The Examples module even demonstrates how to create a custom form and display it in a modal window. But what if what you want to do is display an already created form in a modal? How do we do that? Let's see how to do it with an example. Let's display the node add form in a modal window.

The first thing that we need to do is create a link which will trigger the modal when the user clicks it. The only special things that this link needs to have are a few attributes that will let Drupal know to display the contents of the link in a dialog:

<a href="http://agaric.com/node/add/article" class="use-ajax" data-dialog-type="modal" data-dialog-options="{'width':800,';height':500}"> Create Node </a>

Drupal also needs to include the JavaScript libraries which will read these attributes and make them work, so let's add the following libraries to your module's dependencies (in your equivalent to this example's modal_form_example.libraries.yml file).

dependencies: 'core/drupal.dialog.ajax', 'core/jquery.form',

If you are unsure about how to add libraries on Drupal 8 you can consult the documentation to either add it in a theme or add it in a custom module. At the end of the post I will provide a repository with the code where I added the libraries in a block.

And that's it! If you click the link, the form will be displayed in a modal dialog! Drupal will automatically detect that you are sending an AJAX request and will display just the form so you won't need to worry about removing the rest of the blocks or hiding undesired markup.

The last thing missing, is what will happen if the user creates a node? By default, the node will redirect the user to another page but if we want to just close the modal dialog and leave the user on the same page we need to tell the form to do that. For this we are going to alter the form and add an AJAX command letting Drupal know that we want to close the dialog as soon as the node is created. In the .module file of a custom module we will add this code:

use Drupal\Core\Form\FormStateInterface; use Drupal\Core\Ajax\AjaxResponse; use Drupal\Core\Ajax\CloseModalDialogCommand; use Drupal\Core\Ajax\RedirectCommand; /** * Implements hook_form_alter(). */ function modal_form_example_form_node_article_form_alter(&$form, FormStateInterface $form_state, $form_id) { $form['actions']['submit']['#submit'][] = '_modal_form_example_ajax_submit'; $form['actions']['submit']['#attributes']['class'][] = 'use-ajax-submit'; } /** * Close the Modal and redirect the user to the homepage. * * @param array $form * The form that will be altered. * @param \Drupal\Core\Form\FormStateInterface $form_state * FormState Object. */ function _modal_form_example_ajax_submit(array $form, FormStateInterface &$form_state) { $response = new AjaxResponse(); $response->addCommand(new CloseModalDialogCommand()); $form_state->setResponse($response); }

The first function adds an extra submit function (which will be executed after Drupal finishes processing the node) and the second function adds the command to close the Dialog when the node has been created.

We can do this with practically any form in Drupal and you can add extra commands to do more complex things. Here are two resources:

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

22. November 2017 - 16:57

Over the past weeks I have shared an update on the Media Initiative and an update on the Layout Initiative. Today I wanted to give an update on the Workflow Initiative.

Creating great software doesn't happen overnight; it requires a desire for excellence and a disciplined approach. Like the Media and Layout Initiatives, the Workflow Initiative has taken such an approach. The disciplined and steady progress these initiative are making is something to be excited about.

8.4: The march towards stability

As you might recall from my last Workflow Initiative update, we added the Content Moderation module to Drupal 8.2 as an experimental module, and we added the Workflows module in Drupal 8.3 as well. The Workflows module allows for the creation of different publishing workflows with various states (e.g. draft, needs legal review, needs copy-editing, etc) and the Content Moderation module exposes these workflows to content authors.

As of Drupal 8.4, the Workflows module has been marked stable. Additionally, the Content Moderation module is marked beta in Drupal 8.4, and is down to two final blockers before marking stable. If you want to help with that, check out the Content Moderation module roadmap.

8.4: Making more entity types revisionable

To advance Drupal's workflow capabilities, more of Drupal's entity types needed to be made "revisionable". When content is revisionable, it becomes easier to move it through different workflow states or to stage content. Making more entity types revisionable is a necessary foundation for better content moderation, workflow and staging capabilities. But it was also hard work and took various people over a year of iterations — we worked on this throughout the Drupal 8.3 and Drupal 8.4 development cycle.

When working through this, we discovered various adjacent bugs (e.g. bugs related to content revisions and translations) that had to be worked through as well. As a plus, this has led to a more stable and reliable Drupal, even for those who don't use any of the workflow modules. This is a testament to our desire for excellence and disciplined approach.

8.5+: Looking forward to workspaces

While these foundational improvements in Drupal 8.3 and Drupal 8.4 are absolutely necessary to enable better content moderation and content staging functionality, they don't have much to show for in terms of user experience changes. Now a lot of this work is behind us, the Workflow Initiative changed its focus to stabilizing the Content Moderation module, but is also aiming to bring the Workspace module into Drupal core as an experimental module.

The Workspace module allows the creation of multiple environments, such as "Staging" or "Production", and allows moving collections of content between them. For example, the "Production" workspace is what visitors see when they visit your site. Then you might have a protected "Staging" workspace where content editors prepare new content before it's pushed to the Production workspace.

While workflows for individual content items are powerful, many sites want to publish multiple content items at once as a group. This includes new pages, updated pages, but also changes to blocks and menu items — hence our focus on making things like block content and menu items revisionable. 'Workspaces' group all these individual elements (pages, blocks and menus) into a logical package, so they can be prepared, previewed and published as a group. This is one of the most requested features and will be a valuable differentiator for Drupal. It looks pretty slick too:

I'm impressed with the work the Workflow team has accomplished during the Drupal 8.4 cycle: the Workflow module became stable, the Content Moderation module improved by leaps and bounds, and the under-the-hood work has prepared us for content staging via Workspaces. In the process, we've also fixed some long-standing technical debt in the revisions and translations systems, laying the foundation for future improvements.

Special thanks to Angie Byron for contributions to this blog post and to Dick Olsson, Tim Millwood and Jozef Toth for their feedback during the writing process.

Sooper Drupal Themes: It's Happening! SooperThemes Portfolio Views For Drupal 8 and Drupal 7

22. November 2017 - 13:50

Our very first official Drupal 8 product release is our SooperThemes Drupal Portfolio Module! While working on a full release of all our themes and modules we saw an oppurtunity to re-invent our portfolio solution and wrote a new module from scratch, ensuring compatibility and ease of maintenance across Drupal 7 and Drupal 8 ecosystems. We're telling you that our new portfolio module is better, faster, sexier, and easier to use than any portfolio module you're used before, on Drupal or elsewhere.

Creating Professional Portfolio Views Has Never Been Easier

You only have mere seconds to impress people with your website. SooperThemes Portfolio offers 65 design settings and unlimited control over animation, color, and content to help you get it right the first time.

Leverage query building, ordering, and contextualization that made Views and Drupal big. Whether you're displaying nodes, files, or custom entities SooperThemes Portfolio will handle it.

65 Settings, 14 Caption Designs, Advanced Motion Design... And Still Easy To Use

As you've come to expect of SooperThemes' products customisability is something we pay attention to. Without being overbearing we provide settings that allow you to match your portfolio, showcase, or e-commerce grid to you site's branding and content. We implemented color pickers that support transparency, example caption designs, and individual motion design options for loading the image grid, filtering, and hovering items. 

Get the details on our portfolio module landing page:Portfolio Drupal Module
Upgrading Your Drupal 7 Site From Glazed Portfolio/MD Portfolio

First of all, if Glazed Portfolio is working fine for you, you don't have to upgrade. While the new module provides more features and easier customisability this doesn't mean it's worth your time to configure new views with SooperThemes Portfolio  if you're going to end up with the same design that was already working fine for you.

However, if your portfolio views are up for a make-over, or if some of the little bugs and limitations in the old module are bothering you this is the time to upgrade! Since both modules are based on the same grid system the views settings will be familiar. 

Upgrading is very simple:

1. Install new module

2. Create new view or edit example view. Customize to your liking

3. Reference the new view in your menu links and drag and drop pages

4. Uninstall glazed portfolio/MD Portfolio

Where are Drupal 8 Glazed Builder and Glazed Theme at?

Releasing SooperThemes Portfolio is just one of the stepping stones on the way to a full Drupal 8 release for our flagship products. The only 2 remaining stepping stones are finalization of our Entity Browser/Media integration in Glazed Builder and the migration of our theme demos to the Drupal 8 ecosystem. The release itself will take some work in terms of updating our provisioning software and content/documentation on sooperthemes.com. Expect new updates in December!

qed42.com: Override existing Configuration entity types - Drupal 8

22. November 2017 - 10:16
Override existing Configuration entity types - Drupal 8 Body

Why do we need to override Config Entity Types?

  1. By default, Vocabulary list displays all the vocabularies. In case we want to restrict certain roles from viewing certain vocabularies. Overriding that Class(VocabularyListBuilder) function would be the solution to display specific/no/all vocabularies.
  2. Let's assume we need to specify vocabulary-path for each vocabulary apart from name, title, description, vid etc. In this case we would need to override the default Vocabulary Form of taxonomy_vocabulary config entity type.
  3. Suppose we want to custom access check for views on the basis of role/user/views operation or whatever, we would need to override ViewsAccessControllerhandler of view configEntityType and write our own logic.
  4. Another use case can be, if we want to display all the image fields which use image style being deleted, on confirm text message, we again need to override ImageStyleFlushForm class and redefine getconfirmText function.

In short, to customise and meet our dynamic requirements which may not be supported by config entity type definition as a part of @ConfigEntityType annotations in core or contributed modules, we need to override existing config entity types and write some custom code :).

How can we override Config Entity Types?

Entity types use object based annotation unlike array based annotation which is commonly used. Also, Unlike Content Entity Types where every thing is a field, NOTHING is a field for Configuration Entity type.

Every Drupal config entity type is defined as a particular ConfigEntityType Annotation. Entity controller is completely different from the Controller of MVC pattern. To avoid this confusion in terminology Entity Controllers are termed as handlers, each form related to a particular entity type say taxonomy_vocabulary is declared inside handlers with form key. 

In this article, will take an example of adding custom form elements to config entity type forms to explain this.

In case we need to add a custom element to any of these forms, we need to follow these 2 steps:

I) Set a new handler class specific to that form.

  1. Implement hook_entity_type_alter(array &$entity_types).
  2. Set new handler class as :  $entity_types[{id}]->setHandlerClass('form', ['{form_type}' => 'Drupal\my_module\MyModuleForm', '....', '....' ]);

    where, id = configEntityType id,  form_type eg: default, reset, delete etc is whichever form we want to override and MyModuleForm is the Class name of new form we'll define in Step II.
    Here is the sample code of overriding default form of taxonomy vocabulary.

    $entity_types['taxonomy_vocabulary']->setHandlerClass('form', ['default' => 'Drupal\my_module\VocabularyForm', 'reset' => 'Drupal\taxonomy\Form\VocabularyResetForm', 'delete' => 'Drupal\taxonomy\Form\VocabularyDeleteForm' ]);

     

II) Define the class set in Step I.

  1. Extend the actual class of the form we want to add new form elements to.  use Drupal\taxonomy\VocabularyForm as VocabularyFormBuilderBase;

    {this is optional, we need to do this to keep the new class name same as base class i.e VocabularyForm}.

    class MyModuleForm extends VocabularyFormBuilderBase

    OR simply, 

    class MyModuleForm extends VocabularyForm

    This override is important because we need to inherit functions and form elements defined in the parent class i.e VocabularyForm and also add additional feature i.e form element without disturbing the core code. This is purely OOPs concept of inheritance.

  2. We need to override the form function by 
    1. Inheriting the parent elements by parent::form(....) and
    2. Defining the new custom elements as the basic example below: $form['third_party_settings']['qed42_textfield'] = array( '#type' => 'textfield', '#title' => t('QED42 Custom Form Element'), '#default_value' => $vocabulary->getThirdPartySetting('my_module', 'qed42_textfield', 'Qed42 textfield default value') );

      Config Entities have by default "getThirdPartySetting()" function { Config entities inherit this function if these extend ConfigEntityBase class which implements ConfigEntityInterface interface which in turn extends ThirdPartySettingsInterface interface}. This thirdParty function allows to set and retrieve a value particularly for a module.

    3. Similarly, we can inherit the save function to save the value of newly added form element with Third Party Settings  as : 

      If the form is set as Tree we need to set value as

      $vocabulary->setThirdPartySetting('my_module', 'qed42_textfield', $form_state->getValue('third_party_settings')['qed42_textfield']);

      else :

      $vocabulary->setThirdPartySetting('my_module', 'qed42_textfield', $form_state->getValue('qed42_textfield'));

      and of course inherit the parent save function. 

    4. We can implement the same logic for extending definition of any existing method  AND can also define new functions inside our new Form.

Any Configuration Entity Type (Date format etc) can be overridden similarly, this can be extended to list_builder, access etc.  Apart from overriding, we can also add new flavours of entity controller using the above steps.

 

jyoti.bohra Wed, 11/22/2017 - 13:46

PreviousNext: Introducing the Display Suite Chained Fields module for Drupal 8

21. November 2017 - 23:41
Share:

Need a way to mix fields from referenced entities with regular fields from managed display?

Then the Display Suite Chained Fields module might be for you.

by Lee Rowlands / 22 November 2017

So how do you go about using the module?

Step 1: Enable a display suite layout for the view mode

To use the chained fields functionality, you must enable a display suite layout for the view mode. Select a layout other than none and hit Save.

Enabling a layoutStep 2: Enable the entity reference fields you wish to chain

To keep the manage display list from being cluttered, you must manually enable the entity reference fields you wish to show chained fields from. For example, to show the author's picture, you might enable the 'Authored by' entity reference field, which points to the author. After you've enabled the required fields, press Save.

Enabling fields for chainingStep 3: Configure the chained fields as required

Finally, just configure the chained fields as normal.

Configuring chained fields

That's it - let me know your thoughts in the comments or the the issue queue.

Tagged Drupal 8, Display Suite

Posted by Lee Rowlands
Senior Drupal Developer

Dated 22 November 2017

Add new comment

Chromatic: Common Drupal Problems - Solutions Included

21. November 2017 - 19:27

Whether you are a Drupal newcomer or a seasoned Drupal developer, you're bound to run into one, some, or all of the issues outlined below. Some are obvious, some not so obvious, but we'll show you how to troubleshoot them all regardless.

Elevated Third: WEBINAR: How NFPA Is Bringing Paper Processes Online With Drupal 8

21. November 2017 - 18:16
WEBINAR: How NFPA Is Bringing Paper Processes Online With Drupal 8 WEBINAR: How NFPA Is Bringing Paper Processes Online With Drupal 8 Nick Switzer Tue, 11/21/2017 - 09:16

Firewise USA™'s paper application process existed for 15 years but, in 2016, the Firewise team decided to bring the process online. They chose to build this process on top of Drupal 8.

Since moving to Drupal, the Wildfire Division of the National Fire Protection Association has streamlined their processes - enabling them to more efficiently deliver on their program’s goal: teaching individuals how to adapt to living with wildfires and take community action to prevent loss of property.

Join us, Acquia, and our client Aron to discuss the challenges and rewards of bringing a paper process online as a Drupal 8 web app. Topics we’ll discuss:

  • Leveraging an agile philosophy to respond quickly to change, collaborate across disciplines and stakeholder groups and get to a working product in as little time as possible.
  • Balancing effective deliverables with shared understanding to produce working software that meets the organization’s needs.
  • Organizational hurdles to overcome when adding structure and bringing an established paper application process online.