Planet Drupal

Subscribe to flux Planet Drupal
Drupal.org - aggregated feeds in category Planet Drupal
Mis à jour : il y a 58 min 23 sec

FFW Agency: Go Camping with Drupal This Summer

lun, 06/06/2016 - 18:21
Go Camping with Drupal This Summer Ray Saltini Mon, 06/06/2016 - 16:21

Why spend all your time at the beach when you can be learning even more about Drupal. Here are just a few of the camps our staff will be participating in this summer. We hope to see you there.

DrupalNorth

Drupal North in Montreal June 16 - 19 is a great regional event. FFW Manager of Learning and Contributions David Hernandez is presenting Managing CSS and JavaScript files in Drupal 8 with Libraries

GovCon

Join us at GovCon in Bethesda July 20-22 where we’re sponsoring a full day training with Drupal Console author and FFW Drupal 8 Solutions Engineer Jesus Olivas on Building Custom Drupal 8 features and modules.  FFW Center of Excellence Director Ray Saltini and FFW Manager of Learning and Contributions David Hernandez will be there presenting on Personalization Strategies for Government Websites and Managing CSS and JavaScript files in Drupal 8 with Libraries

NYC Camp

NYC Camp is back at the United Nations this year July 8  - 11. There’s too much learning going on to list it all here. Make sure you catch FFW Center of Excellence Director Ray Saltini’s presentation Radical Digital Transformation or Die

Twin Cities Drupal Camp

FFW Drupal 8 Solutions Engineer and Drupal Console project lead Jesus Olivas is giving a full day training at Twin Cities June 16 - 19 on Drupal 8 Module Building and presenting Improving Your Drupal 8 Development Workflow. Make sure you catch him and FFW Developer Tess Flynn who’s presenting Ride the Whale! Docker for Drupalists.

Tagged with Comments
Catégories: Elsewhere

Dries Buytaert: Gotthard tunnel website using Drupal

lun, 06/06/2016 - 18:17

The Gotthard Base Tunnel, under construction for the last 17 years, was officially opened last week. This is the world's longest and deepest railroad tunnel, spanning 57 kilometers from Erstfeld to Bolio, Switzerland, underneath the Swiss Alps. To celebrate its opening, Switzerland also launched a multi-lingual multimedia website to celebrate the project's completion. I was excited to see they chose to build their site on Drupal 8! The site is a fitting digital tribute to an incredible project and launch event. Congratulations to the Gotthard Base Tunnel team!

Catégories: Elsewhere

Four Kitchens: Launch Announcement: WOOD Magazine

lun, 06/06/2016 - 18:14

We’re pleased to announce the site launch of woodmagazine.com, the online presence of WOOD Magazine, “The World’s Leading Woodworking Resource.” The new site includes online-only content, free downloadable plans for home woodworking projects, an index of articles in the print magazine, community forums, and subscription management.

Catégories: Elsewhere

Dries Buytaert: Advancing Drupal's web services

lun, 06/06/2016 - 09:24

In an earlier blog post, I looked at the web services solutions available in Drupal 8 and compared their strengths and weaknesses. That blog post was intended to help developers choose between different solutions when building Drupal 8 sites. In this blog post, I want to talk about how to advance Drupal's web services beyond Drupal 8.1 for the benefit of Drupal core contributors, module creators and technical decision-makers.

I believe it is really important to continue advancing Drupal's web services support. There are powerful market trends that oblige us to keep focused on this: integration with diverse systems having their own APIs, the proliferation of new devices, the expanding Internet of Things (IoT), and the widening adoption of JavaScript frameworks. All of these depend to some degree on robust web services.

Moreover, newer headless content-as-a-service solutions (e.g. Contentful, Prismic.io, Backand and CloudCMS) have entered the market and represent a widening interest in content repositories enabling more flexible content delivery. They provide content modeling tools, easy-to-use tools to construct REST APIs, and SDKs for different programming languages and client-side frameworks.

In my view, we need to do the following, which I summarize in each of the following sections: (1) facilitate a single robust REST module in core; (2) add functionality to help web services modules more easily query and manipulate Drupal's entity graph; (3) incorporate GraphQL and JSON API out of the box; and (4) add SDKs enabling easy integration with Drupal. Though I shared some of this in my DrupalCon New Orleans keynote, I wanted to provide more details in this blog post. I'm hoping to discuss this and revise it based on feedback from you.

