The Maestro Engine is the mechanism responsible for executing a workflow template by assigning tasks to actors, executing tasks for the engine and providing all of the other logic and glue functionality to run a workflow. The maestro module is the core module in the Maestro ecosystem and is the module that houses the template, variable, assignment, queue and process schema. The maestro module also provides the Maestro API for which developers can interact with the engine to do things such as setting/getting process variables, start processes, move the queue along among many other things.
As noted in the preamble for our Maestro D8 Concepts Part 1: Templates and Tasks post, there is jargon used within Maestro to define certain aspects of the engine and data. The major terms are as follows:
This is part 2 of our series on developing a Decoupled Drupal Client Application with Ember. If you haven't yet read Part 1, it would be best to review Part1 first, as this article continues on with adding authentication and login form to our application. Shortly, we will explore how to create a new article but for that we will need to have authentication working so that we can pass in our credentials when posting our new article.
Templates and tasks make up the basic building blocks of a Maestro workflow. Maestro requires a workflow template to be created by an administrator. When called upon to do so, Maestro will put the template into "production" and will follow the logic in the template until completion. The definitions of in-production and template are important as they are the defining points for important jargon in Maestro. Simply put, templates are the workflow patterns that define logic, flow and variables. Processes are templates that are being executed which then have process variables and assigned tasks in a queue.
Once created, a workflow template allows the Maestro engine to follow a predefined set of steps in order to automate your business process. When put into production, the template's tasks are executed by the Maestro engine or end users in your system. This blog post defines what templates and tasks are, and some of the terms associated with them.
This is the first in a series of articles that will document lessons learned while exploring using Ember as a decoupled client with Drupal.
You will need to have Ember CLI installed and a local Drupal 8 (local development assumed). This initial series of articles is based on Ember 2.14 and Drupal 8.3.5 but my initial development was over 6 months ago with earlier versions of both Ember so this should work if you have an earlier ember 2.11 or so installed.
You should read this excellent series of articles written by Preston So of Acquia on using Ember with Drupal that provides a great background and introduction to Ember and Drupal.
We've put together a Maestro overview video introducing you to Maestro for Drupal 8. Maestro is a workflow engine that allows you to create and automate a sequence of tasks representing any business process. Our business workflow engine has existed in various forms since 2003 and through many years of refinements, it was released for Drupal 7 in 2010.
If it can be flow-charted, then it can be automated
Now, with the significant updates for Drupal 8, maestro was has been rewritten to take advantage of the Drupal 8 core improvements and module development best practices. Maestro now provides a tighter integration with native views and entity support.
Maestro is a solution to automate business workflow which typically include the movement of documents or forms for editing and review/approval. A business process that would require conditional tests - ie: IF this Then that.
The Maestro Workflow Engine for Drupal 8 is now available as a Beta download! It has been many months of development to move Maestro out of the D7 environment to a more D8 integrated structure and we think the changes made will benefit both the end user and developer. This post is the first of many on Maestro for D8, which will give an overview of the module and provide a starting point for those regardless of previous Maestro experience.
Testing out the new Umami demo profile in Drupal 8.6.x.
I wanted to post a quick guide here for the benefit of anyone else just wanting to test out how Lando works or how it integrates with a Drupal project, since the official documentation kind of jumps you around different places and doesn't have any instructions for "Help! I don't already have a working Drupal codebase!":
DrupalEasy: DrupalEasy Podcast 207 - David Needham - Pantheon, Docker-based Local Development Environments, and Hedgehogs
David Needham (davidneedham), Developer Advocate with Pantheon as well as a long-time Drupal community member and trainer, joins Mike Anello to discuss his new-ish role at Pantheon, tools for trainers, and a bit of a rabbit-hole into local Docker-based development environments.Interview
- Pantheon training options
- Automated Workflows with Drupal 8, GitHub, Composer, and CircleCI workshop at DrupalCon Nashville.
- For more information about Pantheon for Trainers, contact David Needham.
- Introduction to Drupal 8 Module Development full-day training at DrupalCon Nashville. Monday, April 9, 2018.
- Drupal Career Online - begins March 26, 2017.
- MyDropWizard.com - Long-term-support services for Drupal 6, 7, and 8 sites.
- WebEnabled.com - devPanel.
If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.
Last week I was able to attend Drupalcamp London and present a session called “Drupal 101”. The session was about how everyone is welcome in the Drupal Community, irrespective of who you are. At Drupalcamp London I met people from all walks of life whose lives had been changed by Drupal. I caught up with a friend called Ryan Szrama who is a perfect example of my message, he conducted a brilliant speech at Drupalcamp about “doing well by doing good” so I’d like to share his story with you.
Extra quick tip for Drupal developers: Adding views to your page content is now incredibly straightforward:$content['editor_tools']['view'] = [ '#type' => 'view', '#name' => 'editor_tools', '#display_id' => 'embed', '#arguments' => [ 123, ], ];
And that's it! $content is my render array which I'll return and let Drupal render. I suspect most of the bits there are self-explanatory, but in case they aren't:
Would you like to avoid a hassle of processing and keeping your online customers' card details? Stripe is a global online payment gateway you can quickly start using just for that.
In this tutorial, you will learn how to easily embed the "Buy Now" button from Stripe into your Drupal content. You will be able to integrate the Stripe Checkout even if you don't know how to write code.
Since the release of Drupal 8, it has become tricky to determine what and where override configuration is set.
Here are some of the options for a better user experience.by Daniel Phin / 12 March 2018
Drupal allows you to override configuration by setting variables in settings.php. This allows you to vary configuration by which environment your site are served. In Drupal 7, when overrides are set, the overridden value is immediately visible in administration UI. Though the true value is transparent, when a user attempts to change configuration, the changes appear to be ignored. The changes are saved and stored. But Drupal exposes the overridden value when a configuration form is (re)loaded.
With Drupal 8, the behaviour of overridden configuration has reversed. You are always presented with active configuration, usually set by site builders. When configuration is accessed by code, overrides are applied on top of active configuration seamlessly. This setup is great if you want to deploy the active configuration to other environments. But it can be confusing on sites with overrides, since its not immediately obvious what Drupal is using.
An example of this confusion is: is your configuration forms show PHP error messages are switched-on, but no messages are visible. Or, perhaps you are overriding Swiftmailer with environment specific email servers. But emails aren't going to the servers displayed on the form.
A Drupal core issue exists to address these concerns. However this post aims to introduce a stopgap. In the form of a contrib module, of course.
Introducing Configuration Override Inspector (COI). This module makes configuration-overrides completely transparent to site builders. It provides a few ways overridden values can be exposed to site builders.
The following examples show error settings set to OFF in active configuration, but ON in overridden configuration. (such as a local.settings.php override on your dev machine)// settings.php $config['system.logging']['error_level'] = 'verbose';
Hands-off: Allow users to modify active configuration, while optionally displaying a message with the true value. This is most like out-of-the-box Drupal 8 behaviour:
Expose and Disable: Choose whether to disable form fields with overrides display the true value as the field value:
Invisible: Completely hide form fields with overrides:
Unfortunately Configuration Override Inspector doesnt yet know how to map form-fields with appropriate configuration objects. Contrib module Config Override Core Fields exists to provide mapping for Drupal core forms. Further documentation is available for contrib modules to map fields to configuration objects. Which looks a bit like this:$config = $this->config('system.logging'); $form['error_level'] = [ '#type' => 'radios', '#title' => t('Error messages to display'), '#default_value' => $config->get('error_level'), // ... '#config' => [ 'key' => 'system.logging:error_level', ], ];
COI requires Drupal 8.5 and above, thanks to improvements in Drupal core API.
Have another strategy for handling config overrides? Let me know in the comments!Tagged CMI, Contrib Modules
MidCamp 2018 wrapped up with a bang today, as there was another year full of great training, sessions, and my favorite aspect, the 'hallway track' (where you go around and network between and during some sessions with tons of excellent Drupalists from the Midwest and around the country).
This year, I presented two sessions; one a co-presentation with Chris Urban titled Local Dev Environments for Dummies, the other a solo presentation titled Jenkins or: How I learned to stop worrying and love automation.
Embedded below are the video recordings of the sessions (recorded as always by the excellent Kevin Thull of Blue Drop Shop!):
Talking about the many contributors to Drupal 8.5, a few of them shouted out on social media that they got their first patch in Drupal 8.5. They were excited but admitted it was more challenging than anticipated. It's true that contributing to Drupal can be challenging, but it is also true that it will accelerate your learning, and that you will likely feel an incredible sense of reward and excitement. And maybe best of all, through your collaboration with others, you'll forge relationships and friendships. I've been contributing to Open Source for 20 years and can tell you that that combined "passion + learning + contribution + relationships"-feeling is one of the most rewarding feelings there is.
I just updated my site to Drupal 8.5 and spent some time reading the Drupal 8.5 release notes. Seeing all the different issues and contributors in the release notes is a good reminder that many small contributions add up to big results. When we all contribute in small ways, we can make a lot of progress together.
At DrupalCon Dublin I caught Fabianx’s presentation on streaming and other awesome performance techniques. His presentation explained how BigPipe worked to me, finally. It also made me aware of the fact that, in Drupal, we have mechanisms to do expensive procedures after output has been flushed to the browser. That means the end user sees all their markup but PHP can chug along doing some work without the page slowing down.
An interesting thing to consider is, does it need to be a part of the site repository in the first place?
If from the beginning you intend to contribute the module, theme or distribution and it’s written as generic and re-usable from the start, then it could be created as a separate project on Drupal.org or as a private repository on your Git server from the beginning, and added as a dependency of the main project rather than part of it. It could already have the correct branch name and adhere to the Drupal.org release conventions and be managed as a separate project, then there is no later need to "clean it up" or split it from the main repo at all.
This is how I worked at the Drupal Association - with all of the modules needed for Drupal.org hosted on Drupal.org itself, and managed as a dependency of the site repository with Drush Make.
Whether this is a viable option or not will depend on your processes. For example, if your code needs to go through a peer review process before releasing it, then pushing it straight to Drupal.org would either complicate that process or bypass it completely. Pushing it to a separate private repository may depend on your team's level of familiarity with Composer, for example.
It does though avoid the “we’ll clean it up and contribute it later” scenario which probably happens less than people intend.Create a new, empty repository
If the project is already in the site repo, this is probably the most common method - to create a new, empty repository for the new project, add everything to it and push it.
For example:cd web/modules/custom/my_new_module # Create a new Git repository. git init # Add everything and make a new commit. git add -A . git commit -m 'Initial commit' # Rename the branch. git branch -m 8.x-1.x # Add the new remote and push everything. git remote add origin firstname.lastname@example.org:project/my_new_module.git git push origin 8.x-1.x
There is a huge issue with this approach though - you now have only one single commit, and you’ve lost the commmit history!
This means that you lose the story and context of how the project was developed, and what decisions and changes were made during the lifetime of the project so far. Also, if multiple people developed it, now there is only one person being attributed - the one who made the single new commit.
Also, if I’m considering adding your module to my project, personally I’m less likely to do so if I only see one "initial commit". I’d like to see the activity from the days, weeks or months prior to it being released.
What this does allow though is to easily remove references to client names etc before pushing the code.Use a subtree split
An alternative method is to use git-subtree, a Git command that "merges subtrees together and split repository into subtrees". In this scenario, we can use split to take a directory from within the site repo and split it into it’s own separate repository, keeping the commit history intact.
Here is the description for the split command from the Git project itself:
Extract a new, synthetic project history from the history of the subtree. The new history includes only the commits (including merges) that affected , and each of those commits now has the contents of at the root of the project instead of in a subdirectory. Thus, the newly created history is suitable for export as a separate git repository.
Note: This command needs to be run at the top level of the repository. Otherwise you will see an error like "You need to run this command from the toplevel of the working tree.".
To find the path to the top level, run git rev-parse --show-toplevel.
In order to do this, you need specify the prefix for the subtree (i.e. the directory that contains the project you’re splitting) as well as a name of a new branch that you want to split onto.git subtree split --prefix web/modules/custom/my_new_module -b split_my_new_module
When complete, you should see a confirmation message showing the branch name and the commit SHA of the branch.Created branch 'split_my_new_module' 7edcb4b1f4dc34fc3b636b498f4284c7d98c8e4a
If you run git branch, you should now be able to see the new branch, and if you run git log --oneline split_my_new_module, you should only see commits for that module.
If you do need to tidy up a particular commit to remove client references etc, change a commit message or squash some commits together, then you can do that by checking out the new branch, running an interactive rebase and making the required amends.git checkout split_my_new_module git rebase -i --root
Once everything is in the desired state, you can use git push to push to the remote repo - specifying the repo URL, the local branch name and the remote branch name:git push email@example.com:project/my_new_module.git split_my_new_module:8.x-1.x
In this case, the new branch will be 8.x-1.x.
Here is a screenshot of example module that I’ve split and pushed to GitLab. Notice that there are multiple commits in the history, and each still attributed to it’s original author.
Also, as this is standard Git functionality, you can follow the same process to extract PHP libraries, Symfony bundles, WordPress plugins or anything else.
One of the common issues I've noticed when working with customers is the tendency to treat non-production environments, such as dev or stage, as less important with respect to security.
This is understandable since these environments are effectively disposable and could be rebuilt from production at any time. However an important consideration that should be taken into account is what data lives in these environments.Tags: acquia drupal planet