Drupal 8 module port journal
Notes on porting modules to Drupal 8.

Drupal 8's Metatag

Acquia’s requirements by 12/4/2015

  • Ability to set global defaults for Title, meta content, meta description, and meta keyworkd tags.
  • Ability to override global defaults on a per bundle basis
  • Ability to override global and bundle defaults on a per entity basis
  • Ability to include tokens from bundles and entities
  • Ability to add no index, no follow tags on a per entity basis

Dave’s thoughts:
  • Damien started a doc in February a list of things to avoid and a roadmap for Drupal 8
  • Port seems rushed. Looks like they didn’t don’t know how the Drupal 7 module worked. Frustrating. A good example of this is that they are not using the API to detect if the current setup for a node matches the default of the content type.
  • One of the problems with the Drupal 7 version is how the metadata was stored. It uses Field API. Is it a field? Is it configuration? Global Metatags should be config entities, node default metatags are configuration entities… but what about specific node ones? Using field API for this, leads to weird cases in view modes.
  • Dave is worried about how flexible the UI should be. We agreed that we will go for the simplest possible and usable UI in order to meet the deadline.

Roadmap 🚗 

@Juan R to work on the porting. @Dave R to provide guidance and peer reviews.

  1. Create GitHub repository.
  1. Create issues for the above list of requirements.
  1. For each issue, check if there is existing logic in the current Drupal Port that a) does use the insight from the Drupal 7 version and b) does not introduce bugs.
  1. If there is code to reuse, adjust it and add test coverage for it.
  1. If there is no code to reuse, study the patterns used in the Drupal 7 version and implement them from scratch along with test coverage.

Tuesday 17th

Implemented a config entity to edit and store Global metatags.

Working on how to rendering them. On the process, I found the commit that adds an API to render tags in HTML pages. There are two related change records:

The recommended event subscriber did not work (may need to debug further). I am now trying it with hook_page_attachments(), which is what system module uses.

Wednesday 18th

Working on how to set the page’s title. Trying hook_page_attachments_alter(). Does not have the title. Moving on to hook_page_top(). Finally made it at hook_preprocess_html().


And this is the Global context edit form:

The above form is not flexible. The module should allow a way for other modules to implement their own meta tags. Thought about the following config entities to accomplish this:

Proposed architecture to manage tags


  • Metatag Context are config entities such as Global, Global: 403 access denied, Node, etc. They hold the context title, a sequence of Tag config entities, and a parent context that points to another Metatag Context
  • Metatag Group are config entities that implement a group of tags. They implement methods to render form fields at the back end, and to render tags at the front end.

The current port to Drupal 8 implements a few plugins to accomplish the above. I will have a look at them again to see if I can reuse some code.

Finished reading. Looks like, as @Dave R said, it is fully oriented to manage tags in nodes, but there is no UI for global metatags, which makes the implementation useless for real-world scenarios. I will continue working on my own approach.

TODO: Read the core tests for metatags. There may be APIs there for us to leverage.
TODO: Read the Metatag spec.

Thursday 19th

Added testing coverage for the UI and tag rendering of the Global context at 

Adding token support to the existing metatags. This will be the foundation for the issue 

First SCRUM notes

David, Neetu, Abhishek, Adam, Jaleel, Adam Hoenich, Kris, Ted

  • Read current port. It focuses in adding metatags to content while it does not define a UI for managing global metatags. Started from scratch. Plan is to reuse bits of the current port where it is possible.
  • Currently working with the global context UI. Added  a few metatags and implemented tests. Now adding token support to them.
  • Next step is to define and implement a more flexible architecture to manage contexts that inherit from the Global one as the Drupal 7 version does.

Friday 20th

Added the token tree dialog plus support of tokens to the rest of the fields at 

Now working in turning tag fields into plugins as suggested by @Dave R. I will check again how this is handled at the current port to reuse as much as possible.

Added Tag plugins. These are now being rendered dynamically instead of being hardcoded form fields:

Now working with the Schema API in order to store the data in configuration.

Sunday 22nd

Looking at how Views module handles configuration. Found that a Views display stores a set of field plugins in configuration, which is the same as what we want to do in Metatag to store a set of tags for a context.

Made it! 

Monday 23rd

Moved field rendering into each plugin.

Implemented the Robots plugin and added more testing coverage to the module.

