Symfony Console is a great component for building a command-line tools. It's bundled as part of the Symfony framework and most of the documentation is geared towards using it with Symfony framework for building commands for recurring jobs.
Latest Blog Posts
Did you know Drupal 8 has a new system to manage config? sure, everyone does by now.
But, did you know you can validate the import of config? Maybe not, that's a bit more of a hidden gem.
As someone who has been using Drupal for over 9 years, attended 8 DrupalCons, spoken at 4 for of them, been on the DrupalCon track team twice, and was co-lead for DrupalCon London I've feel I know Drupal events pretty well.
In his keynote at DrupalCon Baltimore 2017, Dries talked for some time about how Drupal is now for Ambitious Digital Experiences. There has been a lot of talk over the last few years, especially since Drupal 8 was release, that Drupal is now an enterprise CMS. With this keynote it seems as though Dries is, in a way, acknowledging this. Ambitious Digital Experiences reads as something more complex than a blog, a brochure site, or sites for SMEs.
As part of the Drupal Workflow Initiative we have critical issue relating to Content Moderation and translations. This is not actually a Content Moderation issue, but is just surfaced by Content Moderation because it allows you to create forward revisions. The video here should explain the issue:
A few weeks ago I recorded an updated screencast of the Workspace, Deploy, and Relaxed Web services module. Here it is:
Please comment, tweet, IRC, or Slack any questions.
Over the past month there has been a lot of focus on Drupal, the community. More recently it seems people are back to thinking about the software. Dave Hall and David Hernandez both posted eye opening posts with thoughts and ideas of what needs doing and how we can more forward.
A one line summary of those posts would be "We should slim down core, make it more modular, and have many distros".
Drupal 8 has two revisionable entity types, Node and Block Content. When working with revisions it's key to understand the different states a revision can have.
If you have a node with the ID 1 you can load it with
Node::load(1);, this will load the default revision. You may have 200 revisions of node 1, but the default revision is the one which is loaded by default.
Currently forward revisions are revisions with a higher revision ID than the default revision, and past revisions are revisions with a lower revision ID than the default revision.
We have been extremely hard at work this year with the Workflow Initiative bringing some quite big underlying changes to the Entity API and some great advances in core such as the Content Moderation module. There are now around 8 weeks until feature freeze for 8.3.x and there’s still a number of key things we want to get in. Please take a look at our kanban board and see if there’s anything you’d like to take a look at even if it’s just a quick review, a little feedback, or a +1.
At the time of writing this post there are 8 Workflow Initiative issues in Needs Review:
Which core entities get revisions?
We are looking at making more content entities in core revisionable, this will roll out gradually, but which ones should we make revisionable?
Add a content entity form which allows to set revisions
This is mainly an effort by the Media Initiative, but affects the Workflow Initiative too. The idea is to have a generic entity form for revisionable entities.
Add a publishing status field to BlockContent
Shock horror! Block content entities are currently not able to be unpublished. We need to fix this! This will be a pattern for making other things able to be unpublished too.
Upgrade path between revisionable / non-revisionable entities
This patch has had so many iterations but the current one is looking pretty awesome. It will give ups an upgrade path for entity types such as taxonomy terms and menu links to have revisions.
Introduce sorted set key value store
Before we introduce Workspaces in core we want to store a sequence of entity updates, a sorted set key value store will allow us to do this.
Store revision id in originalRevisionId property to use after revision id is updated
There are a number of bugs in core which require us to know what the revision id of an entity object used to be. This issue solves this by adding a simple property.
Introduce a EditorialContentEntityBase class for revisionable and publishable entity types
When we make more entity types revisionable and publishable it’d be great if they all extended the same base class. This issues does this for Nodes, we will then be able to roll it out to Block content once publishable, and other entities once revisionable.
WI: Content Moderation module roadmap
Content moderation is currently in core as an alpha experimental module. How can we get this to beta then stable?
For the last 18 months I have been working full-time on Drupal workflow solutions, first with the Deploy suite of contrib modules, and now with the core Workflow Initiative.
It turns out core is a lot harder than contrib. Everything we have mapped out in the plan for the Workflow Initiative is already done, and working, in the contrib modules. So getting it all in core should be easy, right. Just port over the code from the modules into core APIs or core modules and it’s done. Well… no.
Everything in core needs to be generic, it needs to work for everyone. In contrib you can choose not to use module X if it’s not compatible with module Y, or if it doesn’t work with your use case, in core there is less of that luxury.
Also in core everything has to be done “properly”. We can’t just get a solution that works well enough and run with it, we need to be sure it is the best (or least worse) solution.
Some examples of the issues we are facing so far is with the Upgrade path between revisionable / non-revisionable entities issue. In contrib we use the migrate module to migrate all content out, make entity types revisionable then migrate everything back. For core this is not stable enough so we need a custom set of update hooks. Then Add StatusItem field type to store archived state in contrib we just add a new base field to all entity types to store the archived state. In core there are performance concerns with a new field and new conditions.
Thankfully there are so many people working and thinking about things that will help some of these areas, and as we continue to develop core we should be able to make things easier.