With the advent of web services in Drupal 8 core, decoupling Drupal — namely, using Drupal as a content repository to expose data for retrieval and manipulation by other applications — has never been easier. Now, with the REST module in core, you can transform Drupal into a data service without custom code or substantial configuration. But is it a good idea? What are some of the considerations you should scrutinize when opting for a fully decoupled project?Tags: acquia drupal planet
Earlier this year I set about creating a day of training for DrupalCamp London. It was based on a PHP Framework course I’d given, but reduced to fit into a day. We ended up focusing on Modern PHP, as that was most useful for the attendees in their transition from Drupal 7 to Drupal 8.
It was a really successful day, and I had some great feedback. I have since developed the idea into a two day training course, which looks at some of the core concepts behind most modern PHP apps.
Over the past couple of months I have worked hard to refine the content and edit it down into a short guide. I’ve released it (thanks to Leanpub) in the form of a book. It guides the reader through a weekend-long project to construct a simple PHP web framework.
“a weekend, the fundamental unit of coding self-improvement” - Peter Shirley
In particular, it uses Symfony Components, and some other popular PHP packages, to demonstrate the core features of web frameworks, like routing, templating, controllers, and dependency injection. Projects such as Drupal, phpBB, Laravel, eZ Publish, Joomla!, Magento, Piwik, and many more are using Symfony Components as a foundation on which to build. The book uses these, and more, to build our own PHP Framework in a weekend.
Here’s the full contents:
- Getting Started
- Managing Complexity
- Dependency Injection
- Design and Layout
Click the cover image below to get the book:
Drop me a line if you have any questions.
Second part in a series of how to use XHProf effectively within a VM for a Drupal website. Continue reading…
There are so many amazing companies in the Drupal universe contributing their time and resources to the community and project right now. They’re taking the initiative to encourage their employees to contribute code. They’re sharing what they've learned while trying to provide clients with superior digital experiences. They’re donating their time to provide educational content to the community. And they’re doing a lot of it through their own internal operations.
Some of these businesses are also members of our Supporter Programs, which fund Drupal.org’s maintenance and improvements. And for that, we can’t thank them enough.
"Supporting Partners help us make Drupal.org a better home for our community. Their financial support is directly responsible for DrupalCI, the Issue Credits system, and all the other initiatives we've undertaken as a team. Take the Drupal 8 landing page as one example. Funding from Supporting Partners let us promote the release of Drupal 8 with a level of professionalism and finesse that no Drupal release has had before. Work like that builds a stronger ecosystem for our Supporters and for the wider community." - Tim Lehnen (hestenet), Drupal Association Project Manager
In this quarter alone, with financial support from the Supporting Partners, the Drupal.org tech team has been able to:
- Launch the Alpha of their Composer façade
- Update the Git Twisted daemon, which serves as the backend for the Drupal.org Git repositories and packaging process
- Launch a new staging environment that more closely matches the production environment, optimizing the development workflow
- Improve performance of the DrupalCon Events website
- Deploy CKEditor to Drupal.org's Section, Page, and Post content types, which brings a more impressive editorial experience to Drupal.org
All of this happened while ensuring DrupalCI ran smoothly for DrupalCon New Orleans sprints, successfully launching registration for DrupalCon Dublin (get your tickets now!), and launching the DrupalCon Baltimore splash page. Needless to say, the Drupal.org team has been busy, and it wouldn’t have been possible without our Supporting Partners financial contributions.
Check out our recent Drupal.org update for more details on exactly what the team was able to accomplish this past quarter. And to see where the team is headed next, take a look at the Drupal.org team's working roadmap.
As a testament to the relentless support these companies continue to show, here’s a list of new or renewing partners just this quarter:
- EPAM Systems
- Aten Design Group
- Phase2 Technology
- Digital Circus
- HS2 Solutions
- Cybage Software, Inc.
- The Cherry Hill Company
- Cheeky Monkey Media
- Message Agency
- Adapt A/S
- Unleashed Technologies, LLC
- Promet Source
- Digital Echidna
- ThinkShout Inc.
- Amazee Labs
- ImageX Media
- Four Kitchens
- Evolving Web
- Acro Media Inc
- Facet Interactive
- Last Call Media
- QED42 Engineering Pvt Ltd.
If you want to give back to the Project and help fund this important work, please contact our Executive Director, Megan Sanicki, for details. Your participation will be much appreciated and your company will also be able to enjoy great benefits in return!
Each day, between migrations and new projects, more and more features are becoming available for Drupal 8, the Drupal community's latest major release. In this series, the Acquia Developer Center is profiling some prominent, useful, and interesting projects--modules, themes, distros, and more--available for Drupal 8. This week: Rules.Tags: acquia drupal planetRulesworkflowintegration
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 Views to fix an Access Bypass vulnerability.
An access bypass vulnerability exists in the Views module, where users without the "View content count" permission can see the number of hits collected by the Statistics module for results in the view.
This issue is mitigated by the fact that the view must be configured to show a "Content statistics" field, such as "Total views", "Views today" or "Last visit".
If you have a Drupal 6 site using the Views module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)
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).
Drupal 8.1.3 and 7.44, maintenance releases which contain fixes for security vulnerabilities, are now available for download.Download Drupal 8.1.3 Download Drupal 7.44
Upgrading your existing Drupal 8 and 7 sites is strongly recommended. There are no new features or non-security-related bug fixes in these releases. For more information about the Drupal 8.1.x release series, consult the Drupal 8 overview. More information on the Drupal 7.x release series can be found in the Drupal 7.0 release announcement.Security vulnerabilities
Drupal 8.1.3 and 7.44 were released in response to the discovery of security vulnerabilities. Details can be found in the official security advisory:
To fix the security vulnerabilities, please upgrade to either Drupal 8.1.3 or Drupal 7.44.Change log
We have a security announcement mailing list and a history of all security advisories, as well as an RSS feed with the most recent security advisories. We strongly advise Drupal administrators to sign up for the list.
Drupal 8 and 7 include the built-in Update Manager module, which informs you about important updates to your modules and themes.Bug reports
Adding media (for most people that means adding images) in Drupal has been an issue for a long time. Adding reusable media (upload an image once, use it on any page on your website) has been even trickier.
With the advent of Drupal 8 and the sterling work done by the media team, adding reusable media (in a very user friendly manner) is now a reality. This tutorial shows you how:
Leveraging a common Drupal codebase to power multiple Drupal sites provides compelling benefits, including faster site launches, reduced maintenance overhead, and centralized security updating.
However, in order to be successful and avoid typical traps, the use of a common Drupal codebase requires some extra design care and strategy.Tags: acquia drupal planet
E-commerce sites are more and more commonly offering live chat for their visitors as a way of customer support. There is a wide selection of modules for Drupal that can add this functionality. However, most, if not all, I found rely on third party chat services. A while ago, I decided to build a native live chat module in connection with a project of mine. The module has been released as Customer chat.
At Mediacurrent, we take website security very seriously. Drupal has some security best practices baked into its APIs that let developers create their own modules, hopefully with secure code, to contribute back to the community. You contribute back, don’t you?
Drupal web development has many benefits.
Discover why Drupal is cool for university websites,
and see a nice website example by InternetDevels.
Whilst working on a Drupal 8 project, we found that cache tags for a Block Content entity embedded in the footer weren't bubbling up to the page cache.
Read on to find out how we debugged this and how you can ensure this doesn't happen to you to.
Jonathan provides a list of 10 things that he feels every Jr. Drupal Web Developer needs to knowRead more...
So, we've all heard of the word DevOps, we've all heard of the word FullStack developer. But what are you really? You might question yourselves every day whether or not you are working in one of those roles. Or do you prefer to call yourselves just an engineer?
This article is part of the Google Summer of Code blog series.
As mentioned in the previous blog post, the Mailhandler prototype for Drupal 8 has been finished. The prototype has already one of the main features implemented - processing mail messages and creating nodes. However, processed messages could be created by anyone which is not really nice for a module aiming to be used in production. To solve this problem, I've been working on user authentication implementation for almost a week.
The goal was to authenticate a user (sender of an email) before doing any mail processing. The meta issue with its child issues formalizes the requirements.
An obvious way to identify a mail sender is by checking the From field from the mail header. As this field is required to be present in mail headers (RFC 2822) we can assume we will always be able to identify the sender's mail address.
While writing a blog post about building a prototype, I acquainted you with Inmail. This is the module we are going to rely on to process mail messages. Inmail has a nice concept of plugins separated into deliverers, analyzers, and handlers. Deliverers are used to specify where a mail is coming from, analyzers to identify different types of messages and handlers to do some actions with mail messages and analyzer results. Last week, I already added a handler plugin and here I am going to talk about analyzers.
I started implementing an Inmail analyzer plugin and named it MailhandlerAnalyzer. It inherits AnalyzerBase from Inmail and currently has only one method - analyze() which accepts $message (represents a mail message entity) and processor_result (collects outcomes of a single mail processing pass) parameters. To preserve analyzer results, MailhandlerAnalyzerResult is created with $sender, $user and $body properties. The $sender will represent a sender's mail address (obtained from From mail header field), $user is a user entity in the current system and the $body is analyzed message body. After populating those fields in the analyzer, the job of MailhandlerNode is to authenticate and authorize the sender. If the conditions are met (user is validated) the handler will process the message and do the actions (create a node). This gives us a basic level of security.
However, From mail handler field can be faked by a malicious user. To bridge this obstacle, we introduced support for digitally signed emails. By its definition: digital signature is a mathematical scheme for demonstrating the authenticity of digital documents and it provides:
- Authentication - since the secret (private) key is bound to a specific user, successful signature verification will show the identity of the sender
- Integrity - it guarantees the message was not changed during transmission. Any change of the message content after signing it invalidates the signature
- Non-repudiation - a user can not deny sending and signing the message
Handling digital signature is not supported in PHP by default and we had to find the tools to do it. We decided to use GnuPG implementation of the OpenPGP (Pretty Good Privacy) standard defined by RFC 4880 and gnupg PHP extension. If you are not familiar with the concept of digital signature I would recommend you looking into this ~2 minutes read.
As a starting point, we have to add mailhandler_gpg_key field to store GPG Key for each user. I wanted to preserve public_key and fingerprint properties for each key and decided to go with custom field type. Drupal.org documentation provides a nice explanation how to create a custom field type, corresponding widgets and formatters in Drupal 8.Mailhandler GPG Key field
The next thing in our PGP journey is to extend analyzer and handlers to deal with signed messages. Usually, when handling emails, you will have to deal with regular expressions a lot. This case is not an exception. A new method called isSigned() is added to MailhandlerAnalyzer which analyzes the message and returns a boolean value. While we are dealing with messages at the low level, isSigned() populates the context data in case of signed messages. Context consists of:
- PGP Type - the signed message could be inline-signed (clear-text signature) or as nowadays standard PGP/MIME.
- Signed text - extracted the actual body without PGP signature
- Signature - PGP signature
Populating the general result properties of the analyzer result instance (In case of signed messages MailhandlerAnalyzerResultSigned), the analyzer finishes its job. At this point, we can analyze the signed message and be sure if we are dealing with signed or unsigned mail messages.
Next, we have to adapt our handler to support signed messages too. That looks easy, as all the hard work is completed by the analyzer. The only thing we have to do is to verify the signature. We do that by getting the signed text and signature from the analyzer result and pass them to gnupg_verify() function. If the signature is valid and the corresponding user's GPG key is not disabled, revoked or expired we will continue the handling process. One last step to check before creating a node is to assert the user is authorized for that action.
To summarize, implementing support for digitally signed emails certainly provides an acceptable level of security for Mailhandler module. Keep in mind, that you will need to have GnuPG PHP extension enabled on your server to get GPG support. In either way, you will benefit from Mailhandler's default authentication system. The interesting thing about last week is that authentication support produced more than 1,2k new lines of code in the Github pull request.
Next week, I am going to work on footer detection in a mail message. This will allow us to remove any unnecessary and unintended content from a node body. To support all those features, most of the work will be done in the analyzer. The mid-term evaluation period starts in less than a week which means the next week will be used to do preparation for it as well.
Over and out.
Milos Tue, 06/14/2016 - 22:00 Tags Google Summer of Code Drupal Open source Drupal Planet Add new comment
Rick Manelius Tue, 06/14/2016 - 13:18
One of the main driving forces for writing the community supported Drupal PCI Compliance White Paper was to help developers and merchants to make smart choices that balance functionality with security. At the time, there were dozens of payment gateway modules available and knowing what risks were involved with each was no easy task. Ultimately, many of them posed a significant risk to the merchant because they were requiring Drupal to temporarily store and transmit card data.
For those wishing to better understand these nuances, I highly recommend reading the white paper because you need to be able to defend your choices, especially if you’re trying to pass an audit or have to deal with the fallout of a data breach. That said, if I do nothing else but help you pick a sane default, I’ll rest better at night.My (Current) Recommendations
Historically, Hosted Payment Pages (HPPs) were the preferred solution because they fully offload the entry of the card to a service like Paypal, Authorize.net SIM, or Recurly. This greatly reduces the number of potential attack vectors (thereby increasing security) and is the easiest way to get to a PCI SAQ A status (thereby reducing your costs to obtain and maintain compliance). From a security perspective, HPP are always a good choice. The challenge has always been to convince clients to opt for this because they lose control of the customer experience when customers are redirected to an external site.
Fortunately, for those who want the best of both worlds, there is the inline iframe option. The beauty here is that the customer is kept on the website the entire time and (usually) unaware that the credit card entry is being submitted through the form within the iframe loaded directly from the payment gateway itself. Unfortunately, throughout much of 2014 and 2015, only one module provided this option (Hosted PCI). While I originally recommended this option, the setup and ongoing fees were prohibitive and it generally took several days to get an account provisioned.
Since that time, two major players have created inline options: Commerce Braintree and Commerce Stripe. I highly recommend these two modules because they have extended the checkout inference in a straightforward way and allow users to get either one installed and configured in less than an hour. The only caveat for the Stripe module is site-builders MUST remember to enable the correct rule (the module provides two). If you enable the direct post rule, it still will fall within SAQ A-EP because direct post solutions can be attacked by on-page keyloggers. It’s a subtle but important detail.
Finally, remember that these recommendations are current as of the publishing of this article on June 14, 2016. The PCI-DSS standard will continue to evolve as will the payment gateways that are trying to provide the best solutions for their customers. Still, if you’re looking for two solid solutions to start using immediately, you’ll get a lot of mileage out of the Stripe and Braintree modules.
Drupal 8’s improvements to contact form management and creation is one of my favorite site building upgrades that has been added to Drupal 8’s core.
We now have the ability to field contact forms in the same familiar way as many other entities and can have multiple form variations living at different urls on the same site.
Let me first give a brief summary about the current status of the module Google Vision. In the earlier weeks, I had implemented the services and wrote tests for the module, which are now committed to the module.Now, coming to the progress of this week.Initially, I implemented the Safe Search detection as a function which worked in the same way as the Label detection.However, my mentors suggested that this feature should rather be a Constraint on the image fields, which would be validated if the feature is enabled for the field. It depends on the user whether to keep safe search on their site or not, and they can implement it any time they want by just enabling/disabling the configuration of the image field. Hence, now it is a user choice, rather than the developer’s choice whether to implement this feature or not.Presently, the code is under review by my mentors whether it needs changes or is ready for commit.Constraints and Validators are wonderful features of Drupal 8. Constraints, as the name goes, are certain restrictions which we pose on the various fields. Validators are used to implement the logic to create the situation under which the constraints are to be applied.This week had a lot of new things stored for me. I had no idea about the constraints and validators when I was asked to implement them at the first place. I spent hours on them, learning about them and seeking guidance from my mentors on the issues I faced. I developed gradually on it, and by the end of the week, I was able to implement them for the safe search detection feature.