Implemented entity defaults which override global ones. Here is how the UI looks like after installing the module:

Hangout with Damien McKenna
They have a Trello board, which helps a lot in organizing the work.

Problems that they solved with the current port using Field API: managing revisions and i18n in a reliable way.

Thoughts about the current port: it’s a work in progress. Reasonable starting point. They had to implement metatags for content for a client and that is why they focused just on that. The work that we are doing can complement what’s there already pretty well.

Damien would like us to integrate our code with the current port. I told him that once I get the per-entity-type defaults working, I can look again at the current port and prepare a patch to get my work in.

The Metatagsquick maintainer said that he was keen to help Metatag module since they have something very similar for Drupal 8 using Field API. Larrowan and Michelle are the ones contributing the most nowadays.

Tuesday 24th

Finished the implementation of entity defaults for node, user and taxonomy. Added tests to verify the logic.

Now working in showing the current configuration at the main administration screen as the Drupal 7 module does. Managed something ugly but working:


Now working on per-bundle defaults. The Drupal 7 version has the following workflow:

Issue is 

Wednesday 25th

Implementing per-bundle overrides:
  • Allow per-bundle settings to be added.
  • Filter out existing bundle settings in the Add form.
  • List bundle settings under their entity type.
  • Only allow bundle settings to be deleted. Global and entity settings can just be overridden.
  • Implement bundle overrides.

Got part of the UI working. This is how it looks like:
Realized that I was not passing the entity for token replacements. This was making taxonomy tokens not to be replaced.

Thursday 26th

Finished implementing all requirements. Starting to work on a patch for the Metatag module at Drupal.org.

Integrated my code with the current port. Got all the tests for the global defaults passing at the Drupal 8 port. Now looking at the ones that test field metatags.

Friday 27th

While we discuss where to manage bundle defaults at Drupal.org, I am polishing a few things in the administration interface:

  • Make the metatag field in content types read only.
  • Set field defaults when editing a node using configuration as Drupal 7 does.
  • Show which fields are being overriden in a node as Drupal 7 does.
  • Don't allow global and entity defaults to be deleted. They can be just reverted.


Fixed some warnings in the tests. Now they all pass:
Removed the Delete operation on global and entity defaults: 

Implemented a Revert operation on global and entity defaults. 

Monday 30th

Going to stabilize the current set up by leaving field defaults. This means the following changes:

  • Remove bundle defaults from administration.
  • Review fields defaults in content types.
  • Fix token widget when using core’s token module.
  • Add 404, 403 and front page defaults.

Tuesday 1st

Relaxing day. Started to look at Pathauto module.

Wednesday 2nd

Added front, 403 and 404 defaults for Metatag. Decided to stop working on the patch as we have met all of Acquia’s requirements.

Adam said that Tim Plunkett needs help porting Field Collection. I will take notes for this project at +Drupal 8 Field Collection.

Wednesday 2nd December 2015

Continuing to look into Pathauto. We don’t know when’s the deadline for it. There is quite a bit to read because there are three versions of the module:
  • Plus, the module has an 8.x-1.x branch which was last updated on 4th of October.

Kris has written a document with a few remaining tasks that I could work on. There is also a  branch that may be merged on top of 8.x-1.x or may end up at 8.x-2.x, as Kris sad on IRC. I will start reading everything now to get an idea of the bulk of remaining work. 

Does not work. Most of the code there is Drupal 7 code.

Same as the port at Drupal.org. The code there is for Drupal 7.

Port at https://github.com/md-systems/pathauto (8.x-1.x branch)
Seems to work like the Drupal 7 version by adding all these tabs to the core’s URL alias page:

Broken. I get this error when installing it:

juampy@juampy-box:~/projects/drupal8 (8.0.x)$ drush en pathauto
The following projects have unmet dependencies:                                                                                            [ok]
pathauto requires ctools
Would you like to download them? (y/n): y
Project ctools (8.x-3.0-alpha19) downloaded to /home/juampy/projects/drupal8//modules/contrib/ctools.                                      [success]
The following extensions will be enabled: pathauto, ctools
Do you really want to continue? (y/n): y
ctools was enabled successfully.                                                                                                           [ok]
pathauto was enabled successfully.                                                                                                         [ok]
pathauto defines the following permissions: administer pathauto, notify of path changes
PHP Fatal error:  Class 'Drupal\ctools\Form\RelationshipConfigure' not found in /home/juampy/projects/drupal8/modules/contrib/pathauto/src/Form/ContextConfigure.php on line 14


