All RPGs and Storygames by Tod Foley are now available at DrivethruRPG and RPGnow. Bring these games to your table!
Every generation is a little different. They bring different beliefs and perspectives tied to their upbringing. Generation Z, those born in 1995 or later, have been brought up in a world where information is at their fingertips. They are digitally connected through laptops, tablets and smartphones. If they have a question, all they have to do is pull out a device and ask Siri, Google or Alexa. They have a drive for getting information, learning new things and making an impact.
Gen Z students interested in Stanford are no different. We've often heard Stanford describe their students as adventurous, highly motivated, and passionate in their desire to come together and deepen their learning. During their time at Stanford, they will discover what motivates them and how they can impact the world after graduation. This is true of full-time Stanford students, as well as visiting students participating in the Summer Session. Stanford’s Summer Session provides current Stanford students, high schoolers and students at other universities with the unique opportunity to complete a summer at Stanford – getting a full experience of the coursework and college life Stanford offers.
The program isn’t cheap, and not every student can afford it.
We recently worked with the Stanford Summer Session communications team to combine the high school and college level websites into one site with a fresh design and structure. We kicked off the project with a discovery phase that included user surveys and stakeholder interviews.The Problem Image 1 The old tuition tables from Stanford Summer Session. Students had to navigate the fees and add all the relevant fees up on their own.
As we learned from the user surveys, students are cost-aware individuals, just like Gen Zers all over the nation. Corey Seemiller and Meghan Grace in Generation Z Goes to College couldn’t have put it any better: “Anxiety over being able to afford a college education is forefront on the minds of these students.” Prospective Summer Session students were specifically looking for ways to make the program fit within their budget. This message was amplified by the interviews we conducted with the Summer Session staff, who noted that tuition information was buried, and in some cases, scattered throughout the site.
Through more discussion with stakeholders and students, we learned that students struggled with deciphering the available tuition and fee tables, inhibiting them from learning how much the program would cost (see Image 1). Additionally, as fees and tuition changed every year, staff found it painful and time-consuming to update information in the old system.The Solution
So what did we do to help these students out? We created a one-stop-shop to get an estimate of the cost – welcome the tuition and fees calculator. By answering a few simple questions, students can get a true estimate of the total cost for their summer at Stanford. If they’re not happy with the results, they can tweak their answers to help make the program fit their budget.
As an added bonus, the system makes it really easy for staff to update the costs each year! On the admin side, each question and list of answers are fully editable. The dollar amounts can be changed for each student type to ensure the estimate will stay accurate for each coming school year. On the front end, the questions are organized, options are shown or hidden depending on previous answers, and the total amount is tallied on the final screen. Vue.js allowed us to build a complex interface simply, while making the static data more engaging.How We Got There
Hopefully you’re in love with the solution we came up with, and maybe you’re wondering how we got here. Well, you already know we did some research – surveyed current students and interviewed staff – to learn about the problems they were facing. We then brought our two teams together to brainstorm ideas using the Core Model exercise.
We took a few minutes to sketch out the proposed solution.
These ideas were then further refined in wireframes and design:
And finally developed in Drupal 8.
The tuition and fees calculator was designed to provide Gen Zs with the information they need to financially plan their summer at Stanford, but all generations can benefit from it. Since launch in November 2017, the calculator has appeared in the top 10 visited pages of the redesigned site, with an average of 3000 pageviews per month.
The Drupal Association Board is responsible for the Drupal Association’s financial health and as part of their duty, they vote to approve monthly financial statements. The board met virtually on February 27th, 2018 and voted to approve the Q3 & Q4 2017 financial statements.
Each month we compare our results against the two financial KPIs that we measure against:
- Cash Reserve: have a cash balance of 15-30% of Total Revenue
- Net Income Profit Margin: end 2017 with a net income profit of 10%
These two goals focus on increasing Net Income in order to build a stronger cash reserve.
Below is a summary of how we performed in the third and fourth quarters of 2017 against our KPIs. As you look at this chart, you can see that we improved on our KPI month over-month.
Prior to the start of the year, we stated that if we could achieve a 10% Net Income this would move us to the minimum percentage (10%-30%) of the cash reserve. As we move month-over-month, you can see the cash reserve build as our net income percentage increases. December has us land at a Net Income percentage of 16%, and our “money in the bank” was 11%, or $570K (not including restricted cash).
Cash Balance (including Restricted Cash)
Cash Reserve %
Net Income Percent
Cash Balance (excluding Restricted Cash)
Cash Reserve %
The month of July saw us move closer to our cash reserve KPI. We ended the month within 80% of that goal. As we moved closer to DrupalCon Vienna, we saw cash reserves drop because we paid expenses towards the conference. The net income goal outperformed the cash forecast due to fundraising revenue being $31k higher and membership sales coming in $11k more than forecasted. The costs for July tracked to forecast, with a small amount of trailing costs (about 4k) from DrupalCon Baltimore, and bank fees being $5k lower than forecasted.
August had supporter sales and digital sponsorships down $30k from the forecast, however this was offset by an unforecasted time and materials project for $25k. Operating expenses for DrupalCon, along with overall administration costs, stayed in line with the forecast.
September’s focus was DrupalCon Vienna. Overall, net income significantly exceeded expectations for September because of much lower than expected costs for Vienna, and a boost of an additional $46k in revenue. This increase in revenue was mostly due to fundraising ($20k over forecast) and other programs ($26k over forecast). We do expect a significant amount of trailing costs in October for Vienna that will impact the net income in the upcoming months.
Activity for October saw some trailing costs for DrupalCon Vienna, and a clear picture on how DrupalCon Vienna closed out. We were below the forecasted loss of $267k, however the trend towards a loss. Some revenue help was in trailing ticket sales and sponsorship sales, which did beat the forecast. The events team did a great job containing costs, and maximizing savings in catering, supplies and our print signage for approximately $71k of savings in those budgets. Additionally, we were able to reclaim $32k of VAT through deductions on tax returns. This moved the anticipated net margin loss from -31% to -22% on this event.
November saw trailing costs from DrupalCon Vienna, which increased the forecasted loss of $68k to $114k. (October’s predicted loss was much less than forecasted) This was due to timing issues, as these invoices were expected to come in October.
December had some variances between actual and forecasted, ending up with a $59k loss instead of the forecasted $66k. Some of the more material events were:
- Revenue was up $50k over forecast due to VAT deductions from Vienna booked to uncategorized income at month’s end that totaled $57k.
- Board expense came in at $4k but we had none forecast. We have updated the forecast for the recurring $4k item to be included each month.
- IT expense in the admin section was $7k for December, but we forecasted $16K.
- Cash ended the month (and year) at $770k, which was $119k higher than our forecasted $651k. This ends our year with our minimum cash reserve goal sitting at 10%.
With reforcasting in process, and not quite finalized, we expect cash to grow over the next four months, leading into DrupalCon Nashville in April 2018.
We will be blogging soon about our 2017 close, which includes our CPA driven financial review (a lighter “audit”), production of our 2017 990 tax return and a 2017 weather report review from our virtual CFO group Summit.
We would not be able to do our mission-driven work without the support and contributions of our community. Contributions come in many forms, through the purchase of DrupalCon tickets and event sponsorships, through our Supporters and Members, Drupal.org sponsors, recruiters who post jobs on Drupal Jobs and many other fantastic ways our community supports the Drupal eco-system. We are deeply grateful for everyone who has contributed their time, talent, and treasure to move Drupal forward.
Thank you!File attachments: Drupal Association - Q3 2017 Financial Statements.pdf Drupal Association - Q4 2017 Financial Statements.pdf
It's a few years old, but I don't think I've seen this Drupal rap video yet:
It's a few years old, but I don't think I've seen this Drupal rap video yet:
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.