Drupal Feeds

Social Auth Amazon

Latest Drupal Modules - Sun, 2018-01-14 12:49

This project is part of the Drupal Social Initiative and is based on the Social API.

Social Auth Amazon allows users to register and login to your Drupal site with their Amazon account. It is based on Social Auth and Social API projects.

This module adds a path user/login/amazon which redirects the user to Amazon for authentication.

Categories: Straight From Drupal

Billing API

Latest Drupal Modules - Sat, 2018-01-13 20:57
Categories: Straight From Drupal

Social Auth Reddit

Latest Drupal Modules - Sat, 2018-01-13 16:50

This project is part of the Drupal Social Initiative and is based on the Social API.

Social Auth Reddit allows users to register and login to your Drupal site with their Reddit account. It is based on Social Auth and Social API projects.

This module adds a path user/login/reddit which redirects the user to Reddit for authentication.

Categories: Straight From Drupal

Personalize Browscap Context

Latest Drupal Modules - Sat, 2018-01-13 16:46
INTRODUCTION

This module provides personalize contexts based on browscap data. There are available browscap properties:

  • Browser (IE, Chromem Firefox, etc.)
  • Platform (Win7, Win10, iOS, Android, Linux, etc. )
  • Is Mobile Device
  • Is Tablet
  • Device Type (Decktop, Console, Mobile Device, Tablet, etc.)

Based on options for each of those contexts it is possible to setup showing personalized content. Learn more about personalization in README.txt and project page of personalize module.

Categories: Straight From Drupal

Lullabot: The Out of the Box Initiative

Planet Drupal - Sat, 2018-01-13 15:42
Matt and Mike the ins and outs of Out of the Box initiative, which endeavors to showcase Drupal's power "out of the box." They are joined by some of the developers from the Out of the Box initiative.

Lullabot: The Out of the Box Initiative

Feeds from Drupal.org - Sat, 2018-01-13 15:42
Matt and Mike the ins and outs of Out of the Box initiative, which endeavors to showcase Drupal's power "out of the box." They are joined by some of the developers from the Out of the Box initiative.
Categories: Straight From Drupal

Titus

Latest Drupal Themes - Fri, 2018-01-12 22:45

Titus is a Drupal 8 administration theme, based on the Seven theme. It's designed to be a modern, seamless and visually pleasing admin experience.

Screenshots

Screenshots are available on Imgur.

Development & Testing

See Titus - Testing Distribution for testing details.

Categories: Straight From Drupal

Joachim's blog: Triggering events on the fly

Planet Drupal - Fri, 2018-01-12 21:45

As far as I know, there's nothing (yet) for triggering an arbitrary event. The complication is that every event uses a unique event class, whose constructor requires specific things passing, such as entities pertaining to the event.

Today I wanted to test the emails that Commerce sends when an order completes, and to avoid having to keep buying a product and sending it through checkout, I figured I'd mock the event object with Prophecy, mocking the methods that the OrderReceiptSubscriber calls (this is the class that does the sending of the order emails). Prophecy is a unit testing tool, but its objects can be created outside of PHPUnit quite easily.

Here's my quick code:

$order = entity_load('commerce_order', ORDER_ID); $prophet = new \Prophecy\Prophet; $event = $prophet->prophesize('Drupal\state_machine\Event\WorkflowTransitionEvent'); $event->getEntity()->willReturn($order); $subscriber = \Drupal::service('commerce_order.order_receipt_subscriber'); $subscriber->sendOrderReceipt($event->reveal());

Could some sort of generic tool be created for triggering any event in Drupal? Perhaps. We could use reflection to detect the methods on the event class, but at some point we need some real data for the event listeners to do something with. Here, I needed to load a specific order entity and to know which method on the event class returns it. For another event, I'd need some completely different entities and different methods.

We could maybe detect the type that the event method return (by sniffing in the docblock... once we go full PHP 7, we could use reflection on the return type), and the present an admin UI that shows a form element for each method, allowing you to enter an entity ID or a scalar value.

Still, you'd need to look at the code you want to run, the event listener, to know which of those you'd actually want to fill in.

Would it same more time than cobbling together code like the above? Only if you multiply it by a sufficiently large number of developers, as is the case with many developer tools.