One great REST module in core

While core REST can be enabled with only a few configuration changes, the full extent of possibilities in Drupal is only unlocked either when leveraging modules which add to or work alongside core REST's functionality, such as Services or RELAXed, or when augmenting core REST's capabilities with additional resources to interact with (by providing corresponding plugins) or using other custom code.

Having such disparate REST modules complicates the experience. These REST modules have overlapping or conflicting feature sets, which are shown in the following table.

Feature Core REST RELAXed Services Ideal core REST Content entity CRUD Yes Yes Yes Yes Configuration entity CRUD Create resource plugin (issue) Create resource plugin Yes Yes Custom resources Create resource plugin Create resource plugin Create Services plugin Possible without code Custom routes Create resource plugin or Views REST export (GET) Create resource plugin Configurable route prefixes Possible without code Translations Not yet (issue) Yes Create Services plugin Yes Revisions Create resource plugin Yes Create Services plugin Yes File attachments Create resource plugin Yes Create Services plugin Yes Authenticated user resources (log in/out, password reset) Not yet (issue) No User login and logout Yes

I would like to see a convergence where all of these can be achieved in Drupal core with minimal configuration and minimal code.

Working with Drupal's entity graph

Recently, a discussion at DrupalCon New Orleans with key contributors to the core REST modules, maintainers of important contributed web services modules, and external observers led to a proposed path forward for all of Drupal's web services.

A visual example of an entity graph in Drupal.

Buried inside Drupal is an "entity graph" over which different API approaches like traditional REST, JSON API, and GraphQL can be layered. These varied approaches all traverse and manipulate Drupal's entity graph, with differences solely in the syntax and features made possible by that syntax. Unlike core's REST API which only returns a single level (single entity or lists of entities), GraphQL and JSON API can return multiple levels of nested entities as the result of a single query. To better understand what this means, have a look at the GraphQL demo video I shared in my DrupalCon Barcelona keynote.

What we concluded at DrupalCon New Orleans is that Drupal's GraphQL and JSON API implementations require a substantial amount of custom code to traverse and manipulate Drupal's entity graph, that there was a lot of duplication in that code, and that there is an opportunity to provide more flexibility and simplicity. Therefore, it was agreed that we should first focus on building an "entity graph iterator" that can be reused by JSON API, GraphQL, and other modules.

This entity graph iterator would also enable manipulation of the graph, e.g. for aliasing fields in the graph or simplifying the structure. For example, the difference between Drupal's "base fields" and "configured fields" is irrelevant to an application developer using Drupal's web services API, but Drupal's responses leak this internal distinction by prefixing configured fields with field_ (see the left column in the table below). By the same token, all fields, even if they carry single values, expose the verbosity of Drupal's typed data system by being presented as arrays (see the left column in the table below). While there are both advantages and disadvantages to exposing single-value fields as arrays, many developers prefer more control over the output or the ability to opt into simpler outputs.

A good Drupal entity graph iterator would simplify the development of Drupal web service APIs, provide more flexibility over naming and structure, and eliminate duplicate code.

Current core REST (shortened response) Ideal core REST (shortened response) { "nid": [ { "value": "2" } ], "title": [ { "value": "Lorem ipsum" } ], "field_product_number": [ { "value": "35" } ], "field_image": [ { "target_id": "2", "alt": "Image", "title": "Hover text", "width": "210", "height": "281", "url": "http://site.com/x.jpg" } ] } { "nid": "2" "title": "Lorem ipsum", "product_number": { "value": 35 }, "image": { "target_id": 2, "alt": "Image", "title": "Hover text", "width": 210, "height": 281, "url": "http://site.com/x.jpg" } } GraphQL and JSON API in core

We should acknowledge simultaneously that the wider JavaScript community is beginning to embrace different approaches, like JSON API and GraphQL, which both enable complex relational queries that require fewer requests between Drupal and the client (thanks to the ability to follow relationships, as mentioned in the section concerning the entity graph).

While both JSON API and GraphQL are preferred over traditional REST due to their ability to provide nested entity relationships, GraphQL goes a step further than JSON API by facilitating explicitly client-driven queries, in which the client dictates its data requirements.

