Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 20 hours 45 min ago

qed42.com: Securing Cookie for 3rd Party Identity Management in Drupal

30 October 2017 - 1:15am
Securing Cookie for 3rd Party Identity Management in Drupal Body

We are in an era where we see a lots of third party integrations being done in projects. In Drupal based projects, cookie management is done via Drupal itself to maintain session, whether it be a pure Drupal project or decoupled Drupal project,.

But what when we have a scenario where user’s information is being managed by a third party service and no user information is being saved on Drupal? And when the authentication is done via some other third party services? How can we manage cookie in this case to run our site session and also keep it secure?

One is way is to set and maintain cookie on our own. In this case, our user’s will be anonymous to Drupal. So, we keep session running based on cookies! The user information will be stored in cookie itself, which then can be validated when a request is made to Drupal.

We have a php function to set cookie called setCookie() , which we can use to create and destroy cookie. So, the flow will be that a user login request which is made to website is verified via a third party service and then we call setCookie function which sets the cookie containing user information. But, securing the cookie is must, so how do we do that?

For this, let’s refer to Bakery module to see how it does it. It contains functions for encrypting cookie, setting it and validating it.

To achieve this in Drupal 8, we will write a helper class let’s say “UserCookie.php” and place it in ‘{modulename}/src/Helper/’. Our cookie helper class will contain static methods for setting cookie and validating cookie. Static methods so that we will be able to call them from anywhere.

We will have to encrypt cookie before setting it so we will use openssl_encrypt() php function in following manner:

/** * Encrypts given cookie data. * * @param string $cookieData * Serialized Cookie data for encryption. * * @return string * Encrypted cookie. */ private static function encryptCookie($cookieData) { // Create a key using a string data. $key = openssl_digest(Settings::get('SOME_COOKIE_KEY'), 'sha256'); // Create an initialization vector to be used for encryption. $iv = openssl_random_pseudo_bytes(16); // Encrypt cookie data along with initialization vector so that initialization // vector can be used for decryption of this cookie. $encryptedCookie = openssl_encrypt($iv . $cookieData, 'aes-256-cbc', $key, OPENSSL_RAW_DATA, $iv); // Add a signature to cookie. $signature = hash_hmac('sha256', $encryptedCookie, $key); // Encode signature and cookie. return base64_encode($signature . $encryptedCookie); }
  1. String parameter in openssl_digest can be replaced with any string you feel like that can be used as key. You can keep simple keyword too.
  2. Key used should be same while decryption of data.
  3. Same initialization vector will be needed while decrypting the data, so to retrieve it back we append this along with cookie data string.
  4. We also add a signature which is generate used the same key used above. We will verify this key while validating cookie.
  5. Finally, we encode both signature and encrypted cookie data together.

For setting cookie:
 

/** * Set cookie using user data. * * @param string $name * Name of cookie to store. * @param mixed $data * Data to store in cookie. */ public static function setCookie($name, $data) { $data = (is_array($data)) ? json_encode($data) : $data; $data = self::encrypt($data); setcookie($name, $cookieData,Settings::get('SOME_DEFAULT_COOKIE_EXPIRE_TIME'), '/'); }

Note: You can keep 'SOME_COOKIE_KEY' and 'SOME_DEFAULT_COOKIE_EXPIRE_TIME' in your settings.php. Settings::get() will fetch that for you.
Tip: You can also append and save expiration time of cookie in encrypted data itself so that you can also verify that at time of decryption. This will stop anyone from extending the session by setting cookie timing manually.

Congrats! We have successfully encrypted the user data and set it into a cookie.

Now let’s see how we can decrypt and validate the same cookie.

To decrypt cookie:

/** * Decrypts the given cookie data. * * @param string $cookieData * Encrypted cookie data. * * @return bool|mixed * False if retrieved signature doesn't matches * or data. */ public static function decryptCookie($cookieData) { // Create a key using a string data used while encryption. $key = openssl_digest(Settings::get('SOME_COOKIE_KEY'), 'sha256'); // Reverse base64 encryption of $cookieData. $cookieData = base64_decode($cookieData); // Extract signature from cookie data. $signature = substr($cookieData, 0, 64); // Extract data without signature. $encryptedData = substr($cookieData, 64); // Signature should match for verification of data. if ($signature !== hash_hmac('sha256', $encryptedData, $key)) { return FALSE; } // Extract initialization vector from data appended while encryption. $iv = substr($string, 64, 16); // Extract main encrypted string data which contains profile details. $encrypted = substr($string, 80); // Decrypt the data using key and // initialization vector extracted above. return openssl_decrypt($encrypted, 'aes-256-cbc', $key, OPENSSL_RAW_DATA, $iv); }
  1. We generate the same key using same string parameter given while encryption.
  2. Then we reverse base64 encoding as we need extract signature to verify it.
  3. We generate same signature again as we have used the same key which was used to creating signature while encryption. If doesn’t signatures doesn’t matches, validation fails!
  4. Else, we extract initialization vector from the encrypted data and use to decrypt the data return to be utilized.
/** * Validates cookie. * * @param string $cookie * Name of cookie. * * @return boolean * True or False based on cookie validation. */ public static function validateCookie($cookie) { if (self::decryptCookie($cookieData)) { return TRUE; } return FALSE; }

We can verify cookie on requests made to website to maintain our session. You can implement function for expiring cookie for simulating user logout. We can also use decrypted user data out of cookie for serving user related pages.

navneet.singh Mon, 10/30/2017 - 13:45
Categories: Drupal

Matt Glaman: Using JSON API to query your Search API indexes

28 October 2017 - 8:18pm
Using JSON API to query your Search API indexes mglaman Sat, 10/28/2017 - 22:18 The JSON API module is becoming wildly popular for in Drupal 8 as an out of the box way to provide an API server. Why? Because it implements the {json:api} specification. It’s still a RESTful interface, but the specification just helps bring an open standard for how data should be represented and requests should be constructed. The JSON API module exposes collection routes, which allows retrieving multiple resources in a single request.
Categories: Drupal

Hook 42: Hook 42's BADCamp 2017 Takeaways

27 October 2017 - 12:43pm

This year at BADCamp we had the opportunity to share in thought leadership by leading a training, participating in the DevOps Summit, and presenting 5 sessions with topics ranging from accessibility, git, project management, A/B testing, and contributing to the Drupal issue queue.

Continuing in the spirit of thought leadership, we also want to share with the whole Drupal community our takeaways, thoughts, and excitement about the new ideas and technologies we learned at BADCamp.

Categories: Drupal

Lullabot: Effective Communication, Part 2: Crossing the Streams

27 October 2017 - 11:20am

The first article in this series helped us dismantle the various forms of communication, isolate common pitfalls, and set realistic expectations for the team. Now we'll dig a little deeper and explore effective communication techniques to help stakeholders, managers, and the development and design team work together in blissful symbiosis.

Makers vs Managers

First, we need to agree that all of these groups exist in different realms of the project.  What I mean by this is that each group is involved to a different degree and thus approaches the project with a unique mindset. One of my favorite articles outlining this concept is Paul Graham's 2009 post entitled "Maker's Schedule, Manager's Schedule."

Paul outlines the pitfalls of interrupting a "maker's" schedule with meetings. Managers run on a different style of schedule where meetings and context switching are a regular part of their workday. Makers, such as developers, need large blocks of uninterrupted focus to solve logic problems or hunt down a bug in the system. Remembering, preparing for, and attending meetings pulls the developer out of their "zone." And, as any developer will tell you, getting into that zone is much more difficult than being pulled out of it. This comic beautifully outlines the reason why you should never interrupt a programmer.

Minimize the Meetings

First, I'd like to talk to the meeting schedulers.  As we just outlined, meetings, or as most developers refer to them, "productivity crushing time sinks," are budgetary black holes when it comes to development. A one-hour meeting with a developer could cost two or more hours in productivity when you consider scheduling, prep and loss of focus. Lullabot Senior Developer, Juampy, wrote a great article on reforming this process. So when are meetings OK? Before scheduling one, ask yourself these questions:

  1. Could the information be exchanged via email?
  2. Could this information be rolled into a different, more encompassing meeting?
  3. Do we need to create a deliverable item?
  4. Will all invitees be involved?

I see a meeting being a valuable use of time when multiple people are brainstorming an idea and a deliverable needs to be produced as a result. The keystone of the decision being the interactivity of people. In the scope of a project, a meeting where the majority of invitees are present just to listen is a waste of time. Summarize the information in an email or a document and send it to people to read on their own. If the document is well constructed, follow up meetings and Q&A can be avoided completely and you just saved a boatload of time.

If you have decided that a meeting is necessary, consider who is critical to be involved in the meeting and who could stand to simply receive a summary of the decisions made. Inviting people to a meeting "just in case" is just another time sink. Furthermore, when you involve more people in a conversation, the lines of communication increase factorially, which leads to diluted discussions. Information is more easily processed and decisions made more quickly when there are fewer communication channels.

undefined

Keeping the meetings to a minimum removes the focus-busting barriers from your production team's workday, but you still need to be in the loop about the project. I've found that most meetings can be easily replaced with email, progress reports, or other project management tools. The benefit to the developers is that they can incorporate these tasks into their schedules in the most effective manner for them. For many stakeholders, however, meetings are how they stay connected to the project. If the meetings go away, other communication methods may fall in to replace them. That's not a bad thing, as long as expectations for how they should be used are set in advance.

Meeting Alternatives

How you structure these ground rules depends on the size and comfort level of both the development team and the stakeholders. A good project manager will sit in between to ensure the proper channels are used and are not being abused. At Lullabot, we often have the entire development team in the same Slack channel as the clients and set up a distribution mailing list for external stakeholders.

Before we get the project up to cruising altitude, we go over the safety speech with the client on how to use these tools effectively. For example, please don't fire off an email for every idea, bug, or individual task that comes to mind. This also goes for Slack pings. Consolidate your thoughts and send them out in a single request. If you truly want to be ignored and miss your deadline, ping the developer every time you send them an email to make sure they got it. Believe it or not, this has happened. Instead, work with the project manager and follow the communication guidelines outlined in the project charter or kickoff meeting. If all else fails, funnel your requests through the project manager and allow them to parse the necessary actions and assign them to the team. We'll discuss more on handling email effectively in the next article.

As a project manager, your place in the communication landscape could be lounging comfortably at the top of the hill enjoying the view, or you might be down in the weeds playing in the dirt. Teams will play nicely together in some projects and could be completely at odds in another. Your job is to keep the information flowing and the project on track.

Set the Ground Rules Early

When kicking off a project, the project manager should get stakeholders, developers, and designers together to discuss the expected frequency of communication and the proper channels to use for certain communications. For example, do you want your developers emailing the clients directly whenever they have a question? Or is it OK for stakeholders to ping developers on Slack every time they find what they consider to be a bug? Defining these ground rules in the project charter or at least in a formal kickoff meeting ensures that everyone is aware of the expectations and the channels are set to make the project run smoothly. It is very easy for clients to feel ignored or developers to feel overwhelmed if neither knows the right method or frequency to address their concerns.

Keep Your Focus  

Check in periodically with both stakeholders and the production team. Ensure the communication channels originally outlined are holding up and important information is not falling through the cracks. Make adjustments if needed, like increasing daily syncs or eliminating useless notifications. It’s easier to begin with fewer items in the communication landscape and add more as needed than it is to try and remove them later, so start lean.

Don't Overcomplicate the System

If you have some excellent communicators on your production team and the client is open to working with them, cautiously step out of the way and let the stakeholders and your team communicate directly. Given this responsibility, you might be surprised at the leaders you have hidden behind the screens. As a project manager, sometimes you can simplify the process by removing yourself!

"Don't add process for the sake of process. The fewer cogs in the machine, the simpler it is to maintain." -  Jerad Bitner, Lullabot Technical Project Manager

For more resources about effectively managing an agile system, check out Jerad’s article, "Lessons Learned in Scaling Agile."

Block Your Calendar

Lastly, here's a little trick for the production team I used when I worked in a meeting-heavy office environment. Coworkers had access to each others' calendars and could thus schedule meetings based on the attendees' availability, so I reduced my availability. I put two giant blocks of busy time over Tuesday and Thursday and made those my heads-down days.

undefined

This technique funneled most of my meetings into Wednesdays. I saved the smaller tasks that didn't require as much focused brain power to fill in the gaps in between meetings and hunkered down to attack the bigger tasks on those heads-down days. It was a huge productivity boost. Sometimes you need to control the communication flow however you can to get the work done.

We've covered a number of ways that the production team can work effectively with the stakeholders, and also how project managers can help facilitate that. Setting the ground rules early and avoiding unnecessary meetings go a long way to boosting productivity without sacrificing stability. The elephant in the room that we've been tip-toeing around is email. It is by far the most pervasive and invasive form of communication and deserves its own article's worth of attention.  Stay tuned for the next installment, where we'll discuss best practices as well as tips and tricks for dealing with a deluge of email.

In the meantime, if you have any suggestions of your own, I'd love to hear about them! How do you handle complex communication systems?

Categories: Drupal

OSTraining: Adding a MailChimp Newsletter to Your Drupal Site

27 October 2017 - 8:50am

Finding easy to use modules for Drupal 8 is not always easy. Often they haven't been migrated from Drupal 7. Or they are still in beta. Or the documentation is either poor or non-existent.

That's why finding the MailChimp module was a true delight. In this tutorial, you will learn how to use this module to integrate your Drupal 8 site with MailChimp newsletter service.

Categories: Drupal

Valuebound: Continuous integration using Jenkins and GitHub to automate deployment

27 October 2017 - 4:35am
Continuous Integration (CI) is rapidly becoming an integral part of software development process as it makes our monotonous and repetitive tasks a little less grindy. CI is a project development practice where developers integrate code into a shared repository frequently. Each Integration is then verified by an automated build that allows the team to detect problems in an early stage.

This post will walk you through the continuous integration with Jenkins and GitHub. Here we will install Jenkins, create Jenkins task and then configure it with GitHub.

Let’s get our arms around why Jenkins is so popular and why this is not just a hot topic, but an important best practice for developers…

Categories: Drupal

InternetDevels: Supercharge your Drupal 8 website with special powers of Views

27 October 2017 - 4:25am

The Views module lets even non-developers organize and present the website's content in the desired ways. Website administrators love it, Drupal newbies start with it, and Drupal ninjas perform miracles with it. No wonder it used to be the most downloadable contributed module. Well, it still is — in Drupal 7.

Read more
Categories: Drupal

Colan Schwartz: Representing Drupal at the GSoC 2017 Mentor Summit

26 October 2017 - 6:25pm
Topics:  I've been mentoring students as part of Drupal's Google Summer of Code (GSoC) program for the last two years, where we guide students in working on Drupal projects over the summer. (For the projects I've been involved in, see User-friendly encryption now in Drupal 8! and Client-side encryption options now available in Drupal.) This year, our organization administrator, Matthew Lechleider, invited my to the Mentor Summit.

The Google-provided summit creates a forum for members of free/libre and open-source software (FLOSS) organizations to come together to discuss GSoC, mentoring and FLOSS in an unconference format. I met attendees from all over the world, who flew in from far-reaching places to interact as part of a wider community. Generally, two mentors are invited from each organization, but some had more and some had less.

I arrived late Friday night, having missed that day's introductory sessions due to some trouble at the US border. Historically, in my experience, we Canadians haven't had too much trouble getting across the border for technology conferences. This has recently changed so it's now necessary to provide proof of intent for being in the country (a signed invitation from the organizers) as well as proof of business activities (corporate and tax documents). Needless to say, all of this took a significant amount of time to prepare. Eventually though, I was allowed through and made my way to Sunnyvale, California.

On Saturday morning, the day started with Lightning Talks, where attendees gave presentations on their student projects having only a few minutes each to speak. There were so many presentations that it was necessary to split the session into two, continuing after dinner that same evening. While there were several interesting projects highlighted, the most interesting to me was Jitsi's speech-to-text service. Besides making video conferences accessible through textual media, it also allows for automated note-taking. This was one of the truly amazing projects completed by a student over the summer.

In talking about Drupal with other folks, I was surprised to hear that many other delegates do not have paying day jobs associated with their organizations. They work on these projects on the side, and generally don't get paid for them. For example, nobody in the Kodi contributor community gets paid; it's all volunteer work. While there are volunteer contributions to Drupal, many of those contributors eventually turn that knowledge into paid work. I suppose we're a lucky bunch, being able to work on an open-source project and get paid for it. And speaking of Kodi, I'm happy to report that they're using Drupal for their Web site!

There were quite a few conversations about messaging applications, with a large XMPP delegation. There were also folks from the Zulip and Rocket.Chat communities. It was interesting to hear from a former XMPP developer who's shifted completely to Matrix with the Riot client, exactly as I've done. I use that client and the federated protocol to bridge with other communications networks such as proprietary closed-source Slack and classic Internet Relay Chat (IRC) whenever possible. Matrix already integrates with these two protocols, and has built-in support. The goal is to eventually use only one messaging client, instead of the many applications we all have installed on all of our devices. Rocket.Chat has already started working on Matrix integration, while Zulip hasn't. They're open to it, and may move in this direction eventually, but for now they're focused on user-experience innovations. In the Drupal community, we've had a very long discussion about using Matrix for our communications alongside IRC, and have finally put a plan into place to make this happen. For those eager to jump in, it's now possible to use Matrix as an always-on IRC bouncer client to connect to Drupal's IRC channels for communication within the community. To sum up, it looks as though everything is moving towards Matrix.

Alongside Drupal, representatives from other content management systems (CMSes) also attended. There were folks from both the Joomla and Plone communities. It would have been great to connect with them, but I didn't get a chance. I was hoping that Airship would have representation as that crew has been doing a lot of excellent security work with PHP projects (including helping us).

All in all, it was an excellent conference. In my humble opinion, it's really important to stay in touch with this greater community, cross-pollinate with folks doing similar work in the public interest, and keep contributing!

This article, Representing Drupal at the GSoC 2017 Mentor Summit, appeared first on the Colan Schwartz Consulting Services blog.

Categories: Drupal

PreviousNext: Sending Drupal entities to dialogflow with Chatbot API module

26 October 2017 - 3:16pm
Share:

Services like dialogflow (formerly api.ai) do a much better job of natural language parsing (NLP) if they're aware of your entity names in advance.

For example, it can recognize that show me the weather in Bundaberg is a request for weather in Bundaberg, if you've told it ahead of time that Bundaberg is a valid value for the City entity.

Having the entity values automatically update in your service of choice when they're created and changed in Drupal makes this much more efficient.

This article will show you how to achieve that.

by Lee Rowlands / 27 October 2017

This is where the chatbot_api_entities sub-module comes in.

When you enable this module you can browse to Admin -> Config -> Web Services -> Entity Collections to create a collection.

The UI looks something like this:

Adding an entity collection to send to dialogflow in Drupal

Each collection comprises an entity-type and bundle as well as a push handler and a query handler.

By default Chatbot API Entities comes with a query handler for each entity-type and a specific one for Users to exclude blocked users.

The api_ai_webhook module comes with a push handler for pushing entities to your dialogflow/api.ai account.

By default, these plugins query based on available entities and the push handler pushes the entity labels.

Writing your own query handler

If for example, you don't want to extract entities from entity labels, e.g. you might wish to collect unique values from a particular field. In this case you can write your own query handler.

Here's an example that will query speaker names from a session content type. The collection handed to the push handler will contain all published sessions.

namespace Drupal\your_module\Plugin\ChatbotApiEntities\QueryHandler; use Drupal\chatbot_api_entities\Entity\EntityCollectionInterface; use Drupal\chatbot_api_entities\Plugin\QueryHandlerBase; use Drupal\Core\Entity\EntityTypeManagerInterface; /** * Defines a query handler that just uses entity query to limit as appropriate. * * @QueryHandler( * id = "speakers", * label = @Translation("Query speakers from sessions"), * ) */ class SpeakerQuery extends QueryHandlerBase { /** * {@inheritdoc} */ public function query(EntityTypeManagerInterface $entityTypeManager, array $existing = [], EntityCollectionInterface $collection) { $storage = $entityTypeManager->getStorage('node'); return $storage->loadMultiple($storage->getQuery() ->condition('type', 'session') ->exists('field_speaker_name') ->condition('status', 1) ->execute()); } /** * {@inheritdoc} */ public function applies($entity_type_id) { return $entity_type_id === 'node'; } }Writing your own push handler

Whilst we've written our own query handler to load entities that we wish to extract values from, we need to write our own push handler to handle sending anything other than the label.

Here's an example push handler that will push field values as entities to Api.ai/dialogflow

<?php namespace Drupal\your_module\Plugin\ChatbotApiEntities\PushHandler; use Drupal\api_ai_webhook\Plugin\ChatbotApiEntities\PushHandler\ApiAiPushHandler; use Drupal\chatbot_api_entities\Entity\EntityCollection; use Drupal\Core\Entity\EntityInterface; /** * Defines a handler for pushing entities to api.ai. * * @PushHandler( * id = "api_ai_webhook_speakers", * label = @Translation("API AI entities endpoint (speakers)") * ) */ class SpeakerPush extends ApiAiPushHandler { /** * {@inheritdoc} */ protected function formatEntries(array $entities, EntityCollection $entityCollection) { // Format for API.ai/dialogflow. return array_map(function ($item) { return [ 'value' => $item, 'synonyms' => [], ]; }, // Key by name to remove duplicates. array_reduce($entities, function (array $carry, EntityInterface $entity) { $value = $entity->field_speaker_name->value; $carry[$value] = $value; return $carry; }, [])); } } Learn more

If you're interested in learning more about Chatbots and conversational UI with Drupal, I'm presenting a session on these topics at Drupal South 2017, the Southern Hemisphere's biggest Drupal Camp. October 31st is the deadline for getting your tickets at standard prices, so if you plan to attend, be sure to get yours this week to avoid the price hike.

I hope to see you there.

Tagged AI, Natural Language Parsing, Chatbot, Drupal 8

Posted by Lee Rowlands
Senior Drupal Developer

Dated 27 October 2017

Add new comment
Categories: Drupal

Dries Buytaert: Shopping with augmented reality

26 October 2017 - 10:34am

Last spring, Acquia Labs built a chatbot prototype that helps customers choose recipes and plan shopping lists with dietary restrictions and preferences in mind. The ability to interact with a chatbot assistant rather than having to research and plan everything on your own can make grocery shopping much easier. We wanted to take this a step further and explore how augmented reality could also improve the shopping experience.


The demo video above features how a shopper named Alex can interact with an augmented reality application to remove friction from her shopping experience at Freshland Market (a fictional grocery store). The Freshland Market mobile application not only guides Alex through her shopping list but also helps her to make more informed shopping decisions through augmented reality overlays. It superimposes useful information such as price, user ratings and recommended recipes, over shopping items detected by a smartphone camera. The application can personalize Alex's shopping experience by highlighting products that fit her dietary restrictions or preferences.

What is exciting about this demo is that the Acquia Labs team built the Freshland Market application with Drupal 8 and augmented reality technology that is commercially available today.

The first step in developing the application was to use an augmented reality library, Vuforia, which identifies pre-configured targets. In our demo, these targets are images of product labels, such as the tomato sauce and cereal labels shown in the video. Each target is given a unique ID. This ID is used to query the Freshland Market Drupal site for content related to that target.

The Freshland Market site stores all of the product information in Drupal, including price, dietary concerns, and reviews. Thanks to Drupal's web services support and the JSON API module, Drupal 8 can serve content to the Freshland Market application. This means that if the Drupal content for Rosemary & Olive Oil chips is edited to mark the item on sale, this will automatically be reflected in the content superimposed through the mobile application.

In addition to information on price and nutrition, the Freshland Market site also stores the location of each product. This makes it possible to guide a shopper to the product's location in the store, evolving the shopping list into a shopping route. This makes finding grocery items easy.

Augmented reality is building momentum because it moves beyond the limits of a traditional user interface, or in our case, the traditional website. It superimposes a digital layer onto a user's actual world. This technology is still emerging, and is not as established as virtual assistants and wearables, but it continues to gain traction. In 2016, the augmented reality market was valued at $2.39 billion and it is expected to reach $61.39 billion by 2023.

What is exciting is that these new technology trends require content management solutions. In the featured demo, there is a large volume of product data and content that needs to be managed in order to serve the augmented reality capabilities of the Freshland Market mobile application. The Drupal community's emphasis on making Drupal API-first in addition to supporting distributions like Reservoir means that Drupal 8 is prepared to support emerging channels.

If you are ready to start reimagining how your organization interacts with its users, or how to take advantage of new technology trends, Acquia Labs is here to help.

Special thanks to Chris Hamper and Preston So for building the Freshland Market augmented reality application, and thank you to Ash Heath and Drew Robertson for producing the demo video.

Categories: Drupal

Acro Media: Video: Reporting in Drupal Commerce 2.x is Going to be Great!

26 October 2017 - 8:08am


The good news is that Commerce 2.x has the potential to handle tons of different reports and display the data any way you want. The dashboard is complete and the framework is impressive. The catch is that many of the reports don’t technically exist yet, so you need to do a little configuring to make sure you’re looking at the data that’s most important to you.

What kind of reports are we talking about?

You could have a whole suite of point-of-sale reports, for instance (in Commerce 1, they were their own set of reports; in Commerce 2, they just build on Commerce reporting). If you need reports for checkout, or cart, or analytics, you can have them all in the Commerce reporting suite, even if they are vastly different types of reports. So you can have reports for different people who manage different metrics, but you can build them all using the same framework.

Categories: Drupal

Appnovation Technologies: Meet the Appnovation Fall 2017 Co-ops

26 October 2017 - 12:00am
Meet the Appnovation Fall 2017 Co-ops Get to know Appnovation's Fall 2017 cohort of post-secondary co-op students. This September 2017 has been both busy and exciting here at Appnovation! We've relocated to a brand new office in the Railtown area of Vancouver, BC, we've hopped into a brand new fiscal year, and we've hired a super cool group of co-op students to help break in the n...
Categories: Drupal

PreviousNext: Lightning talk: Database Deadlocks & Render caching - A case study

25 October 2017 - 7:46pm
Share:

In this week's Lightning talk, I go through a case study on an investigation into Deadlocks and Render caching and why cache contexts are so important to get right. Check out the video below to find out how we were able to withstand 10x the throughput with smarter caching.

by Adam Bramley / 26 October 2017 Tagged Cache Contexts, Drupal 8

Posted by Adam Bramley
Senior Drupal Developer

Dated 26 October 2017

Add new comment
Categories: Drupal

Agiledrop.com Blog: AGILEDROP: History of the Druplicon, the famous Drupal symbol

25 October 2017 - 6:54pm
Does everybody know a story how the Drupal was created? It's quite interesting. Dries Buytaert and Hans Snijder were students at the University of Antwerp back in 2000. Back then a broadband internet connection was a luxury, so Hans and Dries set up a wireless bridge among the student dorms to share Hans’s ADSL modem connection among eight students. Dries made an online forum, where they shared news like where they were meeting, having dinner, etc. This software was nameless for a while. Then Dries graduated and left the dorm. They wanted to stay in touch so the internal site had to go… READ MORE
Categories: Drupal

Lullabot: Decoupled Drupal Hard Problems: Image Styles

25 October 2017 - 3:52pm

As part of the API-First Drupal initiative, and the Contenta CMS community effort, we have come up with a solution for using Drupal image styles in a decoupled setup. Here is an overview of the problems we sought to solve:

  • Image styles are tied to the designs of the consumer, therefore belonging to the front-end. However, there are technical limitations in the front-end that make it impossible to handle them there.
  • Our HTTP API serves an unknown number of consumers, but we don't want to expose all image styles to all consumers for all images. Therefore, consumers need to declare their needs when making API requests.
  • The Consumers and Consumer Image Styles modules can solve these issues, but it requires some configuration from the consumer development team.
Image Styles Are Great

Drupal developers are used to the concept of image styles (aka image derivatives, image cache, resized images, etc.). We use them all the time because they are a way to optimize performance on our Drupal-rendered web pages. At the theme layer, the render system will detect the configuration on the image size and will crop it appropriately if the design requires it. We can do this because the back-end is informed of how the image is presented.

In addition to this, Drupal adds a token to the image style URLs. With that token, the Drupal server is saying I know your design needs this image style, so I approve the use of it. This is needed to avoid a malicious user to fill up our disk by manually requesting all the combinations of images and image styles. With this protection, only the combinations that are in our designs will be possible because Drupal is giving a seal of approval. This is transparent to us so our server is protected without even realizing this was a risk.

The monolithic architecture allows us to have the back-end informed about the design. We can take advantage of that situation to provide advanced features.

The Problem

In a decoupled application your back-end service and your front-end consumer are separated. Your back-end serves your content, and your front-end consumer displays and modifies it. Back-end and front-end live in different stacks and are independent of each other. In fact, you may be running a back-end that exposes a public API without knowing which consumers are using that content or how they are using it.

In this situation, we can see how our back-end doesn't know anything about the front-end(s) design(s). Therefore we cannot take advantage of the situation like we could in the monolithic solution.

The most intuitive solution would be to output all the image styles available when requesting images via JSON API (or REST core). This will only work if we have a small set of consumers of our API and we can know the designs for those. Imagine that our API serves to three, and only three, consumers A, B and C. If we did that, then when requesting an image from consumer A we would output all the variations for all the image styles for all the consumers. If each consumer has 10 - 15 image styles, that means 30 - 45 image styles URLs, where only one will be used.

undefined

This situation is not ideal because a malicious user can still generate 45 images in our disk for each image available in our content. Additionally, if we consider adding more consumers to our digital experience we risk making this problem worse. Moreover, we don't want the presentation from one consumer sipping through another consumer. Finally, if we can't know the designs for all our consumers, then this solution is not even on the table because we don't know what image styles we need to add to our back-end.

On top of all these problems regarding the separation of concerns of front-end and back-end, there are several technical limitations to overcome. In the particular case of image styles, if we were to process the raw images in the consumer we would need:

  • An application runner able to do these operations. The browser is capable of this, but other more challenged devices won't.
  • A powerful hardware to compute image manipulations. APIs often serve content to hardware with low resources.
  • A high bandwidth environment. We would need to serve a very high-resolution image every time, even if the consumer will resize it to 100 x 100 pixels.

Given all these, we decided that this task was best suited for a server-side technology.

In order to solve this problem as part of the API-First initiative, we want a generic solution that works even in the worst case scenario. This scenario is an API served by Drupal that serves an unknown number of 3rd party applications over which we don't have any control.

How We Solved It

After some research about how other systems tackle this, we established that we need a way for consumers to declare their presentation dependencies. In particular, we want to provide a way to express the image styles that consumer developers want for their application. The requests issued by an iOS application will carry a token that identifies the consumer where the HTTP request originated. That way the back-end server knows to select the image styles associated with that consumer.

undefined

For this solution, we developed two different contributed modules: Consumers, and Consumer Image Styles.

The Consumers Project

Imagine for a moment that we are running Facebook's back-end. We defined the data model, we have created a web service to expose the information, and now we are ready to expose that API to the world. The intention is that any developer can join Facebook and register an application. In that application record, the developer does some configuration and tweaks some features so the back-end service can interact optimally with the registered application. As the manager of Facebook's web services, we are not to take special request from any of the possible applications. In fact, we don't even know which applications integrate with our service.

The Consumers module aims to replicate this feature. It is a centralized place where other modules can require information about the consumers. The front-end development teams of each consumer are responsible for providing that information.

This module adds an entity type called Consumer. Other modules can add fields to this entity type with the information they want to gather about the consumer. For instance:

  • The Consumer Image Styles module adds a field that allows consumer developers to list all the image styles their application needs.
  • Other modules could add fields related to authentication, like OAuth 2.0.
  • Other could gather information for analytic purposes.
  • Maybe even configuration to integrate with other 3rd party platforms, etc.
The Consumer Image Styles Project

Internally, the Consumers module takes a request containing the consumer ID and returns the consumer entity. That entity contains the list of image styles needed by that consumer. Using that list of image styles Consumer Image Styles integrates with the JSON API module and adds the URLs for the image after applying those styles. These URLs are added to the response, in the meta section of the file resource. The Consumers project page describes how to provide the consumer ID in your request.

{ "data": { "type": "files", "id": "3802d937-d4e9-429a-a524-85993a84c3ed" "attributes": { … }, "relationships": { … }, "links": { … }, "meta": { "derivatives": { "200x200": "https://cms.contentacms.io/sites/default/files/styles/200x200/public/boyFYUN8.png?itok=Pbmn7Tyt", "800x600": "https://cms.contentacms.io/sites/default/files/styles/800x600/public/boyFYUN8.png?itok=Pbmn7Tyt" } } } }

To do that, Consumer Image Styles adds an additional normalizer for the image files. This normalizer adds the meta section with the image style URLs.

Conclusion

We recommend having a strict separation between the back-end and the front-end in a decoupled architecture. However, there are some specific problems, like image styles, where the server needs to have some knowledge about the consumer. In these very few occasions the server should not implement special logic for any particular consumer. Instead, we should have the consumers add their configuration to the server.

The Consumers project will help you provide a unified way for app developers to include this information in the server. Consumer Image Styles and OAuth 2.0 are good examples where that is necessary, and examples on how to implement it.

Further Your Understanding

If you are interested in alternative ways to deal with image derivatives in a decoupled architecture. There are other alternatives that may incur extra costs, but still worth checking: Cloudinary, Akamai Image Converter, and Origami.

Hero Image by Sadman Sakib

Categories: Drupal

Drupal Commerce: Beta release for Commerce Discount 7.x-1.0

25 October 2017 - 2:30pm

Commerce Discount improves Commerce 1.x by providing a custom entity type for managing Product and Order level discounts, including more complicated discounts like free shipping upgrades and BOGO offers. The module makes it easier for merchants to create promotions that would otherwise require the use of the Rules UI or even custom code, tasks that are similarly beyond the reach of most casual Drupal users.

Even as we've worked to improve the user experience even further in Commerce 2.x by making Promotions a core module, we continue to work to do to improve the experience for 1.x users. Today, after a month of focused contrib time at Commerce Guys team and review from end users like Thomas Jonas at the University of Minnesota, we're proud to announce the release of a long overdue beta version for the module.

Categories: Drupal

Mediacurrent: DrupalCamp Atlanta 2017 Highlights

25 October 2017 - 1:32pm

It's official: the countdown to DrupalCamp Atlanta is on. In just two weeks (November 2 - November 4), Mediacurrent will proudly sponsor another great camp in Buckhead, the tech center of ATL. Known for being a top Drupal event in the southeast, DCATL isn't one to miss. It's not too late to register!

Categories: Drupal

Bay Area Drupal Camp: BADCamp videos now available on the website!

25 October 2017 - 1:25pm
BADCamp videos now available on the website! Grace Lovelace Wed, 10/25/2017 - 1:25pm

Thank you! We had so much fun with all of you at BADCamp that we're already excited for next year!

Review what you learned and see what you missed!

Are there sessions you weren't able to attend at BADCamp this year? Or maybe you're back at work ready to apply what you learned and wishing you had better notes? Never fear! We took video of the slides from each presentation at BADCamp that includes audio from our expert speakers! Just visit our event schedule and click on the sessions you'd like to view. Videos are posted at the top of each session page. 

Share your feedback.

Please take a moment to let us know what you thought about BADCamp—it's just a few questions and will help us improve our future events.

Send Your Feedback

Join us at next year's BADCamp, October 24th through 27th, 2018! 

BADCamp Organizing Collective

Drupal Planet
Categories: Drupal

Elevated Third: Lessons Learned: Component Based Design with Paragraphs

25 October 2017 - 9:04am
Lessons Learned: Component Based Design with Paragraphs Lessons Learned: Component Based Design with Paragraphs Anthony Simone Wed, 10/25/2017 - 10:04

 

 

 

The ideas of Atomic Design and component based design allow one to create an established structure within which a large scale front end project can be built. The CMS space hasn’t always been the most friendly toward implementing these types of patterns. Whether it’s difficulty in creating a content architecture that models your front end design system within Drupal or the feeling of lack of control over generated markup, it can feel like an uphill battle.

The Paragraphs module gives us the tools to create much more well defined and structured component based architectures upon which modular front end systems can be built. The Paragraphs module, however, comes with no rules. As a site architect and front end developer, you must decide how to implement Paragraphs. There is definitely a lot of room for flexibility in implementation, but there are many best practices that can be followed to allow for a very clean, scalable, and extendable front end design system to be built within Drupal 8.

The goals of this session will be the following:

  • Review the basic concepts and benefits of component based design
  • Discuss the paragraphs module and how to create an implementation based on a well defined content architecture 
  • Explore some Drupal best practices that allow for a successful component based design system implementation
Categories: Drupal

Pages