It's the sort of idea I might have tinkered with back in the days when I had time. As it is, I'm just going to throw this idea out in the open.

Tags: eventsdeveloper tools

Joachim's blog: Triggering events on the fly

Feeds from Drupal.org - Fri, 2018-01-12 21:45

As far as I know, there's nothing (yet) for triggering an arbitrary event. The complication is that every event uses a unique event class, whose constructor requires specific things passing, such as entities pertaining to the event.

Today I wanted to test the emails that Commerce sends when an order completes, and to avoid having to keep buying a product and sending it through checkout, I figured I'd mock the event object with Prophecy, mocking the methods that the OrderReceiptSubscriber calls (this is the class that does the sending of the order emails). Prophecy is a unit testing tool, but its objects can be created outside of PHPUnit quite easily.

Here's my quick code:

$order = entity_load('commerce_order', ORDER_ID); $prophet = new \Prophecy\Prophet; $event = $prophet->prophesize('Drupal\state_machine\Event\WorkflowTransitionEvent'); $event->getEntity()->willReturn($order); $subscriber = \Drupal::service('commerce_order.order_receipt_subscriber'); $subscriber->sendOrderReceipt($event->reveal());

Could some sort of generic tool be created for triggering any event in Drupal? Perhaps. We could use reflection to detect the methods on the event class, but at some point we need some real data for the event listeners to do something with. Here, I needed to load a specific order entity and to know which method on the event class returns it. For another event, I'd need some completely different entities and different methods.

We could maybe detect the type that the event method return (by sniffing in the docblock... once we go full PHP 7, we could use reflection on the return type), and the present an admin UI that shows a form element for each method, allowing you to enter an entity ID or a scalar value.

Still, you'd need to look at the code you want to run, the event listener, to know which of those you'd actually want to fill in.

Would it same more time than cobbling together code like the above? Only if you multiply it by a sufficiently large number of developers, as is the case with many developer tools.

It's the sort of idea I might have tinkered with back in the days when I had time. As it is, I'm just going to throw this idea out in the open.

Tags: eventsdeveloper tools
Categories: Straight From Drupal

Echo Message To Log

Latest Drupal Modules - Fri, 2018-01-12 20:30

This module is extremely simple and just echos all Drupal error and warning messages to the Drupal log.

If you are trying to diagnose hard-to-reproduce user issues that include them seeing notifications, this module may help with doing that. You can also consider the logging_alerts module so that you receive an email when something is added to the log. The masquerade module is highly useful too of course, but sometimes user issues are hard to reproduce.

Categories: Straight From Drupal

Drupal core announcements: Drupal 8.5.0 will be released March 7; alpha begins week of January 17

Planet Drupal - Fri, 2018-01-12 20:12

Drupal 8.5.0, the next planned minor release of Drupal 8, is scheduled for Wednesday, March 7, 2018. Minor releases include new features, usability improvements, and backwards-compatible API improvements. Here's what this means now for core patches.

The goal of the alpha phase is to begin the preparation of the minor release and provide a testing target for theme or module developers and site owners. Alpha releases include most of the new features, API additions, and disruptive changes that will be in the upcoming minor version.

Drupal 8.5.0-alpha1 will be released the week of January 17

In preparation for the minor release, Drupal 8.5.x will enter the alpha phase the week of January 17, 2018. Core developers should plan to complete changes that are only allowed in minor releases prior to the alpha release. (More information on alpha and beta releases.)

  • Developers and site owners can begin testing the alpha next week.

  • The 8.6.x branch of core has been created, and future feature and API additions will be targeted against that branch instead of 8.5.x. All outstanding issues filed against 8.5.x will be automatically migrated to 8.6.

  • All issues filed against 8.4.x will then be migrated to 8.5.x, and subsequent bug reports should be targeted against the 8.5.x branch.

  • During the alpha phase, core issues will be committed according to the following policy:

    1. Most issues that are allowed for patch releases will be committed to 8.5.x and 8.6.x.

    2. Drupal 8.4.x will receive only critical bugfixes in preparation for its final patch release window. (Drupal 8.3.x and older versions are not supported anymore and changes are not made to those branches.)

    3. Most issues that are only allowed in minor releases will be committed to 8.6.x only. A few strategic issues may be backported to 8.5.x, but only at committer discretion after the issue is fixed in 8.6.x (so leave them set to 8.6.x unless you are a committer), and only up until the beta deadline.

