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.
Create GitHub repository.
Create issues for the above list of requirements.
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.
If there is code to reuse, adjust it and add test coverage for it.
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().
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.
Drupal 8's Metatag
Acquia’s requirements by 12/4/2015
Roadmap 🚗
Tuesday 17th
Wednesday 18th
Proposed architecture to manage tags