Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Work in progress on my brainstorming for simplifying the UI
Comment | File | Size | Author |
---|---|---|---|
#6 | 3. Meta Tags: Defaults.png | 33.01 KB | Dave Reid |
Comments
Comment #1
DamienMcKennaMy idea:
This is very similar to a plan I had built for a rewrite of the Omniture module at Bonnier, before I left in May.
Comment #2
Dave Reidhook_metatag_info() and hook_metatag_info_alter()
I think your comments on term pages and node pages map really well to the field API in D7, but the problem is we don't easily have CCK fields on terms in D6. One plus for using the CCK/Field architecture is we get built-in handling for different types of display (page vs teaser vs print vs RSS).
Comment #3
DamienMcKennaAgreed on the hooks.
Given the differences between D6 and D7, might it just make sense to maintain Nodewords as the legacy D6 application and Metatags as the clean D7 version, and build a migration path between the two? I really don't want to rewrite everything that Nodewords already has for a version of Drupal that can't really do everything we'd like it to (i.e. D6), more just clean it up.
That said, if we do follow the legacy-clean sibling-modules path then I think we should work together on building an overall architecture and then leave the individual implementations separate, i.e. fields for D7 but custom data structures for D6.
Comment #4
andypostWith help of page_alter we have unique page-entity object and router items as bundles. Allowing meta-tag as field we could gather metatags from page, page+region - also we could use text and date field-widgets for editing
EDIT: now we have #796658: UI for field formatter settings
Comment #5
BenK CreditAttribution: BenK commentedSubscribing...
Comment #6
Dave ReidHere's how I've started brainstorming:
The schema
Table: {metatag_default} or {metatag_config}
Description: Stores all the 'default' meta tags for entities/bundles and their settings/options. Note that we will want to make this table exportable since it is configuration.
Fields:
Table: {metatag_data}
Description: Stores the actual meta tags for individual entities. Should not be exportable since it is not configuration.
Fields:
The UI
There will be one default admin screen to select which meta tags are enabled. A second screen is a table listing of {metatag_default/config} where admins can easily add new default meta tags, edit and delete existing defaults, and filter by entity or meta tag name.
As I just typed this, what might be better is to merge selecting which meta tags are enabled on the site into this screen as well. To enable a new meta tag, you would 'Add a new meta tag', and select the entity/bundle you would want (or use the catch-all values to apply the meta tag globally).
Comment #7
DamienMcKennaSounds good.
What are your thoughts on two other things:
Comment #8
Dave ReidGoing with D7 convention, we would have hook_metatag_info()/hook_metatag_info_alter() to define the actual meta tags. Suggesting a sane default value for each entity type seems good, but thats something for later on. With the UI when people add a meta tag they'd have to specify a default anyway.
By default the meta tag 'value' would be exposed as a textfield, but we'd want each metatag to also be able to provide a 'form callback' to display its own custom FAPI stuff if it needs more than a textfield, i.e. the 'robots' meta tag should have a select field with a few choices. Basically provide a sane default UI but allow the implementing modules to have freedom to do whatever crazy crap they need to do. :)
I'm not sure exactly yet about the UI for individual entities. I'm playing with it now.
Comment #9
Dave ReidI think we might need to set up a wiki page for this plan. Anyone can look at the current UI mockups at http://gomockingbird.com/mockingbird/index.html?project=973a42310950a6f6...
Comment #10
andypostI think that metatags should be a field that could be attached to nodes/user/vocabularies - btw we already have UI for assign, defaults for each entity could be assigned in field settings. With this approach we need UI for allowed metatags list and UI for custom pages (maybe context links could help).
{metatag_data} should be used only for custom pages, for all other entities we have field storage.
Comment #11
MixologicSince this is an offshoot/proper rewrite of the nodewords module, I'd like to make an architectural suggestion while you are still in the drawing board phase.
I may be coming at this with SEO blinders on, but it seems that attaching meta tags to entities (nodes, taxonomy terms, etc) is a murky abstraction when the purpose of the meta tag is to provide information to search engines, robots, and browsers as to the nature of the resource that is located at a particular URL
So from a data storage standpoint would the data model be better if the meta tags were associated with a URL in the system, and not with the entities they are trying to describe? Im thinking about panels and views specifically and how a node is no longer the only way to access content. One node may be part of a page, but it's sequestered in a panel, or there may be multiple nodes on a page, or there may be *no* nodes on a page and it's simply the output of a view. But the output of that view may be highly dependent upon arguments which may drastically alter the meta description that you would want to display. For example the meta tags for "http://mysite.com/shopping/pets/cat-toys/laser-pointers" should always be the same, regardless of whether that is a url alias to a node, or whether that is a view that takes pets,cat-toys, and laser-pointers as arguments. Either way external visitors should be able to programatically determine that "this is a page about laser pointers for cats". Additionally this would allow assigning meta tags to other as yet undefined resources in drupal, (Im thinking things like RESTful implementations using the Services module, or any module that uses hook_menu to define a path in drupal).
On the other hand, I also recognize that most of the content being generated on sites happens at the node level (user pages being a notable exception), so from a useability perspective it makes sense to enter the meta tag data that pertains to your content on the same form that you use enter your content. (and on taxonomy term pages, vocabulary pages, etc) I would just like to see it somewhere near the path settings, and have an additional administrative screen to add/input modify any other path in the system. (like this module: http://drupal.org/project/nodewords_pagetitle, or this one: http://drupal.org/project/nodewords_bypath).
I guess what Im suggesting is the following:
Table: {metatag_data}
Description: Stores the actual meta tags for individual entities. Should not be exportable since it is not configuration.
Fields:
Anyhow, thoughts?
Comment #12
Dave ReidSorry, but as I explained in #864404: Make 'Meta tag' fields to get a 7.x-1.x out the door, I'm not going to be using the Field API. It doesn't seem mature enough to handle our use case and I'm not keen on coding it. Especially if we want to do things like make meta tag configurations and defaults exportable.
Comment #13
Dave ReidUpdated mockups provided at https://drupal.mybalsamiq.com/projects/metatags/story
Comment #14
Dave Reid