Drupal 8.5.0-beta1 will be released the week of February 7

Roughly two weeks after the alpha release, the first beta release will be created. All the restrictions of the alpha release apply to beta releases as well. The release of the first beta is a firm deadline for all feature and API additions. Even if an issue is pending in the Reviewed & Tested by the Community (RTBC) queue when the commit freeze for the beta begins, it will be committed to the next minor release only.

The release candidate phase will begin the week of February 21, and we will post further details at that time. See the summarized key dates in the release cycle, allowed changes during the Drupal 8 release cycle, and Drupal 8 backwards compatibility and internal API policy for more information.

Drupal core announcements: Drupal 8.5.0 will be released March 7; alpha begins week of January 17

Feeds from Drupal.org - Fri, 2018-01-12 20:12

Drupal 8.5.0, the next planned minor release of Drupal 8, is scheduled for Wednesday, March 7, 2018. Minor releases include new features, usability improvements, and backwards-compatible API improvements. Here's what this means now for core patches.

The goal of the alpha phase is to begin the preparation of the minor release and provide a testing target for theme or module developers and site owners. Alpha releases include most of the new features, API additions, and disruptive changes that will be in the upcoming minor version.

Drupal 8.5.0-alpha1 will be released the week of January 17

In preparation for the minor release, Drupal 8.5.x will enter the alpha phase the week of January 17, 2018. Core developers should plan to complete changes that are only allowed in minor releases prior to the alpha release. (More information on alpha and beta releases.)

  • Developers and site owners can begin testing the alpha next week.

  • The 8.6.x branch of core has been created, and future feature and API additions will be targeted against that branch instead of 8.5.x. All outstanding issues filed against 8.5.x will be automatically migrated to 8.6.

  • All issues filed against 8.4.x will then be migrated to 8.5.x, and subsequent bug reports should be targeted against the 8.5.x branch.

  • During the alpha phase, core issues will be committed according to the following policy:

    1. Most issues that are allowed for patch releases will be committed to 8.5.x and 8.6.x.

    2. Drupal 8.4.x will receive only critical bugfixes in preparation for its final patch release window. (Drupal 8.3.x and older versions are not supported anymore and changes are not made to those branches.)

    3. Most issues that are only allowed in minor releases will be committed to 8.6.x only. A few strategic issues may be backported to 8.5.x, but only at committer discretion after the issue is fixed in 8.6.x (so leave them set to 8.6.x unless you are a committer), and only up until the beta deadline.

Drupal 8.5.0-beta1 will be released the week of February 7

Roughly two weeks after the alpha release, the first beta release will be created. All the restrictions of the alpha release apply to beta releases as well. The release of the first beta is a firm deadline for all feature and API additions. Even if an issue is pending in the Reviewed & Tested by the Community (RTBC) queue when the commit freeze for the beta begins, it will be committed to the next minor release only.

The release candidate phase will begin the week of February 21, and we will post further details at that time. See the summarized key dates in the release cycle, allowed changes during the Drupal 8 release cycle, and Drupal 8 backwards compatibility and internal API policy for more information.

Categories: Straight From Drupal

Get Social

Latest Drupal Modules - Fri, 2018-01-12 19:49

This module adds Get Social integration.

Categories: Straight From Drupal

Drupal blog: How to decouple Drupal in 2018

Planet Drupal - Fri, 2018-01-12 18:19

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

In this post, I'm providing some guidance on how and when to decouple Drupal.

Almost two years ago, I had written a blog post called "How should you decouple Drupal?". Many people have found the flowchart in that post to be useful in their decision-making on how to approach their Drupal architectures. Since that point, Drupal, its community, and the surrounding market have evolved, and the original flowchart needs a big update.

Drupal's API-first initiative has introduced new capabilities, and we've seen the advent of the Waterwheel ecosystem and API-first distributions like Reservoir, Headless Lightning, and Contenta. More developers both inside and outside the Drupal community are experimenting with Node.js and adopting fully decoupled architectures.

