All RPGs and Storygames by Tod Foley are now available at DrivethruRPG and RPGnow. Bring these games to your table!
The process of reordering the views can be done with the help of Drupal draggable views module. With the help of the module we can easily re-order the table format, but if we want to reorder the grid format, it requires some modification in the views that is created. In this blog I will be explaining about Drupal grid view which is the view that is visible for the user.
You can download and install the module using drush commands drush dl draggableviews -y and then drush en…
One of the nicest new features of Drupal 8 is its support of REST out of the box. With more and more websites moving to a decoupled approach, whether fully or partially, it has become essential for developers to understand how to build REST endpoints.
“By failing to prepare, you are preparing to fail.” Benjamin Franklin
This age-old advice from Benjamin Franklin is applicable in many situations but is a clear truth when you are upgrading or migrating your website to Drupal 8. The fact is: if you do not plan for SEO in your website transition, you will see a drop in Google rankings and traffic.
Volacci has over ten years of Drupal experience and has created meticulous, process-driven methods for SEO during website migrations or upgrades. We've detailed all of our steps to a successful transition in our new whitepaper: Key Steps to a Successful Drupal 8 SEO Website Migration or Upgrade. Download for free here.
We’ve seen it happen over and over again: prospective clients come to us, after completing a website... Read the full article: Drupal 8 Migration SEO Success: Start with a Plan
I had been getting by with shell scripts and SFTP to deploy Drupal sites until recently. After using Ansible for a few weeks, I realized how much I've been missing all these days. I share some of my notes on how to use Ansible to setup and deploy Drupal infrastructure in this post. Besides, this is also meant to be a full blown introduction to Ansible. A lot of tutorials don't cross the "hello world" realm and I wanted to go beyond that, hence an epic post!
There are some assumptions I'm holding about the reader and the setup, like:
If you're getting started with Drupal 8, there are some key features you'll need to master.
In this tutorial, I'll show you how to build your first Drupal 8 slideshow.
In the last post in this series, we learned how to implement a simple Blog listing with Drupal, GraphQL, Apollo and React. Now it’s time to take a deep breath and dive into the full list of features built into the GraphQL module to spark your imagination with its endless capabilities.Philipp Melab Thu, 08/10/2017 - 07:13 More than data
After being educated by more than a decade of thinking in terms of RESTfulness and pure data, the solution seems obvious. Drupal 8 has Typed Data and therefore we know everything about our data structure and can just automatically generate GraphQL types, fields and interfaces from it. Awesome, we’re done!
Well you only need the light when it's burning low
Only miss the sun when it starts to snow
Only know you love her when you let her go
I suspect that Michael David Rosenberg was trying to build a decoupled Drupal website, gave up and wrote this song instead. The moment you reduce Drupal to a pure object database you will learn what else it does for you. How did you plan to handle ...
- Output filtering and XSS protection
- Routing and Redirecting
- Arbitrary Listings
- Image processing
- Menus and Breadcrumbs
- The editable and context sensitive “Contact” block in the footer …?
And that’s just what ships with Core. Obviously, you can build that all into your frontend application, but that’s a lot of development time spent on implementing things that have already been tested and are there for you to use.
As stated in the first post in this series, GraphQL is an application level query language, which means data and operations are equally important. Actually, this brings it rather close to SOAP. This might send shivers down some spines, but stay with me - we learned from the lessons of the past and gained some valuable insights.
After experiencing some painful “Aha”-moments, we started to implement a GraphQL Schema that allows us to tap into very different levels and areas of Drupal’s feature-set instead of typed data alone. This growing collection of types and fields has been split up into submodules that can be enabled on demand. Let’s have a look at them, one by one.GraphQL Core
The base module all others depend on. It introduces a system of overridable plugins (Fields, Scalars, Types, Interfaces, Enumerations and Input Types) that are automatically assembled to form our GraphQL Schema. In addition to that, it includes plugins that expose some basic Drupal mechanisms: Routing, Context and Entities.
For every entity type, there is a corresponding query field that makes it possible to run property-filtered queries and will return a list of entity objects that contain the UUID. This might not seem very helpful, but more on this later.
More interesting, however, is the route field. It takes a path as an argument and returns an object of type Url which contains fields for every defined context in Drupal. This way it’s possible to pull the content language, current user or node for a given path. Any context provided by a contrib module will also be picked up automatically.GraphQL Content
As mentioned above, the entity objects returned by entity queries and contexts only contain the UUID, and are therefore not terribly useful. That’s where the second base module takes to the stage. In the last blog post, we already used it to configure a view mode and defined the fields that are exposed to the GraphQL API. Let’s have a closer look what happened there.
The module will pick up all enabled content entity types and bundles and transform them into corresponding GraphQL interfaces and types with fields for common entity properties. If a view mode has been assigned, the configured fields will be attached to the GraphQL type. The fields will return string values rendered according to their field formatter configuration. This means we keep input filters on our body field and all other field formatters that are out there as well.
The latter is what happens by default. It is, however, possible to define special field formatters that alter this behaviour and return custom GraphQL types. One example is the built-in "GraphQL Raw value" formatter, which returns Typed Data objects. By that, we successfully closed the circle and are able to get back to raw, unprocessed data values when necessary.
A bunch of modules in the repository do something similar to “GraphQL Raw value”, but with a different spin for the corresponding field type. Below is a brief rundown on each module’s purpose:GraphQL Boolean
Provides a GraphQL Boolean formatter that will make sure that the response value is an actual boolean and not a string. As simple as that.GraphQL File
Turns file fields into objects containing useful file information like mime type, file size and the absolute file URL for downloading it.GraphQL Image
One of the more important ones. Image fields will return types that contain “derivative” fields that allow us to pull information about specific image styles. This also makes it easily possible to grab multiple image styles at once.GraphQL Entity Reference
Instead of returning the rendered entity or the raw target_id value, this allows us to traverse the entity relation and query the related type. The result type will again expose fields based on it’s configured view mode for the entity type retrieved.GraphQL Link
Exposes the link field title, attributes and URL. So far so “raw value”. But there’s a catch! The URL field is not a simple string, but an object of type Url.
Remember, the one also returned by the route field with all defined contexts attached? It is possible to pull contextual information for any path inserted into a link field. But beware: this will issue a kernel sub-request, which will have a performance impact when overdoing it. Not sayin’ it’s a good idea, just sayin’ it’s there.GraphQL Content mutation
Adds GraphQL mutations for all content entities, which means it enables you to write any content data out of the box -provided the user has required permissions since this and all other entity features will respect entity access.GraphQL Block
This module adds a blocksByRegion field to Url objects, which will retrieve block entities displayed in this region. Access conditions will be evaluated against the Url object’s path and the default theme. Until configuration entities are fully supported, this field has limited use on its own.
However, when used in combination with “GraphQL Content”, returned Content Blocks contain the configured fields just as nodes do. This way we maintain the ability to inject blocks of meta-information that are configurable from the Drupal backend and even respect any visibility settings and contexts.GraphQL Menu
This module provides us with a root level field for querying menu trees. The structure returned will respect access permissions but it does not mark active states. This is done in the client implementation when necessary so we don’t have to re-fetch the whole menu tree on every location update.GraphQL Breadcrumbs
Retrieve a list of breadcrumb links from any URL object.GraphQL Views
Last but not least, there is the views integration. One of the most versatile tools in Drupal is also a must have in your decoupled application. We already used it in the last instalment of this series to create the listing of posts, so we can skip boring examples and get to the juicy theory right away!
Any “GraphQL” views display will provide a field that will adapt to the views configuration:
- The fields name will be composed of the views and displays machine names or configured manually.
- If the view is configured with pagination, the field will accept pager arguments and return the result list and count field instead of the entity list directly.
- Any exposed filters will be added to the “filters” input type that can be used to pass filter values into the view.
- Any contextual filters will be added to the “contextual_filters” input type.
- If a contextual filters validation criteria match an existing GraphQL type, the field will be added to this type too, and the value will be populated from the current result context.
TL;DR: We are able to create a view that takes a node as context argument and the field will be added to all GraphQL node objects.
That’s a wrap! We covered all features that help you to build an automated schema included in the GraphQL module at the time of writing. There a lot going on and the community is working hard to implement improvements like:
- Support for views field displays.
- Partial query caching.
- A dedicated user interface for graph configuration.
- Mutations based on actions and rules.
- Performance optimization with deferred resolving and lookaheads.
In the next blog post we will take a look at the underlying API and show how you can use it to extend the schema with custom functionality and - even more important - contribute and help to make these features come alive!
Last week, I published a super long article called Drupal 8 has left small non-profits behind... How can we fix that? which details the many issues Drupal 8 is having and their chilling affect on usage among nonprofit organizations.
It also proposes a possible path for fixing it: building an Open Source platform for nonprofit websites built on Drupal 8 and CiviCRM, available as a SaaS with hosting and support included.
We're looking for 10 nonprofits who are willing to participate in the BETA and help build it (in exchange for a FREE migration to Drupal 8 & CiviCRM).
Next week, we're planning to talk more details about how that BETA process will work!
However, this week, I wanted to take a little break from that, and talk more about CiviCRM in Drupal 8.
So, in this article, we're goning to:
- Walk through how to install CiviCRM on Drupal 8. It's quite complicated now, but we're helping to improve that.
- Talk about why we're betting on CiviCRM and not a CRM built in Drupal. There's a couple of great, pure Drupal solutions to CRM, like RedHen or CRM Core - but we've chosen to go with CiviCRM. Why?
Read more to find out!
The task at hand here is to allow the client to create a classed wrapper around multiple elements using CKEditor in Drupal 8.
The fundamental problem here is the CKEditor's built in "Styles" dropdown classes each <p> individually, while we need a class wrapping them.
You could probably make or install your own CKEditor plugin, but that's not what I did.
As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!
Today, there is a Moderately Critical security release for the Facebook Like Button module to fix an Cross Site Scripting (XSS) vulnerability.
The module provides a Facebook Like button on node pages and blocks.
The module doesn't sufficiently sanitize certain configuration fields.
See the security advisory for Drupal 7 for more information.
Here you can download the Drupal 6 patch.
If you have a Drupal 6 site using the Facebook Like Button module, we recommend you update immediately.
If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.
Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).
This blog post summarises the tenth week of writing open-source code for Drupal with Google Summer of Code.JS DOM manipulating for listing encrypted files
The REST API that I had set up last week was leveraged to append the list of the files that are associated with a node for making the files available for decryption and downloading.Tags GSoC Google Summer of Code 2017 Drupal Drupal Blog
Last week, FFW was proud to attend and sponsor Drupal GovCon, a Drupal Camp dedicated to serving Drupal users in the government sector and hosted in the greater Washington, DC area. The event consisted of three days of great conversations, sessions, and sprints in the FFW Sponsored Sprint Lounge. We’d also like to congratulate the GovCon organizers on this year’s amazing event, which had more attendees and excitement than ever before.A chance to reconnect
One of the things we noticed at GovCon was the amazing enthusiasm about the Drupal project, and especially Drupal 8. We got to be part of a lot of great conversations about Drupal 8, and appreciated the chance to reconnect with colleagues who are interested in Drupal and its capabilities. One of our teammates, David Hernandez, had an especially great session about Docksal and VMs, and had a lot of great conversations later about the subject matter.
For us, the chance to meet up with our friends and colleagues is the most important part of attending camps. Being able to take the time to have in-depth conversations with other people and organizations who are using Drupal in new and challenging ways is incredibly valuable to us, and is a great way of understanding the problems and challenges that others in our industry are facing on a day-to-day basis.Open source and government sites
In our work with governments and other big organizations with strict governance rules, we’ve found that open source software is an ideal choice. In addition to being far more secure than closed-source alternatives, software like Drupal simplifies the process of managing permissions and creating content that can be read by anyone, anywhere, on any device.
Additionally, the flexibility of open-source solutions makes it easier to integrate digital platforms with a variety of systems so that simple transactions can be automated. For example, see how several Danish municipalities built solutions that could better serve their constituents with help from FFW.
Ultimately, we know that open source is a great solution for governments, and we had a wonderful time connecting with other like-minded people at GovCon last week. We were glad for the chance to sponsor such a great event, and look forward to connecting to more Drupalers in the government sector in the future.
The annual meeting of Drupal enthusiasts in Norway (and elsewhere) will take place on the 11th of November, with community sprints happening November 12th.
Every year, the camp attracts visitors from Drupal professionals and hobbyists from Norway, but also from the surrounding countries. If you want to meet Drupal entusiasts from our region, this is a great chance to do so.
We also want to invite people who wants to speak to submit their session proposals to our website. Whether you are a seasoned conference speaker or if you want to have your first session, you are very welcome to submit your talk to Drupal Camp Oslo.
If you prefer to attend, we are just as welcome to you as well! Tickets are now available for purchase, and at the moment they are extra early-bird cheap! We also have different price tiers if you attend as a hobbyist or student, and we hope for a diverse audience of attendees, both in the sessions and in the sprints on Sunday!
See you in Oslo in November!
One of the most common hurdles that Drupal beginners face is learning to navigate the modules area on Drupal.org.
We often hear questions like this:"There are over 38,000 modules! How we do know which ones to use?"
The answer is often to use a distribution.
Building your own e-commerce, intranet or a social networking site in Drupal can be intimidating. Imagine how much easier it would be if an expert had found all the best modules for your purpose and had combined them into one package. Imagine that you could download and install that package as easily as a normal copy of Drupal. That's what distributions can do for you.
Appnovation Technologies: How I Stepped My Way Through a Failing Drush Drupal 8 Migration With PHPStorm’s Xdebug Integration: Part 2...
Continued from Setting the Stage: Hosting a Decoupled Drupal Site...
With numerous ski resorts, several Camp Woodward destinations around the country, and roughly 50 unique events hosted each year, the content demands of POWDR’s portfolio are significant. Managing the volume and variety of this content is a challenge in itself - and managing it across disparate systems with different processes and siloed data makes it much harder. With that in mind, POWDR set out to unify the technology driving their digital presence using a new platform powered by Drupal 8.The Requirements
The platform needed to serve two seemingly different goals: flexibility allowing for different designs on the frontend and a uniform data model on the backend for maintaining content. To meet these needs, POWDR opted for a decoupled approach, using the backend system as a data API that’s consumed by individual frontends that can be styled however necessary, and at times, completely differently.The Responsibilities
With our partners Hoorooh Digitial and Acquia providing the frontend and hosting solutions respectively, our job at Elevated Third was to design and build the data layer at the platform’s center. As Drupal experts, we knew Drupal 8 had the right tools for this job. Our solution used a combination of Drupal 8’s REST API, Views, the Paragraphs module, and some custom modules to provide the right amount of flexibility and maintainability for POWDR’s needs.An Initial Architectural Consideration
When building a solution like this, the first decision will revolve around structuring the technology powering it. Currently, there are a couple architectural options in the decoupled application landscape.
The first option consists of running two servers: one for the frontend application(s) and one for the backend data API. In this scenario, the frontends are responsible for all the routing and the backend simply provides a JSON endpoint that communicates with the frontends.
The second option consists of storing the frontend applications as compiled assets on the same server as the backend. In this scenario, the backend will respond to initial incoming requests and route them to the proper frontend application which takes over from there.
There’s not a right or a wrong choice here. And any decision will depend on the combination of hosting options, technical expertise, and development team’s appetite for complexity. We chose the second option. And after some fiddling with HTTP requests and Apache proxying, the POWDR platform has been performing excellently.To Be Continued...
In the next entry of this blog series, my project partner Joe Flores will detail some of specific Drupal technologies and techniques we used to power POWDR.
Thanks for reading!
The project was for Powdr Resorts, one of the largest ski operators in North America.
The first installment was A Deep Dive into a Decoupled Drupal 8 Project.Tags: acquia drupal planet
Oh! Hey there, my name is Piyush Jain and as a new staff member at the Drupal Association I wanted to learn what the community likes so much about DrupalCon.
This week, I spoke with Eduardo Garcia (-enzo-), a Drupal Console core maintainer. Eduardo has been part of the Drupal community for 9.5 years, and has attended 6 DrupalCons.