As you'd be aware by now - Drupal 8 features lots of refactoring of from procedural code to object-oriented.
One such refactoring was the way forms are build, validated and executed.
One cool side-effect of this is that you can now build and test a form with a single class.
Yep that's right, the form and the test are one and the same - read on to find out more.
Mapping out the moving parts of the content workflow initiative we arrived at this high level grouping of related activities:
- Create content
- Review & approve content
- Publish content
- Manage the creation, review and publishing process
- Configure the tools that enable all of the above
For either single items of content or a set of multiple items, bundled in a workspace.Create content
Everything related to creating new, editing existing content in the first place.Roles
- Copy writer
- Photo/image editor
- Review assignments
- Create content
- Format content
- Preview content
- Request review
- Edit content based on feedback
- Review other people’s content
- Review existing, live content
All the things that need to happen to get new content ready for publication. Here’s a more elaborate example of a moderation workflow using a workspace.Roles
- Marketing associate
- Review content, give feedback
- Edit content
- Preview content
- Get notified of content conflicts
- Adapt content for different channels
- Analyse impact of content changes
- Review existing content
- Recover content
Actual publication of content and managing its life cycle from then on.Roles
- Section editor
- Define/specify content packages
- Review content (packages)
- Audit (legal, compliance)
- Preview content
- Approve revivisions
- (un)publish content items
- (un)publish content packages
- Schedule (un)publishing of content
- Archive/delete content
Set the strategic agenda, coordinate with other business units, oversee all of the above.Roles
- Managing editor
- Marketing executive
- Support & maintenance
- Define content strategy
- Content planning
- Coordinate with the business
- Coordinate with IT
- Coordinate content delivery
- Define content assignments
- Schedule content production
- Monitor progress
- Review audit trail
Providing the tools and processes to enable all of the above.Roles
- Configure workflows for content moderation
- Configure content workspaces
- CMS configuration: content types, roles & permissions, notification settings…
- Technical development
Hope this helps clarify the main concepts, activities and relationships in the workflow initiative.Tags: drupaluxworkflow initiativedrupalplanetSub title: Must not make spelling mistakes or I have to start over again
Disclaimer: The steps in this tutorial are not recommend for a live site and are experimental!
Recently, I ran into an issue in my local Drupal 8 development environment where uninstalling a module failed. I was getting errors related to the module in question in both the UI and in drush. My bad for not having a recent DB backup for my local, the one I had was too old to use. (I've since fixed that with an automated backup script!) Double my bad for having installed a not-ready-for-primetime module.
That being said, my local site had a ton of configuration and custom entities and I really wanted a clean database. I first attempted to use Features to transport all my config to a new install but kept getting an "Unmet Dependancies" error and was not able to get to the bottom of it. (There are a number of Drupal 8 Features issues open related to this.) I didn't understand this error as I was simply using the same root folder with a new database.
Features aside, I knew that by nature, an existing site configuration export can't be imported into another site, this makes sense at face value. But I got to thinking, "well, I just want to take all this nice config and pop it into a brand new site" -- less anything relating to the aforementioned bad module.Get the site UUID
I did more searching and sure enough there is roundabout way to do what I was intending. It involves a few drush commands, drush cget and drush cset. The first command is to get the existing UUID from your present site.drush cget system.site uuid
This will print out the Site UUID as:'system.site:uuid': bfb11978-d1a3-4eda-91fb-45decf134e25
Once you get this, be sure to run drush cex one last time which will export the current configuration.Install and reset
Once I had the current UUID, I put my settings files back to default, created a new database and installed Drupal 8 from scratch. Once the new site installed, I updated my settings.local.php to point to my existing configuration files:/sites/default/files/config_......./sync/
If your remote is on Pantheon, the local config path would be like this:/sites/default/files/config/
Once this was set, all I had to do was reset the new site UUID to my old one that I derived from the drush cget command by running this:drush cset system.site uuid bfb11978-d1a3-4eda-91fb-45decf134e25
This resets the new site's UIID to the old site's UUID and that will allow you to run your config import.Import the existing config
Now it was time to run drush cim which imports your site configuration. Running the command the first time gave me a rather nasty looking error.The import failed due for the following reasons: [error] Entities exist of type Shortcut link and Default. These entities need to be deleted before importing.
This might seem like a scary error but it just has to do with admin Shortcut links and there is a core issue open for this. At any rate this was a new site so I didn't really care about deleting these. I did more searching and discovered an obscure drush command to "fix" this:drush ev '\Drupal::entityManager()->getStorage("shortcut_set")->load("default")->delete();'
Once I did that, my configuration imported like a charm, all 300 config files and several dozens of entities. I didn't see any errors after that, and everything was perfect now.Summary
I am not sure there would be many use cases for doing what is outlined here but it did solve a specific issue, your milage may vary. I would be suspect of using this method for an existing site that has lots of things already built out. Keep in mind, I imported my existing config into a brand new site install.Tags
- Drupal 8
- Drupal Planet
For the last 3 months I’ve been working on Porting the Comment Alter module to Drupal 8 as my GSoC’16 project under mentorship of boobaa and czigor. This blog is an excerpt of the work I did during this time period. Weekly blog posts for the past 12 weeks can be accessed here.Achievements
Creating schema for the module: Implemented hook_schema() to store the old and new entity revision IDs along with the parent entity type as altered by a comment. The revision IDs are used to show the differences over comments. The parent entity type is used to delete the entries from the comment_alter table when any revision of the parent entity is deleted, because in Drupal 8 we can have same revision IDs from different entity types. So to remove entries of particular entity type we need the entity type.
Using ThirdPartySettings to alter field config edit form - Implemented hook_form_FORM_ID_alter() for field_config_edit_form. This provides an interface to:
Make any field comment alterable - Makes it possible to select any field we want to be altered by the comment. Currently all the Drupal core provided fields works well with the module.
Hide alteration from diff - If the comment alterable option is enabled, then this option hides the differences shown over the comments. Instead of the differences, a link to the revision comparison is displayed for nodes. For the rest of the entities a “Changes are hidden” message is shown.
Use latest revision - When a module like Workbench makes the current revision of an entity not the latest one, this option forces the Comment Alter module to use the latest revision instead of the current one. This option is present on the comment field settings.
Adds Diff link on comments - Adds a Diff link on comments which takes us to the comparison page of two revisions, generated by the Diff module.
Comment altering while replying to a comment - By default comment alterable fields can not be altered while replying to a comment. This option allows altering of fields even while replying to comments.
Adding pseudo fields: Implemented hook_entity_extra_field_info() to add one pseudo field for each comment alterable field on respective comment form display, and one pseudo field on comment display to show the changes made at the comment. Using these pseudo fields the position of the comment alterable fields can be re-ordered in the comment form. This gives site-builders flexibility to alter the position of any alterable fields.
Attaching comment alterable fields’ widgets on comment form: Comment alterable field widgets are retrieved from the form-display of the parent entity and they are attached to the comment form only after ensuring that there are no side effects. To support same name fields on both comment and parent entity, #parent property is provided so that the submitted field values for our alterable field widgets appears at a different location, not at the top level of $form_state->getValues(). All these added fields are re-orderable. Column informations and old values are also stored to the form at this stage, to later check if there were any changes made on the comment alterable fields.
Adding submit and validation callback for the altered comment form: First the submitted values are checked against the old values to see if the values of the alterable field changed at all or not. If they changed, then the parent entity values are updated and this is done by building the parent entity form display and copying the altered field values into it. Then the form is saved. In case the parent entity doesn’t support revisions, then do nothing else just save the parent entity with altered values. Otherwise create a revision and store the comment ID, old and new revision IDs and parent entity type in the comment alter database table, which is used to show the differences on comments using the Diff module.
Showing differences on comments: Using the Diff module and comment alter database table, the differences are shown over a particular comment. Only possible if the parent entity supports revisions. Diff module is used to get the differences between the two revisions and then those differences are rendered on comments in table format along with some custom styling.
Adding PHPUnit tests: Added automated unit tests to check the functionality of the module for different field types and widgets. The tests are written for EntityTestRev entity types to keep them as generic as possible. This was the toughest part for me as I was stuck at some places in tests for quite a while as thses tests took lot of time to run and debugging them really is hard. But in the end I’m happy that I was able to complete all the tests.
Screencast/Demo video: Created a demo video showing how the Comment Alter module works, along with a simple use case.What’s left?
My mentors asked me to skip the Rules Integration part because the Rules module doesn’t have a stable or a beta release yet, only their first alpha release is there. So, the Rules Integration part is postponed till we get a stable or beta release.Some important links
The Comment Alter module’s project page on drupal.org
First impressions matter. The first glance has a lot if impact on further expectations. Drupal core doesn’t do well there. As webchick points out, after installation the opening line is “you have no content”.
This empty canvas makes Drupal appear very limited in functionality. Which is the exact opposite of how Drupal is advertised (flexible, extensible, there’s a module for that!)
This is not news. The issue for adding sample content is over 10 years old. The image I posted earlier is from a core conversation 6 years ago. Eaton and moi presented on Snowman in Prague 3 years ago.
But now we do have Drupal 8, with essential features available right out of the box. We have a new release schedule that encourages shipping new features and improvements every 6 months. And we’re settling on a better process for figuring out the part from initial idea to fleshed out plan first, before implementing that plan.
So lets work together and come up with a plan for sample content in core. Which means answering product focussed questions like:
- Audience: who do we make this for?
- Goals: what do these people want to achieve?
- Features: which tools (features) to provide to make that possible?
- Priorities: which of those tools are essential, which are nice to haves?
But purpose first: audience and goals.
We’re always balancing product specifics with framework generics in what core provides. Pretty sure we can do something more opiniated than our current default “Article” and “Page” content types without painting ourselves in a corner.drupalonboardingdrupalplanetSub title: Tabula rasa is not an effective onboarding strategy