Let's start with the new flowchart in full:

How to Decouple Drupal in 2018 | Flowchart in Full

All the ways to decouple Drupal

The traditional approach to Drupal architecture, also referred to as coupled Drupal, is a monolithic implementation where Drupal maintains control over all front-end and back-end concerns. This is Drupal as we've known it — ideal for traditional websites. If you're a content creator, keeping Drupal in its coupled form is the optimal approach, especially if you want to achieve a fast time to market without as much reliance on front-end developers. But traditional Drupal 8 also remains a great approach for developers who love Drupal 8 and want it to own the entire stack.

A second approach, progressively decoupled Drupal, offers an approach that strikes a balance between editorial needs like layout management and developer desires to use more JavaScript, by interpolating a JavaScript framework into the Drupal front end. Progressive decoupling is in fact a spectrum, whether it is Drupal only rendering the page's shell and populating initial data — or JavaScript only controlling explicitly delineated sections of the page. Progressively decoupled Drupal hasn't taken the world by storm, likely because it's a mixture of both JavaScript and PHP and doesn't take advantage of server-side rendering via Node.js. Nonetheless, it's an attractive approach because it makes more compromises and offers features important to both editors and developers.

Last but not least, fully decoupled Drupal has gained more attention in recent years as the growth of JavaScript continues with no signs of slowing down. This involves a complete separation of concerns between the structure of your content and its presentation. In short, it's like treating your web experience as just another application that needs to be served content. Even though it results in a loss of some out-of-the-box CMS functionality such as in-place editing or content preview, it's been popular because of the freedom and control it offers front-end developers.

What do you intend to build?

How to Decouple Drupal in 2018 | What do you intend to build?

The most important question to ask is what you are trying to build.

  1. If your plan is to create a single standalone website or web application, decoupling Drupal may or may not be the right choice based on the must-have features your developers and editors are asking for.
  2. If your plan is to create multiple experiences (including web, native mobile, IoT, etc.), you can use Drupal to provide web service APIs that serve content to other experiences, either as (a) a content repository with no public-facing component or (b) a traditional website that is also a content repository at the same time.

Ultimately, your needs will determine the usefulness of decoupled Drupal for your use case. There is no technical reason to decouple if you're building a standalone website that needs editorial capabilities, but that doesn't mean people don't prefer to decouple because of their preference for JavaScript over PHP. Nonetheless, you need to pay close attention to the needs of your editors and ensure you aren't removing crucial features by using a decoupled approach. By the same token, you can't avoid decoupling Drupal if you're using it as a content repository for IoT or native applications. The next part of the flowchart will help you weigh those trade-offs.

Today, Drupal makes it much easier to build applications consuming decoupled Drupal. Even if you're using Drupal as a content repository to serve content to other applications, well-understood specifications like JSON API, GraphQL, OpenAPI, and CouchDB significantly lower its learning curve and open the door to tooling ecosystems provided by the communities who wrote those standards. In addition, there are now API-first distributions optimized to serve as content repositories and SDKs like Waterwheel.js that help developers "speak" Drupal.

Are there things you can't live without?

How to Decouple Drupal in 2018 | What can't you live without?

Perhaps most critical to any decision to decouple Drupal is the must-have feature set desired for both editors and developers. In order to determine whether you should use a decoupled Drupal, it's important to isolate which features are most valuable for your editors and developers. Unfortunately, there is are no black-and-white answers here; every project will have to weigh the different pros and cons.

For example, many marketing teams choose a CMS because they want to create landing pages, and a CMS gives them the ability to lay out content on a page, quickly reorganize a page and more. The ability to do all this without the aid of a developer can make or break a CMS in marketers' eyes. Similarly, many digital marketers value the option to edit content in the context of its preview and to do so across various workflow states. These kind of features typically get lost in a fully decoupled setting where Drupal does not exert control over the front end.

On the other hand, the need for control over the visual presentation of content can hinder developers who want to craft nuanced interactions or build user experiences in a particular way. Moreover, developer teams often want to use the latest and greatest technologies, and JavaScript is no exception. Nowadays, more JavaScript developers are including modern techniques, like server-side rendering and ES6 transpilation, in their toolboxes, and this is something decision-makers should take into account as well.