Meeting with Tim

Port started at lee rowlands 3 years ago. Sandbox. Taken over by jame was. Started working again and merged it back to drupal.org. He did not know what he was doing. PArts commented out. Does not work. Almost every bug reported to Acquia was caused by incomplete code.

People have blocks > field collecitions > field collections > text fields. D7 had code to protect from infinite loops. Tons of problems.

From scratch?
Considering it, but Acquia can’t do that. Can’t change the UI. Need to use the current port. 8.x-1.x is the old code. 8.x-2.x will be the inline entity form version using entity reference.

Acquia has a hit-list. It’s an email. Tim is OK on me using GitHub and then submitting a patch for him to review.

Issues:
Acquia asked Tim to fix these:
https://www.drupal.org/node/2613584 > he is working on it.

Community?
He thinks that asplicious could help, but people just use paragraph module.

Tests?
Some. They pass. 

People doing site build sent a module that simulates what they want.

They are behind schedule. Two months ago Tim was asked to work at field collection. Acquia said that it worked, then it started crashing.

Can’t make big changes to the architecture nor to the UI because there are sites using it.

Thursday 3rd

Reading the code of the current port.

Tim said that I can work in these two issues:

Friday 4th

OOO. Worked on adding an update path for beta2 to Metatag.

Monday 7th

Trying to replicate the warning reported at https://www.drupal.org/node/2611814

Notice: cardinality. Can replicate. Now debugging.

Talked to Tim Plunkett. He needs help with https://www.drupal.org/node/2613584. This function:
\Drupal\field_collection\Plugin\Field\FieldWidget\FieldCollectionEmbedWidget::removeSubmit does not work (should remove a fc), it fails specially to nested fcs. Functions of d7 version are not there. Lot of debuggin but not fixing. >> Start debugging and submit a patch.

Submitted a patch for https://www.drupal.org/node/2611814#comment-10644680. Looks like it was caused by buggy and unneeded code.

Could reproduce the issue removing field collection items at https://www.drupal.org/node/2613584. Currently debugging it.

Tuesday 8th

Testing my patch for https://www.drupal.org/node/2613584.

Findings:
  • Wrapper ids are repeated.
  • Logic does not use WidgetState.
  • Looking at how image field removes images to copy the approach.

The workflow that builds the form and processes the removal of an item is too complex. I need to understand all of its pieces to fix it correctly. I am testing each of the methods at FieldCollectionEmbedWidget. Therefore, I need more time to figure this out properly, but I am confident that I will pay off for Thursday.

Wednesday 9th

Fixed wrapper ids.
First Remove click works. Need to keep track of the widget state so consecutive additions or removals work. Helped a lot to see how FileWidget does it.

Thursday 10th

Reading core Ajax actions. I am struggling to update the whole field collection item and preserving user input when Remove is clicked.

Will submit a patch with where I am up to so I can get further feedback.

Submitted a patch and implemented Tim’s suggestions https://www.drupal.org/node/2613584#comment-10657018. Pending tasks:

  • Fix “Add another item”
  • Fix “Remove” button for the parent field collection.
  • Test sorting.
  • Adding test coverage.

Friday 11th

Adam gave me a new issue to work on: https://www.drupal.org/node/2633310. Seems to be related with https://www.drupal.org/node/2633310.

Sat/Sun

Worked on another version of the patch where each Remove/Add button rebuilds the whole field collection widget.

Monday 14th to Wednesday 16th

Debugging errors when deleting nested field collections.

Thursday 17th

Finally got a deep understanding of the module. My patches for the following issues were committed into Field Collection module:


Now working on a follow up issue: https://www.drupal.org/node/2636198

At the scrum, Adam said that I will move on to Pathauto since the issues for Field Collection are fixed. Will talk to Kris Vanderwater on what should I work on.

Notes for Pathauto will be taken at +Drupal 8 Pathauto 

Friday the 18th

Adam told me that the product team created a new issue that they experience when saving nested field collections: empty items do pile up at the bottom on every save: https://www.drupal.org/node/2637704. Looking into it today.

Drupal 8 Pathauto

Thursday, December 17th

Hangout with Kris and Sasha
Kris says that Berdir (Sasha) worked no a new UI, but they both need Dave’s thumbs up on their work.