I believe that GraphQL and JSON API in core would be a big win for those building decoupled applications with Drupal, and these modules can use existing foundations in Drupal 8 such as the Serialization module. Furthermore, Drupal's own built-in JavaScript-driven UIs could benefit tremendously from GraphQL and JSON API. I'd love to see them in core rather than as contributed modules, as we could leverage them when building decoupled applications backed by Drupal or exchanging data with other server-side implementations. We could also "eat our own dog food" by using them to power JavaScript-driven UIs for block placement, media management, and other administrative interfaces. I can even see a future where Views and GraphQL are closely integrated.

A comparison of different API approaches for Drupal 8, with amended and simplified payloads for illustrative purposes.

SDKs to consume web services

While a unified REST API and support for GraphQL and JSON API would dramatically improve Drupal as a web services back end, we need to be attentive to the needs of consumers of those web services as well by providing SDKs and helper libraries for developers new to Drupal.

An SDK could make it easy to retrieve an article node, modify a field, and send it back without having to learn the details of Drupal's particular REST API implementation or the structure of Drupal's underlying data storage. For example, this would allow front-end developers to not have to deal with the details of single- versus multi-value fields, optional vs required fields, validation errors, and so on. As an additional example, incorporating user account creation and password change requests into decoupled applications would empower front-end developers building these forms on a decoupled front end such that they would not need to know anything about how Drupal performs user authentication.

As starting points for JavaScript applications, native mobile applications, and even other back-end applications, these SDKs could handle authenticating against the API and juggling of the correct routes to resources without the front-end developer needing an understanding of those nuances.

In fact, at Acquia we're now in the early stages of building the first of several SDKs for consuming and manipulating data via Drupal 8's REST API. Hydrant, a new generic helper library intended for JavaScript developers building applications backed by Drupal, is the work of Acquia's Matt Grill and Preston So, and it is already seeing community contributions. We're eager to share our work more widely and welcome new contributors.

Conclusion

I believe that it is important to have first-class web services in Drupal out of the box in order to enable top-notch APIs and continue our evolution to become API-first.

In parallel with our ongoing work on shoring up our REST module in core, we should provide the underpinnings for even richer web services solutions in the future. With reusable helper functionality that operates on Drupal's entity graph available in core, we open the door to GraphQL, JSON API, and even our current core REST implementation eventually relying on the same robust foundation. Both GraphQL and JSON API could also be promising modules in core. Last but not least, SDKs like Hydrant that empower developers to work with Drupal without learning its complexities will further advance our web services.

Collectively, these tracks of work will make Drupal uniquely compelling for application developers within our own community and well beyond.

Special thanks to Preston So for contributions to this blog post and to Moshe Weitzman, Kyle Browning, Kris Vanderwater, Wim Leers, Sebastian Siemssen, Tim Millwood, Ted Bowman, and Mateu Aguiló Bosch for their feedback during its writing.

Catégories: Elsewhere

KnackForge: Review of Drupal professional themes

lun, 06/06/2016 - 07:34
Review of Drupal professional themes

DropThemes.in is one among the best Drupal professional theme selling sites. With decades of free theme and quality of paid themes, DropThemes.in has got its own place in the list professional theme selling sites. All our themes are Responsive and catered specifically for Drupal sites. A good theme gives your website a distinct feel that sends out a positive impression to your visitors. In this post, we would like to review the top themes on DropThemes.in to help you select the best.

Vamsi Mon, 06/06/2016 - 11:04
Catégories: Elsewhere

Jeff Geerling's Blog: Speeding up Composer-based Drupal installation

lun, 06/06/2016 - 05:07

Drupal VM is one of the most flexible and powerful local development environments for Drupal, but one the main goals of the project is to build a fully-functional Drupal 8 site quickly and easily without doing much setup work. The ideal would be to install Vagrant, clone or download the project, then run vagrant up. A few minutes later, you'd have a Drupal 8 site ready for hacking on!

In the past, you always had to do a couple extra steps in between, configuring a drupal.make.yml file and a config.yml file. Recently, thanks in huge part to Oskar Schöldström's herculean efforts, we achieved that ideal by switching from defaulting to a Drush make-based workflow to a Composer-based workflow (this will come in the 3.1.0 release, very soon!). But it wasn't without trial and tribulation!

Catégories: Elsewhere

Pages