How you reconcile this tension between developers' needs and editors' requirements will dictate which approach you choose. For teams that have an entirely editorial focus and lack developer resources — or whose needs are focused on the ability to edit, place, and preview content in context — decoupling Drupal will remove all of the critical linkages within Drupal that allow editors to make such visual changes. But for teams with developers itching to have more flexibility and who don't need to cater to editors or marketers, fully decoupled Drupal can be freeing and allow developers to explore new paradigms in the industry — with the caveat that many of those features that editors value are now unavailable.

What will the future hold?

In the future, and in light of the rapid evolution of decoupled Drupal, my hope is that Drupal keeps shrinking the gap between developers and editors. After all, this was the original goal of the CMS in the first place: to help content authors write and assemble their own websites. Drupal's history has always been a balancing act between editorial needs and developers' needs, even as the number of experiences driven by Drupal grows.

I believe the next big hurdle is how to begin enabling marketers to administer all of the other channels appearing now and in the future with as much ease as they manage websites in Drupal today. In an ideal future, a content creator can build a content model once, preview content on every channel, and use familiar tools to edit and place content, regardless of whether the channel in question is mobile, chatbots, digital signs, or even augmented reality.

Today, developers are beginning to use Drupal not just as a content repository for their various applications but also as a means to create custom editorial interfaces. It's my hope that we'll see more experimentation around conceiving new editorial interfaces that help give content creators the control they need over a growing number of channels. At that point, I'm sure we'll need another new flowchart.

Conclusion

Thankfully, Drupal is in the right place at the right time. We've anticipated the new world of decoupled CMS architectures with web services in Drupal 8 and older contributed modules. More recently, API-first distributions, SDKs, and even reference applications in Ember and React are giving developers who have never heard of Drupal the tools to interact with it in unprecedented ways.

Unlike many other content management systems, old and new, Drupal provides a spectrum of architectural possibilities tuned to the diverse needs of different organizations. This flexibility between fully decoupling Drupal, progressively decoupling it, and traditional Drupal — in addition to each solution's proven robustness in the wild — gives teams the ability to make an educated decision about the best approach for them. This optionality sets Drupal apart from new headless content management systems and most SaaS platforms, and it also shows Drupal's maturity as a decoupled CMS over WordPress. In other words, it doesn't matter what the team looks like or what the project's requirements are; Drupal has the answer.

Special thanks to Preston So for contributions to this blog post and to Alex Bronstein, Angie Byron, Gabe Sullice, Samuel Mortenson, Ted Bowman and Wim Leers for their feedback during the writing process.

Drupal blog: How to decouple Drupal in 2018

Feeds from Drupal.org - Fri, 2018-01-12 18:19

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

In this post, I'm providing some guidance on how and when to decouple Drupal.

Almost two years ago, I had written a blog post called "How should you decouple Drupal?". Many people have found the flowchart in that post to be useful in their decision-making on how to approach their Drupal architectures. Since that point, Drupal, its community, and the surrounding market have evolved, and the original flowchart needs a big update.

Drupal's API-first initiative has introduced new capabilities, and we've seen the advent of the Waterwheel ecosystem and API-first distributions like Reservoir, Headless Lightning, and Contenta. More developers both inside and outside the Drupal community are experimenting with Node.js and adopting fully decoupled architectures.

Let's start with the new flowchart in full:

How to Decouple Drupal in 2018 | Flowchart in Full

All the ways to decouple Drupal

The traditional approach to Drupal architecture, also referred to as coupled Drupal, is a monolithic implementation where Drupal maintains control over all front-end and back-end concerns. This is Drupal as we've known it — ideal for traditional websites. If you're a content creator, keeping Drupal in its coupled form is the optimal approach, especially if you want to achieve a fast time to market without as much reliance on front-end developers. But traditional Drupal 8 also remains a great approach for developers who love Drupal 8 and want it to own the entire stack.

