All RPGs and Storygames by Tod Foley are now available at DrivethruRPG and RPGnow. Bring these games to your table!
Over the weekend, several of us in the tech chapter at Deeson attended DrupalCamp London 2018. It’s always a great event, and one our own Tim Deeson helped co-found in 2013.
For me, returning to DrupalCamp was a chance to immerse myself in the community again, to catch up with some old friends, and put faces to people I’d only met on Twitter.
The Deeson developers attending the event had different levels of Drupal knowledge, so we didn’t stick together the entire time. Due to my relatively limited knowledge of Drupal 8 I attended two very informative, low level development talks about the internal workings of D8 and how the approach differs to that I already know well with D7.
The first was Drupal 8 Services and Dependency Injection, an introduction to creating custom services to use within your own modules. I also attended Let’s take the best route - Exploring Drupal 8 Routing System, which showed me that while the change to Symfony makes the code very different, it’s actually straightforward and consistent once you get into it.
A particular highlight was seeing our Lead Developer Mike Davis in action. He spoke about Warden – an open source solution Deeson built to allow in-house development teams and agencies to keep track of the status of multiple Drupal sites hosted on different platforms.
Here are a few of our other favourite sessions and highlights from the event…“Hello User, I’m Drupal!”
We’ve been speaking about conversational interfaces and chatbots for a while at Deeson, and it was really interesting to learn about the tools available for Drupal site builders. With Alexa and Dialogflow support out of the box, Chatbot API module is one to keep an eye on.
Katy Ereira, Senior DeveloperDrupal in the era of Microservices.
I attended a talk by Wunder's CTO Florian Lorétan, where he discussed the ideas around using Drupal with Microservices. This is an interesting idea particularly where larger projects are concerned as it opens up the potential for large teams to collaborate more effectively.
We currently use Docker as part of our own build process (which could be considered a microservice) and I wanted to see how this could be extended further and what other benefits could be yielded as a result.
It was very interesting to learn that automated tests, benchmarking, security testing and monitoring could all be done as mircroservices with Drupal and how the speed of deployment could be rapidly increased by using this approach.
Whilst this is relatively new, it's great to see people within the Drupal community exploring how microservices could be used with Drupal to speed up the development process, and I'm really looking forward to seeing what the future holds in this area.
Rowan Blackwood, DeveloperBuilding a contribution culture in a Drupal agency.
I've joined Deeson within the past year, and one of the key qualities that drew me to Deeson in the first place was its commitment to open source and support for contributing back to the community. So I was keen to hear a little more about how other companies foster their own contributions culture and have the opportunity to compare our own culture with another.
In his session @hussainweb reiterated the added value that you can create for yourself by making contributions to open source projects, and how his company has found ways to actively encourage individuals to make contributions.
What really stuck with me is the following three items:
- Open source contributions create Social Capital, and that's an investment you can recoup in other ways.
- Contributions are not just about actual code contributed - it's also about bug reporting, documentation, testing, speaking and writing, which are just as valuable efforts, and they should also be tracked, encouraged and rewarded.
- Don't be intimidated from extending open source projects. If you use it, treat it as your own upstream code and not a project that cannot be touched. Lose the fear of the project and contribute!
James Ford, Senior Developer
Every Drupal 8 site should have a custom favicon that helps to reinforce the site's brand - of this there is really no argument. But, over the past (more than a few) years, the role of the lowly favicon has grown from just the little icon on a browser tab. These days, favicons are also used on mobile devices as the gateway to your site. Keeping your brand strong in all contexts is more important than ever.
Assuming you have a relatively square-ish version of the site's logo, making this all happen is pretty easy.
First - head to Favicon Generator, upload the site's logo, then review/tweak the settings for the various contexts. You'll be asked for the "App name" (usually the site's name), suitable background colors (I selected a nice pear-color for the DrupalEasy logo - you can see it in the iOS mockup above), as well as image overrides (optional) for each context. For the "Favicon Generator options", select the "I will place favicon files at the root of my web site" option (at the recommendation of the Responsive Favicons module maintainers). At the end of the process, you'll get a zipped file full of all the necessary icons and meta data.
Next, download and install the Responsive Favicons module. Head to its configuration area (/admin/config/user-interface/responsive_favicons) and complete the form. For the "Path to responsive favicon files", I just used "favicons". The "Favicons tags" section is provided at the end of the Favicon Generator's process. Finally, point the zip file generated by the Favicon Generator to the final form field. Click to "Save configuration" and you should be all set!
Lessons like this (and much, much more) are taught during our 12-week, 3x/week Drupal Career Online course. Learn more and register for our free Taste of Drupal webinar to dive into the details of the course.
Drupal isn’t known as a particularly lightweight content management system and that is one of the reasons we love it, right? It is meant to handle large amounts of complex content. A problem occurs when you have a site that is just flush with content of different types, how do you get users to it? Navigation can only get you so far sometimes. We have personally seen this on everything from large-scale publishing sites to medical practice sites.
Drupal is a very popular open source Web Content Management system. One of its key characteristics is that it owns both the back-end repository where content is stored and the front-end where content is rendered. In CMS parlance this is typically called a “coupled” CMS because the front-end and the back-end are coupled together.
Historically, the coupled nature of Drupal was a benefit most of the time because it facilitated a fast time-to-market. In many cases, customers could just install Drupal, define their content types, install or develop a theme, and they had a web site up-and-running that made it easy for non-technical content editors to manage the content of that web site.
But as architectural styles have shifted to “API-first” and Single Page Applications (SPAs) written in client-side frameworks like Angular and React and with many clients finding themselves distributing content to multiple channels beyond web, having a CMS that wants to own the front-end becomes more of a burden than a benefit, hence the rise of the “headless” or “de-coupled” CMS. Multiple SaaS vendors have sprung up over the last few years, creating a Content-as-a-Service market which I’ve blogged about before.
Drupal has been able to expose its content and other operations via a RESTful API for quite a while. But in those early days it was not quite as simple as it could be. If you have a team, for example, that just wants to model some content types, give their editors a nice interface for managing instances of those types, and then write a front-end that fetches that content via JSON, you still had to know a fair amount about Drupal to get everything working.
Last summer, Acquia, a company that provides enterprise support for Drupal headed up by Drupal founder, Dries Buytaert, released a new distribution of Drupal called Reservoir that implements the “headless CMS” use case. Reservoir is Drupal, but most of the pieces that concern the front-end have been removed. Reservoir also ships with a JSON API module that exposes your content in a standard way.
I was curious to see how well this worked so I grabbed the Reservoir Docker image and fired it up.
The first thing I did was create a few content types. Article is a demo type provided out-of-the-box. I added Job Posting and Team Member, two types you’d find on just about any corporate web site.
My Team Member type is simple. It has a Body field, which is HTML text, and a Headshot field, which is an image. My Job Posting type has a plain text Body field, a Date field for when the job was posted, and a Status field which has a constrained list of values (Open and Closed).
With my types in place I started creating content…
Something that jumped out at me here was that there is no way to search, filter, or sort content. That’s not going to work very well as the number of content items grows. I can hear my Drupal friends saying, “There’s a module for that!”, but that seems like something that should be out-of-the-box.
Next, I jumped over to the API tab and saw that there are RESTful endpoints for each of my content types that allow me to fetch a list of nodes of a given type, specific nodes, and the relationships a node has to other nodes in the repository. POST, PATCH, and DELETE methods are also supported, so this is not just a read-only API.
Reservoir uses OAuth to secure the API, so to actually test it out, I grabbed the “Demo app” client UUID, then went into Postman and did a POST against the /oauth/token endpoint. That returned an access token and a refresh token. I grabbed the access token and stuck it in the authorization header for future requests.
Here’s an example response for a specific “team member” object.
My first observation is that the JSON is pretty verbose for such a simple object. If I were to use this today I’d probably write a Spring Boot app that simplifies the API responses further. As a front-end developer, I’d really prefer for the JSON that comes back to be much more succinct. The front-end may not need to know about the node’s revision history, for example.
Another reason I might want my front-end to call a simplified API layer rather than call Drupal directly is to aggregate multiple calls. For example, in the response above, you’ll notice that the team member’s headshot is returned as part of a relationship. You can’t get the URL to the headshot from the Team Member JSON.
If you follow the field_headshot “related” link, you’ll get the JSON object representing the headshot:
The related headshot JSON shown above has the actual URL to the headshot image. It’s not the end of the world to have to make two HTTP calls for every team member, but as a front-end developer, I’d prefer to get a team member object that has exactly what I need in a single response.
One of the things that might help improve this is support for GraphQL. Reservoir says it plans to support GraphQL, but in the version that ships on the Docker image, if you try to enable it, you get a message that it is still under development. There is a GraphQL Drupal module so I’m sure this is coming to Reservoir soon.
Many of my clients are predominantly Java shops–they are often reluctant to adopt technology that would require new additions to their toolchain, like PHP. And they don’t always have an interest in hiring or developing Drupal talent. Containers running highly-specialized Drupal distributions, like Reservoir, could eventually make both of these concerns less of an issue.
In addition to Acquia Reservoir, there is another de-coupled Drupal Distribution called Contenta, so if you like the idea of running headless Drupal, you might take a look at both and see which is a better fit.