All RPGs and Storygames by Tod Foley are now available at DrivethruRPG and RPGnow. Bring these games to your table!
A module to create customizable messages that can be sent by email or other methods.
There is now an easier way to install Drupal Commerce! And the best part is that you don't have to do any type of crazy spinup. It does involve a little bit of pseudo-programming, but if you know your way around a command line, you should be OK.A Bit of Background
There's a Commerce Kickstart that exists for Drupal 7. It's Drupal Commerce and all the standard add-ons put together into a mock store. It shows you the power of Commerce and provides a bunch of examples. That can be helpful because Drupal is so modular and can be a bit daunting at first. You install just Commerce, but then if you want, say, gift cards, that's a separate module you need to add. There are all these little bits and pieces you have to get, and not all of them have intuitive names, and it can be very confusing. Commerce Kickstart was meant to solve that problem. Which it did, to some extent.
But the Drupal 7 Commerce Kickstart tried to be both a demo and a base for you to build from. It was primarily a demo, but lots of people used it as a base. The problem was that the demo was already so customized that many people ran into issues because they needed to delete or remove different things instead of starting from a clean setup.A Better Way for Drupal 8
For Drupal 8, we decided to build two separate things: a demo, and a kickstart that would truly assist developers in getting started. It covers Drupal Commerce and all the normal add-ons you would typically add. With the original Commerce Kickstart, you got all the add-ons as a complete package, and you would have to remove whatever you didn't want. For Drupal 8, Commerce Kickstart is an actual builder.
And it's easy to use. You select a region, for instance. If you say that you're based in North America and only ship there, you're not going to see the options for integrating with the Royal Mail, because that's irrelevant to you. Then you go through the different sections. What do you need for payments? For shipping? You select all the options you want, and Commerce Kickstart uses Composer to build an install file for you.Why Is This Cool?
For one thing, it saves you time. For another, it's a great introduction for people who aren't familiar with the Commerce ecosystem. That latter point is key, as that was the biggest hurdle Commerce Kickstart was trying to overcome. If you're new to Commerce and you don't know about all the add-on options, you might install Drupal Commerce and just get stuck. This gets you much farther in the process.Demo Content On the Way
You will eventually be able to choose whether you want a clean install, or whether you want to use demo content. With example content, you could see what a nicely configured product looked like, for instance. Or see a sample tax item, or a sample shipping method. This could be great for people who aren't super technical or who just aren't familiar with Drupal Commerce conventions.
This functionality isn't out there yet, but it is coming down the pipe soon. You can see the status of the Demo Content module here.
We also have pre-set-up migrations. So it's becoming easy to migrate from an Ubercart site or a Commerce site on Drupal 7. Options for Magento and Shopify are also coming.The Bottom Line
If you're building a Drupal Commerce website, use Commerce Kickstart 2.x Installer. It's the best ad easiest way to get Drupal Commerce installed with everything you need.
- High Five video: Introducting the Urban Hipster (UH) Demo for Drupal Commerce
- Try out the Drupal Commerce Demo Site
- Learn more about Drupal Commerce
- Learn more about Acro Media
Chat with us
If you'd like a personalized tour to discuss how Drupal Commerce fits into your ecommerce solution, give us a shout. We're happy to show and tell.
Acquia Developer Center Blog: Decoupling Drupal 8 Core: Web Services in Core and the Serialization Module
If you have decided to decouple Drupal, after conducting due diligence with regard to assessing the risks and rewards of decoupling Drupal and understanding how best to decouple Drupal in 2018, it is essential to understand how web services in Drupal 8 core and their dependencies undergird all decoupled Drupal architectures, regardless of the application you are implementing.Tags: acquia drupal planet
Yesterday was Father's Day in Belgium. As a gift, Stan drew me this picture. In addition to the thoughtful gesture, I love learning more about the way our kids see us. For me, it's special that Stan understands two important communities in my life.
Over the past year or so, I've been looking to replace my standard local development environment with a Docker-based solution. I've been evaluating DDEV, Docksal, and Lando (listed alphabetically), trying to figure out not only was the best for me, but also the best for me to teach and recommend to the hundreds of folks I teach both long-form and full-day Drupal workshops to each year. As I've test-driven each of these three options, I've been periodically posting tutorials on various related topics.
As a long-time Mac OS X user, my previous go-to local development stack has been a mix of MAMP Pro and Acquia Dev Desktop. For teaching, I've mainly been recommending Acquia Dev Desktop, but I think the time has come for a more flexible and professional-level solution. The ability to customize each project's development environment with various versions of PHP, different database and search index servers (adding a Solr server to any of the options in this article is just plain easy), and other things is too big of an opportunity to let pass.
My evaluation of DDEV, Docksal, and Lando has not be quick. I've been using Docksal for several client projects for well over a year now. In fact, during the initial Mastering Professional Drupal Development Workflows with Pantheon course, I recommended it to all of our students. I've even written and shared a somewhat Pantheon-flavored version of a Docksal configuration. It includes custom scripts for automatically downloading and importing a copy of a remote Pantheon database to the local environment as well as running some initial Drush commands after the import is complete.
As the Lando project matured, I was attracted to it mainly for its recipe-based configuration, including a Pantheon-flavored recipe that outdid my custom Docksal scripts. Currently, I'm using Lando for about 5 different client projects (as well as my local development environment for DrupalEasy.com).
Finally, a few months ago, I saw down with a few folks from the DDEV project at BADCamp for an extended walkthrough. It took me another month or two before I really dove into it, using it for a new client project, but at this point (spoiler alert), I'm leaning towards it being my go-to local development environment for teaching.Comparison
What follows below is just a summary of the various features that I've focused on while test-driving each option. By no means it is a comprehensive list of features, but I think it is safe to say that these are what are most important in my use cases. As I mentioned above, my needs are twofold: a solid local development environment for client work, and an easy-to-install-and-configure local development environment for my students on both Windows and Mac OS X. I imagine that most folks don't have the latter requirement, so be sure to select the best environment for your needs.
In no particular order, here's what I focused on:User interface
All three options are only command-line driven at this point; none have a graphical user interface (yet). All three options provide a command-line tool with different (but similar) commands. For example:
To start a project's containers: lando start, fin start, ddev start ("fin" is Docksal's command-line tool)
To stop a project's containers: lando stop, fin stop, ddev stop
As Lando evolved from Kalabox, there is talk that a GUI may be part of a paid add-on in the future. The DDEV team has also made it known that a GUI is in currently being developed.Hard drive space
As all three options are Docker-based; each project on your local has its own set of containers. I've found that for a typical project, these containers require (I think) around 500(ish)MB of hard drive space (not including your project's data). Obviously, this can add up quickly depending on the number of projects you have on your local. I've found that DDEV has an advantage in this area, as it stores your project's data (database, files directory) in a directory shared with the host operating system - so you can remove a project's containers without losing your site's data (database) - thus saving hard drive space. For someone like me who creates a lot of sites (for teaching), this is non-trivial. DDEV's "ddev remove" command that removes only the containers. If you want to remove a project's data as well, "ddev remove --remove-data" does the trick. Both Lando and Docksal have commands to remove a project's containers and data as well, but neither (currently) has an option to preserve data.
As someone who had zero knowledge/experience with Docker at the beginning of this process, estimating how much hard drive space this stuff takes up is a bit of a black art. The "500(ish)MB" number I mentioned in the previous paragraph isn't anything more than an estimate as I watch my available hard drive space grow and shrink as I create and remove sites. I would love to have easy-to-use commands (for someone that isn't familiar with Docker) showing how much space is being used, options for clearing Docker caches, and anything else that could help developers manage hard drive space.Drush and Drupal Console support
DDEV, Docksal, and Lando's command line tool provide a command to run Drush commands: fin drush , lando drush , ddev exec .Pantheon and other remote host support
I tend to use Pantheon quite a bit, both for clients and teaching. The ability to easily get a local environment's database up-to-date from a remote environment quickly is a huge time-saver (and solid development practice). Having integration with Pantheon (and hopefully other hosts in the future) is an important factor for me.
DDEV's Pantheon integration isn't as complete, but it does have the valuable "pull" command which will bring down the database and files directory. I really wish it had separate commands for pulling the database and files directory. Often, it only makes sense to only pull the database, and then use something like Stage File Proxy for local files.
Docksal lags behind in this area - it don't provide any built-in tools for interacting with remote hosts, but they do provide useful examples for creating your own custom commands.
Lando has the edge here, with its robust push-and-pull commands for moving databases, files directories, and codebases between your local and any remote Pantheon environment.
DDEV has various "quickstarts", similar to Lando's recipes, including ones for Drupal 6, 7, and 8, as well as Backdrop, Wordpress, and Pantheon hosting.
Docksal provides some basic default stack configurations, including an Acquia Cloud one, but not on the same level as Lando or DDEV.
Lando provides local development environment "recipes" for a plethora of development projects - including recipes for Drupal 6, 7, and 8, as well as recipes for Pantheon, Python, Dotnet, Joomla, Wordpress, and several other commonly used frameworks and providers (it is really quite impressive).
It doesn't appear that any of the options support Acquia, Platform.sh, or any of the other so-called "modern" Drupal hosting solutions (yet), but I don't think there's anything stopping that from happening in the future. In fact, it is already starting to happen.Support and Documentation
All three options have both issue queue support as well as real-time chat support. Your mileage may vary, but I've found all three projects have very responsive maintainers, with a slight edge going to DDEV for responsiveness.
In addition, they all have relatively good documentation, considering their rapid development schedules and frequent additions. With all three options, I've found that I've had to hunt down answers not easily found in the documentation.
As an example, a few times while creating a new DDEV-powered site, I kept getting a message that port 443 was in use, but I couldn't figure out by what. It was easy enough to change the DDEV config to use a different port number, but it wasn't until I stumbled on a blog post where I learned about "lando poweroff" - this command spins down all Lando containers, including a "traefik" container that holds on to - you guessed it - ports 80 and 443. While there is a documentation page for "lando poweroff", there's nothing on the "Getting started" documentation page about it. It was only by searching the web and finding a blog post that I was able to figure out what the root cause of the issue was. I'm not picking on Lando here (far from it), as I've run into similar documentation issues with DDEV and Docksal as well. Bottom line - use all the support resources available to you.Frequency of updates
One measure of a project's health and momentum is the frequency of updates. In all three cases, development is clearly on-going in each project.
DDEV - 6 releases in 2018 (5 minor, 1 patch), 13 releases in 2017 (10 minor, 3 patch).
Docksal - 0 releases in 2018, 11 releases in 2017 (1 major, 6 minor, 1 patch).
Lando - 4 releases in 2018 (4 betas), 51 releases in 2017 (20 alphas, 31 betas).
While I'm a Mac OS X user, not all of my students always are. Therefore, it is important to me that I select a tool that works well on both Mac and Windows, with a minimum of any "unique configurations" on Windows. All three options utilize some form of automated testing to ensure that each build works on both platforms. To date, I haven't discovered any major issues with any of these tools on Windows. In all cases, I've found it to be much easier to use a 3rd-party command line emulator, rather than using Windows' default command line tools.Requires internet connection
DDEV works fine without an internet connection - no configuration necessary.
Docksal can be run without an internet connection by manually adding an entry to your hosts file via the "fin hosts add mysite.docksal" command.
Lando has a documentation page about offline development, but it is only for Mac OS X, and the process is a bit more involved.
All three tools provide the ability to swap in different versions of PHP via their configuration files.
The latest version of DDEV (0.15.0) now supports overriding php.ini (and other) settings from your project's configuration.
Docksal allows you to place a partial php.ini file as part of your project's configuration. The directives in this file will override any default PHP settings provided by the container.
Lando has some support for some PHP settings as part of their configuration files and also supports a php.ini file as part of a project's configuration.
In all three tools, it is possible to ssh into the CLI container and modify the php.ini settings directly - using this approach, these changes are only temporary, however, as the next time the container is rebuilt, the custom php.ini changes will be lost.Performance
While I didn't run a full suite of tests on all three options, I did want to quantify their relative speed in a real-world situation. My method was to take an actual (Drupal 8) client site, get it up-and-running in all three options (sequentially), and simply time how long it took to run a "drush cache-rebuild all". I ran the command three times for each option and then calculated the average. Other factors depending on your exact site and configuration may come into play (having Xdebug enabled is a bit of a performance hit), so your mileage may vary.
- DDEV: 90 seconds
- Docksal: 20 seconds
- Lando: 89 seconds
Why the huge advantage for Docksal? It's pretty simple - I'm currently using Docksal in "virtual machine" mode instead of utilizing Docker for Mac (both Lando and DDEV utilize Docker for Mac/Windows). It's pretty well-known that native Docker for Mac/Windows solutions are a bit performance-challenged. According to Docksal documentation, Docker for Mac/Windows will eventually become the recommended way of working with Docksal, despite the performance losses.Other stuff
Docksal has a cool "automatic stand-alone CLI container" - this is a container that is not tied to a specific project and is always available. One big advantage to this container is that it can be used to run Composer commands without having to have Composer installed on the host operating system. This is (IMHO) a big deal on Windows, where installing Composer can be tricky (due to its dependency on PHP). There is talk for doing something similar in Lando as well as DDEV.
Docksal utilizes a separate command to start and stop its main virtual machine (fin vm start/stop). It's not a big deal, just a small extra step (but the performance gains are worth it, as mentioned above.)
DDEV automatically writes a settings.local.php file, overwriting the entire file. So, if you're like me and you like to have configuration settings specific to your local environment (Stage File Proxy, Environment Indicator, as well as some of the stuff found in example.settings.local.php, you'll have to either recreate your settings whenever DDEV overwrites the file, or you can create a second settings.local2.php file. There is an open issue about possibly modifying this behavior.
DDEV - the fact that I can completely remove a project's containers without losing the project's database (and other data) is really nice. While their Pantheon integration isn't as robust as Lando's, it does enough (for now). The team behind DDEV appears to have the most consistent release schedule, and I've found their various support channels to be the most responsive. Also - DDEV has a "ddev sequelpro" command that automatically launches the Sequel Pro app (Mac OS X) and connects to the current project's database. I know it's a trivial thing, but I love it so much.
Docksal - its fast. If/when the maintainers decide to make using Docker for Mac/Windows the default, it'll be back on even ground with DDEV and Lando, but for now, it's just plain fast. I also really like that Docksal includes a "fin run-cli" command that allows you to run Composer commands ("composer create-project", for example) before setting up a project's containers. So handy.
Lando - its Pantheon integration is second-to-none. The ability to push and pull code, database, and/or files makes it a breeze when integrating with Pantheon sites. I'm really looking forward to when additional hosting-based recipes are available.
DDEV - I use a MacBook Air with 8GB RAM and a 1.7GHz Intel Core i7 as my main development machine. The stunning performance gap between DDEV and Lando compared with Docksal is completely attributed to Docker for Mac. I don't know all the ins-and-outs about why its performance is so lame, but I find it maddening sometimes. Also, the settings.local.php issue I mentioned above, but fingers-crossed that gets resolved soon.
Lando - re-read what I just wrote about DDEV (except for the settings.local.php stuff). Same. Also, whenever Docker is restarted, the Lando proxy also automatically starts up and grabs hold of port 443 - regardless of if I have any local Lando sites up-and-running. This can cause conflicts with other processes that want to use that port. Lando's "push" command for Pantheon is a little too aggressive for my tastes - it automatically adds, commits and pushes all outstanding changes in your local codebase to the Pantheon repository (I don't care for "git add ." either).
Docksal - lack of Pantheon integration. Granted, it's not terribly difficult to write custom commands to automate pulling databases from Pantheon, but it sure would be nice if it was built-in.
While going through this exercise, I've realized that there's really no single globally "the best" solution. There are pros and cons for each option, and it's really up to the developer (or development team) to determine what's best for them.
Regardless of which option you decide to go with, here are some important things that I've learned:
Pay attention to updates and apply them appropriately (including Docker updates if you're using DDEV or Lando). The pace of each option is such that something that doesn't work today might very well be fixed in the very near future. Pay attention to the release notes for each update, as sometimes there are incompatibilities with specific versions of Docker.
All of these options take up a non-trivial amount hard drive space for each project. For projects that are dormant, go ahead and destroy the containers - that's the whole point of having a solid developer workflow. Recreate the containers (re-import the DB and files directory if you're using Lando or Docksal) when you need to work on the project again.
Get familiar with the real-time chat support for whichever option you go with. They can be real time-savers.
Which will I be using going forward? For client work, the answer is "probably all three". For more complex sites, I'm addicted to Docksal's performance. For teaching, I'll be test-driving standardizing on DDEV starting with the Spring, 2018 class of Drupal Career Online. It's ease of installation on both Windows and Mac OS X, along with its straightforward commands, hard-drive-space-saving architecture, and incredibly responsive support channels give it the edge (at least for me) over Lando.
Which solution should you use? It really depends on you and/or your team's situation. You're going to want to take into account factors such as host operating system (Mac OS X or Windows), hosting environment (on-site, managed VPS, Acquia/Pantheon/Platform.sh), skill level, and other factors. We're experiencing a bit of a renaissance in local development environments with a good deal of innovation and momentum - which makes it a buyer's market, so take advantage and find the solution that works best for you.Official project links
How to add Docksal to an existing project - blog post by Gerado
Getting Started with Lando - testing a fresh Drupal 8 Umami site - blog post by Jeff Geerling
Install, test, repeat - Rapid local development with DDEV - blog post by Jeffrey A. "jam" McGuire
Journey to Lando: Mistakes, pivots, and vindication - blog post by Mike Pirog
Power your Drupal 8 Project with Docksal - blog posty by Steven Murray
Thanks to Mike Pirog from the Lando project, Rick Manelius from the DDEV project, and David Hernandez from the Docksal project for their input on this blog post.
On March 17-18 the ADCI Solutions team held Drupal GTD for the 6th time. Drupal beginners from Omsk got the unique possibility to take part in one of the biggest events in the Drupal world.
If you want to learn how to make Drupal GTD, dive into the blog.
Commerce integration into PeachPayments https://peachpayments.com
This module is under development.
For some reason, you aren’t getting good traffic to your site. Before diving into an intensive content review, consider that you may have made a great website for people, but you haven’t caught the attention of search engines.
This module is used to render a pre-configured block with a toggle on/off switch from a boolean field.
When you have created a related content view block with contextual filters based on the current node and place it within the content area with a toggle switch to show or hide this block, this is the module for you!Requirements
You must have the block and display suite modules installed.
One of the most interesting features added in Drupal 8.5 is the new layout builder module. The layout builder lets you change the way your content is presented. You can add sections to display content using different layouts, and build out according to your design requirements. The exciting part is that you can combine these sections together to create truly customized pages. The user interface, though still a work-in-progress, is similar to page builders in systems like Square Space, WordPress, and Wix. Combine this UI with Drupal's content management features, and the layout builder is a really powerful site building tool.
The layout builder can be used in two ways. You can use it to create a layout for each content type on your site and you can also use it to create a layout for each individual piece of content. This second use case makes the layout builder a landing-page-building tool that content editors and marketers can use to create flexible pages within a Drupal site.
The layout builder module is currently experimental, meaning that its API might change and it's not recommended to use it in production sites yet. That's because there's a risk that your layouts will stop working when you do an update because of changes to the module.Configuring the Layout Builder Module for Content Types
Let's say that we want to display an article in two columns. One column for the image and another for our text fields:
A two-column layout created with the layout builder.
To be able to use the layout builder, enable the module named Layout Builder from the Extend page (admin/modules) in the admin section.
Having enabled the module, the next step is to configure the display of our article content type. For this example, we will modify the Default display of the Article content type. Simply go to Admin > Structure > Content types > Article > Manage Display (admin/structure/types/manage/article/display) and click on the Manage Layout button.
Clicking on Manage Layout should take you to a page where you can modify the layout for articles. The layout is made up of sections and each section can display blocks and fields.
- Sections: Each section can contain content arranged in a certain layout. Example: 2 columns, 3 columns, etc.
- Inside each section, you can display:
- Fields from the content being displayed. Example: title, body, tags, etc.
- Blocks which appear on the Structure > Block Layout page. Example: Page title, tabs, blocks from the custom block library, etc.
For this example, we configure a 2-column layout with the image in the left column and some other fields like author name, body and tags in the right column.
Choose the layout and arrange your blocks.
Once you are done configuring, click on the Save Layout link towards the top of the page. That's it! Now, when you visit the article view page, you should be able to see your layout in action.Configuring the Layout Builder Module for Specific Nodes
On the Manage Display tab, you can also select a checkbox to 'Allow each content item to have a customized layout'. This means that each piece of content has its own 'Layout' tab where you can add sections and change the layout and content for each individual article.
The layout mechanism works the same way, and you can place sections on the page and pick the layout and content for each one.Video Tutorial
Confused? Check out this video created by my colleague Suzanne Dergacheva explaining how the layout builder works. For more in-depth training on creating landing pages with Drupal using this and other techniques, see our Landing Page Architecture and Theming course. We're offering this course at DrupalCon Nashville in April.+ more awesome articles by Evolving Web
With all the changes in Drupal 8, it’s no wonder the landscape for access control modules is adapting. While the port of Organic Groups has started, there are several major issues to resolve before it’s ready for use. There are, however, a couple promising new options.Permissions By Term
If you don’t need group management, Permissions by Term is the Drupal 8 substitute for the Taxonomy Access Control module. It controls node visibility based on the how a node is tagged. Term access is granted by role, and individual users can be whitelisted for term access permissions.
Allows the use of the Tablesorter jQuery plugin, but using the Mottie's fork.
The purpose of this project is to integrate Drupal Commerce with the KITE print-on-demand fulfillment provider.
An OSTraining member has asked us how to achieve the following in Drupal 7:
- A customer fills out a form to send their request for repair or service on a specific piece of equipment.
- A customer service agent comments on the request to either approve or deny it.
- The customer gets an automatic email after his request has been processed.
In this tutorial, you will look at this use case. You will learn how to achieve these requirements by creating a node.
Provides Apollo Client as a drupal library.Dependencies
There are none, although a polyfill and ES6 transpilation are strongly recommended.Polyfill
A polyfill will ensure feature parity between browsers and add missing functions. For a zero-config solution use [Babel polyfill](https://drupal.org/project/babel).