A second approach, progressively decoupled Drupal, offers an approach that strikes a balance between editorial needs like layout management and developer desires to use more JavaScript, by interpolating a JavaScript framework into the Drupal front end. Progressive decoupling is in fact a spectrum, whether it is Drupal only rendering the page's shell and populating initial data — or JavaScript only controlling explicitly delineated sections of the page. Progressively decoupled Drupal hasn't taken the world by storm, likely because it's a mixture of both JavaScript and PHP and doesn't take advantage of server-side rendering via Node.js. Nonetheless, it's an attractive approach because it makes more compromises and offers features important to both editors and developers.

Last but not least, fully decoupled Drupal has gained more attention in recent years as the growth of JavaScript continues with no signs of slowing down. This involves a complete separation of concerns between the structure of your content and its presentation. In short, it's like treating your web experience as just another application that needs to be served content. Even though it results in a loss of some out-of-the-box CMS functionality such as in-place editing or content preview, it's been popular because of the freedom and control it offers front-end developers.

What do you intend to build?

How to Decouple Drupal in 2018 | What do you intend to build?

The most important question to ask is what you are trying to build.

  1. If your plan is to create a single standalone website or web application, decoupling Drupal may or may not be the right choice based on the must-have features your developers and editors are asking for.
  2. If your plan is to create multiple experiences (including web, native mobile, IoT, etc.), you can use Drupal to provide web service APIs that serve content to other experiences, either as (a) a content repository with no public-facing component or (b) a traditional website that is also a content repository at the same time.

Ultimately, your needs will determine the usefulness of decoupled Drupal for your use case. There is no technical reason to decouple if you're building a standalone website that needs editorial capabilities, but that doesn't mean people don't prefer to decouple because of their preference for JavaScript over PHP. Nonetheless, you need to pay close attention to the needs of your editors and ensure you aren't removing crucial features by using a decoupled approach. By the same token, you can't avoid decoupling Drupal if you're using it as a content repository for IoT or native applications. The next part of the flowchart will help you weigh those trade-offs.

Today, Drupal makes it much easier to build applications consuming decoupled Drupal. Even if you're using Drupal as a content repository to serve content to other applications, well-understood specifications like JSON API, GraphQL, OpenAPI, and CouchDB significantly lower its learning curve and open the door to tooling ecosystems provided by the communities who wrote those standards. In addition, there are now API-first distributions optimized to serve as content repositories and SDKs like Waterwheel.js that help developers "speak" Drupal.

Are there things you can't live without?

How to Decouple Drupal in 2018 | What can't you live without?

Perhaps most critical to any decision to decouple Drupal is the must-have feature set desired for both editors and developers. In order to determine whether you should use a decoupled Drupal, it's important to isolate which features are most valuable for your editors and developers. Unfortunately, there is are no black-and-white answers here; every project will have to weigh the different pros and cons.

For example, many marketing teams choose a CMS because they want to create landing pages, and a CMS gives them the ability to lay out content on a page, quickly reorganize a page and more. The ability to do all this without the aid of a developer can make or break a CMS in marketers' eyes. Similarly, many digital marketers value the option to edit content in the context of its preview and to do so across various workflow states. These kind of features typically get lost in a fully decoupled setting where Drupal does not exert control over the front end.

On the other hand, the need for control over the visual presentation of content can hinder developers who want to craft nuanced interactions or build user experiences in a particular way. Moreover, developer teams often want to use the latest and greatest technologies, and JavaScript is no exception. Nowadays, more JavaScript developers are including modern techniques, like server-side rendering and ES6 transpilation, in their toolboxes, and this is something decision-makers should take into account as well.

How you reconcile this tension between developers' needs and editors' requirements will dictate which approach you choose. For teams that have an entirely editorial focus and lack developer resources — or whose needs are focused on the ability to edit, place, and preview content in context — decoupling Drupal will remove all of the critical linkages within Drupal that allow editors to make such visual changes. But for teams with developers itching to have more flexibility and who don't need to cater to editors or marketers, fully decoupled Drupal can be freeing and allow developers to explore new paradigms in the industry — with the caveat that many of those features that editors value are now unavailable.

What will the future hold?

In the future, and in light of the rapid evolution of decoupled Drupal, my hope is that Drupal keeps shrinking the gap between developers and editors. After all, this was the original goal of the CMS in the first place: to help content authors write and assemble their own websites. Drupal's history has always been a balancing act between editorial needs and developers' needs, even as the number of experiences driven by Drupal grows.

