Core Drupal Commerce provides Order Receipt functionality. An Order Receipt is an email notification sent to a customer when an order is placed. It lets the customer know that the order has been received and includes a summary of the order. For each Order Type, you can turn order receipts on/off and, if enabled, specify that a copy be sent to a specific recipient.
When a store has customers that are businesses or institutional, the standard Address field properties and formatting may not align well with actual billing and shipping addresses. For example, a business address may not include the customer's first and last name as the first line; instead, an organizational name may be used. If a contact name is included, it may be an "Attention" line. Additionally, businesses may require a line with reference or purchase order number.
Drupal Commerce order types can be configured to email the customer a receipt when an order is placed, with or without a BCC copy sent to a specified email address. Additionally, administrative users can use a "Resend receipt" button to send a receipt to the contact email address set for the order; no copy is sent to an additional email address.
When re-sending an order receipt, administrative users may want to:
Administrative users creating and updating orders in the backend may want to:
Developers may want to:
We can add a button to the right of the existing, "Resend receipt" button that appears on Order View pages, like this:
Recently, Randy Fay of the DDEV project blogged about two new Docker providers available (and supported by DDEV) for MacOS: Rancher Desktop and OrbStack. Both of these join Colima and Docker Desktop as supported Docker providers for DDEV on MacOS.
I know that I certainly have asked this question - more times than I care to admit. As Randy explains in the blog post:
All of the Docker Providers on every platform (except Linux) are actually wrappers on the open-source Docker/Moby project, which is supported by Docker, Inc.
In other words, in order for DDEV to talk to Docker, it needs a provider. But, not all Docker providers are created equal. Neither Docker Desktop nor OrbStack are open-source - both have free versions (with restrictions); for most commercial use cases, there is a cost involved. Colima and Rancher Desktop are both open-source.
Features vary between Docker providers as well, so it only makes sense that performance differences also exist. Fortunately, Randy has written another blog post summarizing the performance differences between the various Docker providers on MacOS.
tl;dr if you have Mutagen enabled with DDEV, then they're all pretty fast, with OrbStack having the edge.
While Colima is (IMHO) heads-and-tails better than Docker Desktop for Mac, upgrading Colima itself has been a bit of a rocky road. I have learned to never assume that my databases will remain intact during a Colima upgrade. This usually isn't a deal-breaker, but for me, it is squarely in the inconvenience category.
I'm hoping that the situation is smoother with Rancher Desktop.
As I (currently) use DDEV on MacOS with Colima (and Mutagen enabled,) I decided to give Rancher Desktop a try, as it is an open-source option.
Using the instructions provided by the DDEV project, I downloaded Rancher Desktop from the official site. A bit surprisingly, the recommended installation method was not Homebrew, but rather a bit of an old-school MacOS .dmg file.
After downloading Rancher Desktop (but before installing it,) the steps I took to install and change over from Colima began with:
$ ddev poweroff
$ colima stopNext, I double-clicked to install Rancher Desktop - making sure to uncheck the "Kubernetes" checkbox as the DDEV instructions suggested. I didn't touch any other settings during the Rancher Desktop install.
Once that was installed, I restarted my Terminal app, then navigated to one of my DDEV projects.
$ cd ~/sites/d10
$ docker context use rancher-desktop
$ ddev startIf you haven't used it before, the docker context use rancher-desktop bit basically tells Docker which provider to use. In other words, you can have multiple providers installed (like I do with Colima and Rancher Desktop) and switch between them using the docker context use command.
With that, installation was complete.
In short: uneventful (in a good way)
I didn't have any issues at all - it all went very smoothly. From a performance standpoint, Drupal 10 sites feel a little bit snappier than with Colima, but this is purely qualitative, not quantitative.
When switching Docker providers, while project code isn't touched, unfortunately, project databases don't automatically come along. In his blog post, Randy suggests using ddev snapshot --all as an initial step in the process to back up all databases. I tend to take a more piecemeal approach - individually exporting databases while using Colima, then importing them while using Rancher Desktop. For example, here's my process for moving a database from Colima to Rancher Desktop (assuming my system is currently using Rancher Desktop):
$ cd ~/sites/d10
$ ddev poweroff
$ colima start
$ docker context use colima
$ ddev start
$ ddev export-db > db-backup.sql.gz
$ ddev poweroff
$ docker context use rancher-desktop
$ ddev start
$ ddev import-db –file=db-backup.sql.gz
$ ddev drush crGranted, it's a bit wordy, but it works for me.
At the present time, I have no plans to test-drive Orbstack. While Randy's blog post does indicate I would experience a minor performance boost, at this time, I'd rather just stick with an open-source solution.
One of our Professional Module Development course graduates, Jay Volk, recounted his recent experience with Orbstack:
My experience is that OrbStack is really fast and while not open source (it's $8/mo.) it seems well worth the cost and I'm happy to support this project. Orbstack will take your existing Docker settings and move them to Orbstack when starting up (it asks your permission.) This proved to be no problem for DDEV but occasionally causes problems with the other solution I sometimes need, Lando. Easy enough, Docker can reclaim settings back from OrbStack and with a Docker restart you're good to go again with that (albeit slower) solution.
I wrote the first draft of this blog post about 2 weeks ago - since then I've stuck with Rancher Desktop and have no plans to go back to Colima. I'm pretty sure the performance is a bit better than Colima and I've had absolutely zero issues. The real test (for me at least) will be when it comes time to update Rancher Desktop - assuming it is a smooth experience, I doubt I'll be returning to Colima.
Header image generated by ChatGPT-4 using the prompt: "Create a cartoon image of a cowboy lassoing a giant laptop computer using 2:1 aspect ratio". If someone could identify the two flying objects to the right of the laptop, I'd be most appreciative.
The Visual Layout Suite module is a great improvement of the core editorial experience leveraging Layout Builder and many contrib modules. Basicailly, it enables Layout Builder, depends on several contrib modules that improves Layout Builder and ads its custom magic.
One of the most important features is the use of utility classes allowing the configuration of the look and feel easily from the frontend with an instant preview. Additionally, it allows to restrict the utility classes a user can use, so the user is not overwhelmed by the extra options and also the look and feel of the page can be limited to be compliant with the style guide of the site. New utility classes can be easily added and components can be configured to only use a reduced set of utility classes to un clutter the UI.
VLSuite integrates with any Drupal component that integrates with Layout Builder and more: entity fields, paragraphs, Views, SDC, medias, etc. And there's no dependency on any theme, external service or certain entities. The only soft dependency is a Bootstrap 5 theme to enjoy all the VLSuite features out of the box. However, you can use any theme as long as it provides the utility classes you require. T
All the previous information means you could add VLSuite to an existing site with minimal…
Body
Since Drupal 8, there has been a mostly smooth migration path between major versions, so you can upgrade from 8 to 9 to 10 relatively easily.
One bump in the road can be the availability of modules for the new version. Drupal 8 and 9 were only supported for a year after the release of their successors, which didn’t help. While quite a lot of modules had a release supporting the next version quickly, there seemed to be quite a few that were very slow to update, and quite a few sites were waiting for one or two modules to release compatible versions before being able to upgrade. I think there are…
Don't Miss the Last Chance to Submit Your Idea
With over 40 sessions submitted to date, we have a couple of days left for you to get your ideas in for MidCamp 2024!
We’re open to talks for all levels of Drupal users, from beginner through advanced, as well as end users and business owners.
See our session tracks page for a full description of the kinds of talks we are looking for. If you’re new to speaking, check out the recording of our Speaker Workshop for ideas.
Important Dates:
Sponsors Get Early, Privileged Access
Get early and privileged access to new talent and customers by sponsoring MidCamp. We have a variety of sponsorship packages available.
Starting at $600, sponsoring organizations can target their jobs to a select group of experienced Drupal talent, maximize exposure by sharing space with dozens of jobs instead of millions, and have three days of being face-to-face with applicants.
Our sponsorship packages are designed to showcase your organization as a supporter of the Drupal community and provide opportunities to:
Check out the sponsorship packages here, we look forward to working with you to get your organization involved for 2024!
Stay In The Loop
Join the MidCamp Slack and come hang out with the community online. We will be making announcements there from time to time. We’re also on Twitter and Mastodon.
We can’t wait to see you soon! Don’t forget, cancel all those other plans and make MidCamp the only thing happening on your calendar from March 20-22, 2024.
I was just recently starting to get this on projects after (at least I think that's why) I updated to Chrome 120.
Could not open connection: unknown error: cannot find Chrome binary
(Driver info: chromedriver=120.0.6099.71 (9729082fe6174c0a371fc66501f5efc5d69d3d2b-refs/branch-heads/6099_56@{#13}),platform=Linux 6.2.0-37-generic x86_64) (Behat\Mink\Exception\DriverException)
That's the error message in behat at least, which I think originates from the actual webdriver (chromedriver) response. If I look at the debug information from the chromedriver logs it says this:
[1703837483,910][INFO]: [0ca18bb59db30d5acd358de02a01da0a] RESPONSE InitSession ERROR unknown error: cannot find Chrome binary
Well the error is clear enough. It can not find the binary. That's fine by me, but where would I go about informing about the binary? Well, for me that would be in behat.yml:
@@ -33,8 +33,9 @@ default:
w3c: false
marionette: null
chrome:
+ binary: /usr/bin/google-chrome
switches:
This probably translates to something like this, while initiating the session with chromedriver (slightly edited for relevance and brevity):
[1703887172,675][INFO]: [95b2908582293fa560a7301661f5e741] COMMAND InitSession {
"desiredCapabilities": {
"chrome.binary": "/usr/bin/google-chrome",
"chrome.extensions": [ ],
"chrome.switches": [ "--ignore-certificate-errors", "--disable-gpu", "--no-sandbox", "--disable-dev-shm-usage" ],
"goog:chromeOptions": {
"args": [ "--ignore-certificate-errors", "--disable-gpu", "--no-sandbox", "--disable-dev-shm-usage" ],
"binary": "/usr/bin/google-chrome",
"extensions": [ ]
},
"ignoreZoomSetting": false,
"marionette": true,
}
}
If you are using some other tool that interacts with chromedriver, I am sure you are already setting some parameters there, which you could append this new parameter to.