Dave said that he wants pathauto to use config entities. They have a hackpad with some notes at https://hackpad.com/Pathauto-8.x-Plan-ob3OeHCs5t3. Berdir’s work is at https://github.com/md-systems/pathauto/tree/pattern-config-entities-simplified-ui, which is the bleeding edge version of the module. Kris and Berdir need @Dave R to review their work there and pound whether it can be merged into Drupal.org or not yet.

There is an email thread on Pathauto that Berdir said that it was worth it for me to read.

Tasks (from the google doc) for repo https://github.com/juampynr/pathauto/tree/pattern-config-entities:
  •  Fix existing tests.
  • Test the UI in a multilingual context.
  • There is also an email with a few tasks and screnshots. Berdir will forward an email.

Friday the 18th


  • Tried to bulk generate paths for articles. Did not work:

Reading the module’s source code.

Friday the 25th

Stopped for a few days because there was a lot to read plus there was new feedback for Field Collection. I am back at fixing tests before reaching out to @Dave R to port this to Drupal.org.

Created the following pull requests:

md-systems/pathauto#104  install locale module to fix tests.

The issues caused by locale module are related to a core bug: https://www.drupal.org/node/2573975

Created a pull request to fix UI test md-systems/pathauto#105 

Done reviewing and fixing tests.

Done reading that long email between Berdir, Gabor, Kris and Angie, plus the Google Doc.

Reading existing issues at https://github.com/md-systems/pathauto/issues