I believe the next big hurdle is how to begin enabling marketers to administer all of the other channels appearing now and in the future with as much ease as they manage websites in Drupal today. In an ideal future, a content creator can build a content model once, preview content on every channel, and use familiar tools to edit and place content, regardless of whether the channel in question is mobile, chatbots, digital signs, or even augmented reality.

Today, developers are beginning to use Drupal not just as a content repository for their various applications but also as a means to create custom editorial interfaces. It's my hope that we'll see more experimentation around conceiving new editorial interfaces that help give content creators the control they need over a growing number of channels. At that point, I'm sure we'll need another new flowchart.

Conclusion

Thankfully, Drupal is in the right place at the right time. We've anticipated the new world of decoupled CMS architectures with web services in Drupal 8 and older contributed modules. More recently, API-first distributions, SDKs, and even reference applications in Ember and React are giving developers who have never heard of Drupal the tools to interact with it in unprecedented ways.

Unlike many other content management systems, old and new, Drupal provides a spectrum of architectural possibilities tuned to the diverse needs of different organizations. This flexibility between fully decoupling Drupal, progressively decoupling it, and traditional Drupal — in addition to each solution's proven robustness in the wild — gives teams the ability to make an educated decision about the best approach for them. This optionality sets Drupal apart from new headless content management systems and most SaaS platforms, and it also shows Drupal's maturity as a decoupled CMS over WordPress. In other words, it doesn't matter what the team looks like or what the project's requirements are; Drupal has the answer.

Special thanks to Preston So for contributions to this blog post and to Alex Bronstein, Angie Byron, Gabe Sullice, Samuel Mortenson, Ted Bowman and Wim Leers for their feedback during the writing process.

Categories: Straight From Drupal

Commerce Toolbar

Latest Drupal Modules - Fri, 2018-01-12 17:07
Categories: Straight From Drupal

Valuebound: A beginners guide to caching in Drupal 8

Planet Drupal - Fri, 2018-01-12 16:38

Caching is a popular technique to optimize the performance of a website. It is a process that stores web data (HTML, CSS, Image) in some accessible space. Moreover, a cache is a detailed information of a validity of a resource. This information defines for how long the resource is valid and should not be considered stale. The information can be stored at every level right from the original server to intermediate proxies to the browser.

Here you will get to learn about what key/value pairs in the header mean and Cacheability metadata in Drupal 8.

Every request or response contains a HTTP header, which provides additional information about the request/response. This…

Valuebound: A beginners guide to caching in Drupal 8

Feeds from Drupal.org - Fri, 2018-01-12 16:38

Caching is a popular technique to optimize the performance of a website. It is a process that stores web data (HTML, CSS, Image) in some accessible space. Moreover, a cache is a detailed information of a validity of a resource. This information defines for how long the resource is valid and should not be considered stale. The information can be stored at every level right from the original server to intermediate proxies to the browser.

Here you will get to learn about what key/value pairs in the header mean and Cacheability metadata in Drupal 8.

Every request or response contains a HTTP header, which provides additional information about the request/response. This…

Categories: Straight From Drupal

CTI Digital: Drupalcamp London 2018

Planet Drupal - Fri, 2018-01-12 14:46
39001592592_21bacaa7c2_k-053582-edited


Drupalcamp London returns in March for its 6th year. As the largest Drupal camp in Europe, it provides a scale of high-quality knowledge I rarely see elsewhere. If you’re new to Drupalcons and camps, Drupalcamp is a three-day knowledge-sharing conference in London that attracts a wide variety of over 600 Drupal stakeholders, including developers, agencies, business owners, and end users.

CTI Digital: Drupalcamp London 2018

Feeds from Drupal.org - Fri, 2018-01-12 14:46
39001592592_21bacaa7c2_k-053582-edited


Drupalcamp London returns in March for its 6th year. As the largest Drupal camp in Europe, it provides a scale of high-quality knowledge I rarely see elsewhere. If you’re new to Drupalcons and camps, Drupalcamp is a three-day knowledge-sharing conference in London that attracts a wide variety of over 600 Drupal stakeholders, including developers, agencies, business owners, and end users.

Categories: Straight From Drupal

Pages

Subscribe to My Drupal aggregator