Found a failing test which links to the core issue, which links to the ctools issue (https://www.drupal.org/node/2615444#comment-10697778)

Re-rolled patches for the Ctools issue, which is related with a core issue:
The above two are preventing us from running all Pathauto tests. We need these tests to pass before doing further development on the module.

Saturday the 26th

Berdir merged md-systems/pathauto#105, which fixes PathAutoUI tests.

Reviewing Pathauto tests. After applying patches https://www.drupal.org/node/2573975#comment-10697788 and https://www.drupal.org/node/2615444#comment-10697778, all tests pass except PathAutoUnitTest, which has a couple failures which I am working on now.

Realized that taxonomy term patterns aren’t working. Getting a 404 when opening one even though it exists. will debug, fix and cover with a test.

Created a pull request for one of the last two failing assertions md-systems/pathauto#107  plus an issue to continue debugging the other one: md-systems/pathauto#108 

Monday the 28th

Submitted a pull request to fix the last failure when running tests: 

Now testing the module manually to see if there are any unexpected bugs.

Manual testing
  • Create a pattern for articles. Generate content and verify the URLs.
  • Create a pattern for a taxonomy vocabulary. Add terms and test the URLs.
  • Edit the URL alias of a term. Test it.
  • Create an article and set a custom URL alias.
  • Change a pattern and bulk update it’s matching content.
  • Bulk delete patterns.

Findings during manual testing:

💥 When editing a taxonomy term the following URL fields are not under a fieldset as they are when editing a node. Also, there is a bit of missing JavaScript that disables the URL alias field when the “Generate automatic URL alias” checkbox is ON:
💥 After overriding an alias for a taxonomy term, we need to rebuild the URL cache. Otherwise, the View link takes to a 404 page:


Tuesday the 29th

Created an issue to work on an update path from 8.x-1.x to pattern-config-entities-simplified-ui:


Working on it now.

💥 At 8.x-1.x, the batch job to delete content, terms and users got stuck in an infinite loop. Need to test if this happens at pattern-config-entities-simplified-ui.

Making good progress. Created pull request  md-systems/pathauto#111. Pending to process forum patterns plus language-dependent patterns.

Wednesday 30th

Updated the pull request with the database update:  md-systems/pathauto#111 

While Berdir reviews it (and hopefully merges it), I will look at testing patterns in a multilingual site, which is the other requirement in order to merge his branch onto 8.x-1.x.

Adam asked for the status of Token as it is in Alpha and is needed by Pathauto:

<balsama> juampynr: I meant to ask about token this morning... what's the status of token as it relates to pathauto. Is the alpha version sufficient, or do we really need a stable release? (I guess that depends on what is between this alpha and a stable release, which maybe berdir could answer?)
<juampynr> balsama, alpha works fine. I could dig to see how far is alpha from reaching a stable release. Would you like me to balsama?
<balsama> juampynr: we probably should. Basically need to know if there are any expected API changes or anything that might unexpectedly affect pathauto planned
<juampynr> both metatag and pathauto modules are using token, and it is mainly because core does not include that fancy token browser
<juampynr> cool, I will look into it balsama
<berdir> balsama: can't say what you need specifically, that depends on a lot on your needs for specific tokens. e.g., there are currently only very basic field tokens, that just render a field. works quite fine for basic things, but there are some very common features that don't work yet out of the box (like building a pathauto pattern for a term reference field and its parents)
<balsama> berdir: thanks. that makes sense.
* timplunkettAFK is now known as timplunkett
<juampynr> berdir, is there a roadmap of pending things to implement for token? Should I look at the issue queue?
<berdir> balsama: the other part is the token browser. the current one kind of works, but is very ugly, with the same limitations as 7.x (in short, it explodes completely when you have too many tokens/fields). if that's something you intend to expose your customers, then you might want to look into improving the UI
<berdir> juampynr: check the issue queue. there is no road map right now but there are a few major issues for the bigger 8.x specific topics. hussainweb is currently very active and provides a a lot of patches, mostly cleanup/refactoring at the moment. I'm limiting myself on reviewing/testing/committing patches from others at the moment
<juampynr> excellent, thanks berdir 
<balsama> berdir: Ok, makes sense. I'll be in touch if have a need and a resource to help. Thanks.

Need to figure out the status of the module to make sure that there won’t be API changes.

Later on, berdir suggested to add testing coverage for multilingual/translated entities, especially in combination with bulk generate/delete and creating such patterns in the UI and making sure they work.

Thrusday the 31st

Found an error when testing multilingual patterns. Created an issue at  md-systems/pathauto#112. Debugging… Fixed at md-systems/pathauto#111.

Berdir asked for the following test for multilingual patterns:

1. set up a site with 2 languages a node type and content translation.
2. create two patterns, for both languages.
3. create a node and a translation for it, assert aliases.
4. bulk delete and bulk generate, making sure that aliases are deleted and re-created for both translations

Created an issue for the above requirement: md-systems/pathauto#113.

@krisvanderwater1 committed the Ctools patch (https://www.drupal.org/project/ctools), while it looks like the core patch needs some refinements to be ready to be committed (https://www.drupal.org/node/2573975#comment-10709152).
Berdir has created a pull request to merge his branch on top of 8.x-1.x (md-systems/pathauto: Pull Request #115).
While the above progresses, I will continue working in adding tests for multilingual patterns (md-systems/pathauto: Issue #113).

Sunday the 3rd

Added test for language patterns: md-systems/pathauto#118 

Found that aliases for translated content are not created on bulk update. Will debug this tomorrow.

Monday the 4th

Fixed bug with translations on bulk update at md-systems/pathauto#118. Currently debugging a failing assertion.

Fixed tests for Pathauto: md-systems/pathauto: Pull Request #118. Waiting for Berdir for another review.

Moving on to see how far is Token module from an stable release. I will take notes at +Token .

Tuesday/Wednesday 5th and 6th

Berdir merged my pull request with multilingual fixes and tests.

I submitted a few patches for the core issue. It’s progressing well: https://www.drupal.org/node/2573975

Looks like the above core issue is derailing a bit

Thursday the 7th

Investigated how core uses function_exists() to see if there were any potential failures in tests like the one we saw with locale_get_plural(). Did not find anything risky so hopefully with my research core devs may commit my patch. https://www.drupal.org/node/2573975#comment-10726422

Drupal 8 Token

Notes on my progress with Token module

Things to fix at Token module:

  • field tokens > just a few of them: add more. This one does not work, for example: building a pathauto pattern for a term reference field and its parents).
  • generate tokens based on typed data << reuse berdir’s work on typed data.
  • token browser > ugly, explodes when there are many tokens. Look at D7’s.

Grouping fields by topic based on the above:

Field token support

Token tree improvements

Additional findings

function token_render_array(array $array, array $options = array() and function token_render_array_value($value, array $options = array()) have the following in their docblock:

Do not use this function yet. Its API has not been finalized.

Need to check with the module maintainers on the above statement.

Thursday the 7th

Looking at Field token support issues.

https://www.drupal.org/node/2497247 - Field tokens in correct language seems to be in the right track. There is already someone working on it.

New issue: there seems to be a problem with token view modes, but I need further details to debug it https://www.drupal.org/node/2430821#comment-10726786 (Token view modes are only created for entity types that exist when token is installed).

Looking at https://www.drupal.org/node/2430827 (Improve field support and add test coverage). This is a meta issue that leads to the two main issues for field token support:


The two issues above have been left alone. I will work on them.

While browsing issues, Berdir said that there is one remaining issue from @Dave R’s wishlist: 
md-systems/pathauto#124. If I get stuck with Token, I will work on it.

Berdir said that the top priority before fixing anything on field tokens is to expand the existing test coverage by leveraging Dawehner’s patch in a new issue.

Friday the 8th

Working on https://www.drupal.org/node/2646316, which adds tests for field tokens.

Testing adding different field types to see how their tokens get rendered.

Monday the 11th

Implemented all the feedback tips for the field token tests: https://www.drupal.org/node/2646316

Sent a reminder to Dave about his review on Pathauto.

Berdir merged my patch adding tests for field tokens:https://www.drupal.org/node/2646316#comment-10737336.
Moving on to a follow up (https://www.drupal.org/node/2648180) >> submitted a patch.

While running tests for the above, I discovered that core tests fail in Token, so I created another issue and patch https://www.drupal.org/node/2648492

Tuesday the 12th

Things are moving very fast. There is an API change for the tree builder that simplifies the developer experience. It affects Metatag module (submitted a fix at https://www.drupal.org/node/2648752#comment-10739968). Pathauto’s token tree is correct.

Peer reviewed https://www.drupal.org/node/2621598#comment-10740338. Suggested an alternative patch.

Starting with https://www.drupal.org/node/2497247 (Field tokens in correct language)

Wednesday the 13th

https://www.drupal.org/node/2497247 does not seem to be a bug. Asked for more feedback.

Got feedback for https://www.drupal.org/node/2497247#comment-10743814. Working on a fix.

Scrum notes
Working on two issues:

Multilingual field tokens https://www.drupal.org/node/2497247
Tokens for field properties https://www.drupal.org/node/2621598

Field tokens are getting better. There is basic support and the two above issues will cover a good amount of use cases.
Tree theming has been simplified. Pending to improve performance but field tokens has a higher priority.

Only 15 active issues. Issue queue very active.

Asked for guidance at Multilingual field tokens as I got stuck https://www.drupal.org/node/2497247#comment-10745154

Thursday the 14th

Adam reported an issue with aphostrophes in Metatag module: https://trello.com/c/pSKvRQFw/51-apostrophe-s-in-meta-tags. I have two weeks to fix it.

Looks like the above issue is a “works as expected”. Waiting for confirmation https://www.drupal.org/node/2649592#comment-10747836.

As for Token module:
Gave further feedback and help in the multilingual tokens issue: https://www.drupal.org/node/2497247

Reviewed “Attempt to load dialog window using AJAX system https://www.drupal.org/node/1925688”. Looks like there is nothing to do there.

Re-rolled a patch for supporting tokens of base fields automatically https://www.drupal.org/node/2493567

Issue status for Token module (copied from +Drupal 8 module port: Field token support )

Field token support

Under review.
Will retake it today.
Some people working on it already.
Meta issue. Will get closed when field issues are solved.
Being reviewed

Token tree improvements


Scrum

For the metatag quote issue (https://www.drupal.org/node/2649592) Kris suggested to check that Metatag module is using \Drupal\Core\Template\Attribute to render tags. This will ensure we are not reinventing the wheel when rendering tags (which could explain the weird escaping). 

Adam asked me to review the list of modules needing a maintainer so I can start working on them.

Adam wants me to evaluate Workbench Moderation: client wants a demo. Adam wants the module’s core logic to be solid. Should be possible to manage revisions and use scheduling. Ted Bowman will send me an email with details.

Friday the 15h

New priorities:
  1. Evaluate Workbench Moderation and help both Ted and Crell with it. Client needs basic moderation, revisioning and scheduling. 
  1. Check that Metatag tags are rendered using \Drupal\Core\Template\Attribute.
  1. Help on redirect module so it moves to Drupal.org.
  1. Continue giving support at Token, Pathauto and Metatag.

Workbench Moderation review
Client contact is Alex Knoll. Will meet with him to fetch the list of requirements that I need to check that the module meets.


Ted told me that for Scheduled Updates I could start by looking at https://www.drupal.org/node/2643934. He created a sample module to reproduce it: https://github.com/tedbow/d8_form_debug.

Looking at tests. They all pass 👍 .

Meeting with Alex Knoll:
Client pushing Drupal 8.

He is working in the next sprint in the workflow. He has used 7’s workflow and wbm. He is writing user stories with client. Told Adam that he has not seen the D8 version of WBM. We should start by doing a walkthrough:

  • States attributable to roles.
  • different roles can have different permissions for each state:
  1. some can edit,
  1. some can move it to another state
  1. other role can review it
  1. then other role can be the final review.
  1. Then it comes scheduling: you can put a publishing date in a draft mode.
  1. The final guy can review and approve and put it ready for publish until the publishing date.
  • Editors should see the content assign to them: pending, ready, etc. Like Workbench does. Can be built manually, make sure that Views can access to it.
  • Notifications. Nice to have. We should be able to hook into transitions.
  • Transition management, permission management.
  • There will be a content creator role for each content type (10 of them). Matching 10 approval roles. 10 Previewer (can preview but not approve).

Meeting with Ted Bowman
Scheduled updates schedules updates for fields.

UI walkthrough:

Scheduled update types | Bundle updates.

Add an update type: Title updater.

  select content entity.
  they have update runners: chose embedded update, there is a workbench moderation runner.
  you can choose a user to use for the update.
  then, if you chose embedded, you configure the field that lets user to activate this update.
  
Then we go to an article: the field is there.

Monday the 18th

Evaluating the following requirements for Workbench Moderation (copied from notes above from a meeting with Alex Knoll):

Goal: there will be a content creator role for each content type (10 of them) along with 10 matching approval roles plus 10 matching previewer roles (can preview but not approve).

Here is a list of requirements on top of the above:

  • States attributable to roles.
  • Different roles can have different permissions for each state:
  • Some roles can edit on a certain state.
  • 👎 Roles need the “edit content” permission in order to change the moderation state of a node. We could:
  • a) Let these roles to view the node and see a button at the bottom to transition its state to Reviewed. This would involve custom code.
  • b) Disable all fields in the node edit form. I created a simple module to achieve this but it needs further work.
  • I feel that not letting roles to edit the content may be counter productive for the editorial process because there are fields such as the publishing date or the metatags that are visible only at the Edit form. Giving these roles a chance to make small adjustments while they review would save back and forth reviews. Besides, their edits will be marked as a new revision so the role in charge of publishing will see them.
  • 💥 Bug: can’t see revisions of an article. Listing is empty.
  • Some roles can only move it to another state.
  • Some roles can review it.
  • What does this action imply? Is it just to read the content? If so, what would be the action after reading the content?
  • There would be another role who would give the final review, who can review and either publish the content straight away or schedule its publication.
  • 👎 Currently not possible. I tried setting up scheduled_updates module without luck. Perhaps Revision Scheduler or State Machine fit better in this context. Here is a screenshot of a past implementation that we did in Drupal 7:


  • A “tentative” publication date can be set on a piece of content when it is in Draft mode.
  • 👎 Currently not possible. I tried setting up scheduled_updates module without luck.
  • Editors should see the content pending to be reviewed. We need to check that this data is available to Views in order to build the listings.
      👎 There is no Views integration with states, so we can’t filter content by “Needs review”.
  • Notifications. Nice to have. We should be able to hook into transitions.
👎 There is no event/hook triggered at EntityModerationForm::submitForm().

Sent the above notes in an email to Adam and Alex. Adam sent a meeting invitation with a roadmap for Worflow and Preview. Questions after reading the document:

  • What is a workspace?

Scrum notes
Create a list of tasks out of the above findings on Workbench Moderation, then wait for Alex’s feedback on the questions that I raised there.

Roadmap meeting notes

Again: transform the above into requirements.

Larry says that letting roles to transition may be possible.

Q: What is a workspace?

Q: Is Scheduled Updates the go to module to add Scheduling to WBM?

Ted mentions his distribution to test SU (Scheduled Updates). Need to check it out.

Larry says that the views filter can be an entity reference field of type WBM. Create an issue. This may be Workbench module. Check it out.

Ted asks who should be the user that publishes an article.

Did a hangout with Ted on a deeper look at Scheduled Updates module.

Tuesday the 19th

Worked on WBM’s Views integration. Created https://www.drupal.org/node/2652786.

Now working on a module that leverages SU by providing a field that shows a scheduled publishing date.

Created a new issue for creating a field to schedule a publication: https://www.drupal.org/node/2652158


Meeting with Ted and Phenaproxima (SU UX review)
Reviewed the module and ways to make it easy to schedule a publication.

Wednesday the 20th

Gave Alex further feedback on requirements. We are getting close.

Working on the Views filter for WBM: https://www.drupal.org/node/2652786. Submitted a new patch that works for all revisionable entity types.

Thrusday the 21th

TODO
It did. Re-rolled.
Look at a core solution for this.
  • Debug that bug on core when adding filter.
Core issue. There is a patch that works: https://www.drupal.org/node/2248223#comment-10771240
  • Make core to discover tests at modules/contrib/.
There is an issue in core. Too much talking. https://www.drupal.org/node/2499239


  • See if there is a missing setting at BaseFieldInfo.php (WBM).
  • See if we need a new relationship. Check how views add entityreference fields.

Workflow meeting
workflow? workbench moderation? what about state machine?

TODO: ask Alex about multilingual support for WBM and Scheduled Updates.

They want to do multiversion for the elections site. They call a group of content entities a Workspace. They want to be able to publish a workspace at once.

Want to give authors the ability to do whatever they want. Gonna be hard but they want to work on it. Even a certain set of functionality, they want it to be something that can grow.

They need an upgrade path from WBM to Multiversion: talk to Karen and possibly Eaton about this. Acquia wants more people on this. They may want to join us in a meeting.

Friday the 22nd

Adam told me that the origin of the Workflow team was this post in WBM’s issue queue. In there, four different tiers of moderation are described.

  • Submitted core patch.
Created https://www.drupal.org/node/2654908. Positive feedback. Adding tests.
  • Test multilingual support for WBM and SU.
Found a bug: https://www.drupal.org/node/2654972. Added a test. Debugging code now.
  • Test multiversion module.

Saturday the 23rh

Monday the 25th


Workflow meeting
Adam added a sample roadmap 

Dixon joined. Giving an updates on multiversion. They are still laying out the foundation. No UI yet. Goal is to build something like CPS module. Tim seems to be the leader on Multiversion, while Dixon will give guidance. Larry will help on overall architecture.

Tim acknowledges that multiversion may not be needed: We are managing revisions within workspaces.

Project name: cps is taken and unresponsive. Not sure yet what name to use.

Goal is clear now: they want to build CPS, but more flexible and solid.

Lullabot + Acquia meeting
workbench states turned into workbench moderation in Drupal 8.

Election Night Scenario AKA CPS is a workflow module where there is a “workspace” which priviledged users can see.

Karen says that what we now call workspace, it is called Collection in Drupal 7.

Eaton suggests not going too big with such a solution. Adam says that his role is to launch a distribution called Lightning which covers 80% of their use cases. Says that they don’t want to create something generic.

Karen mentions that has a client who needs a workflow system (Turner).

Tuesday the 26th

Core magically fixed the error when translating moderated content.

Submitted a patch to fix warnings on WBM https://www.drupal.org/node/2645516 related with state transitions.

Wednesday the 27th

Thursday the 28th

  • Review Redirect module.
  • Simplify scheduling WBM transitions.

Workflow meeting
Seems that Eric Duran may help on SPS.
Adam posted a roadmap for SPS.

Merge:
Prod workspace with content
two dev workspaces, both want to push

=======

TODO:

Starting to review Redirect module

Seems that redirects are stored in custom table. We could move them to config entities. However, there is a Redirect.php class. Weird, because it is an entity of type ContentEntityBase instead of ConfigEntityBase.

Tests pass. First impression is positive. Created a small PR fixing typos and missing spacing: https://github.com/md-systems/redirect/pull/80.

I will start now looking at the existing issues and pull requests to see if there is anything critical there.

Submitted a fix for an open issue when creating redirections https://github.com/md-systems/redirect/issues/79.

Redirect:
  • Basic redirection seems to work.
  • Tests pass.

Got feedback for WBM on both of my patches (https://www.drupal.org/node/2654972#comment-10796742 and https://www.drupal.org/node/2657914). Will work on them too.

Friday the 29th

Submitted another patch with the suggested feedback.
  • Redirect - review open issues.