If you override the meta tags for a specific object, e.g. a node, there's no clear way to revert the changes to their respective defaults. Some ideas:

  • Display the default after the description,
  • Add a per-field button to reset the field to the default,
  • Provide a UX hint on each field to indicate which fields are at their default values in addition to the summary provided in the vertical tab.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dave Reid’s picture

I would say we add a button which changes the fields to their default values. We could probably store the defaults inside a data attribute, so something like <input type="text" data-metatag-default="[node:title]" /> which uses JS to reset those values. Not sure how it would quite work with more complex things like checkboxes, but it could be a start.

DamienMcKenna’s picture

tomogden’s picture

I think we are overlooking a glaring issue, which may be the major motivation to restoring defaults. That is, the module *does not allow you* to restore your settings to the defaults. In fact, if I add metadata to the settings fields and then empty them again, the module instead sets the respective values to "empty". The only way to restore default settings is to reset the database table.

The Logic
If I enter a value in the field, then I expect it to override the parent object (which is does). If I delete that value to leave the field empty again, then I would expect it to stop overriding the parent.

Unfortunately, the module doesn't do that. When you empty a field, it saves an empty value in the database, and then it uses that as the override instead. This seems like unexpected behavior for most users, with or without a button.

The only possible use case for saving an empty value provides is if you really want it to be "empty" for that object and to override the parent, but this seems very unusual.

It would be so much easier to:
1) Stop the module from saving and using empty values.
2) Institute an [empty] token for those special cases where someone wants less metadata.

Once this unexpected behavior is fixed, resetting the metatags to default may not be such a priority.

DamienMcKenna’s picture

@tomogden: Except that the module was built with the notion that you might want to remove a meta tag from a specific page, which we can't do if we have the logic that "an empty value == use the default". Personally I'd like to add little checkboxes to control whether the values are changed at all, but I don't know if / when I'll have time to do that.

tomogden’s picture

@DamienMcKenna,

you might want to remove a meta tag from a specific page

Won't the [empty] token take care of that? It just isn't logical that a user can return a field to its original state, but the system doesn't recognize that.

Murz’s picture

Won't the [empty] token take care of that?

We can use <none> placeholder for empty values, like in Drupal Block title field, here is Block form field description: Override the default title for the block. Use !placeholder to display no title, or leave blank to use the default block title.

Gomez_in_the_South’s picture

It would be great to have this implemented as I agree that the current behaviour isn't intuitive.

One workaround to remove it is to enter the value that is the same as its parent (in terms of inheritance). In this case it will then forget the metatag setting for that field, and inherit it instead.

xaris.tsimpouris’s picture

I agree with tomogden. In the meantime I use the idea of Gomez_in_the_South.

frakke’s picture

/**
 * Implements hook_metatag_presave().
 */
function foo_settings_metatag_presave(&$new_metatags, $entity_type, $entity_id, $revision_id, $langcode) {
	// Remove empty strings so that the default metatag rules can apply.
	$new_metatags = array_filter($new_metatags, function ($value) {
		return $value['value'] !== '';
	});
}
DamienMcKenna’s picture

What I'd really like is a checkbox on each tag to control whether the value is to be overridden, something like this:
Initial state
When you click the checkbox it would open a text field underneath it, like this:
Expanded state

We can work on refining the UI, but I think this would ultimately be the best approach.

Anybody’s picture

Just for the records, if this shouldn't work well or lead to further complications, feel free to reopen #3272202: Add <none> placeholder to clear / unset inherited value with a <none> option to unset inherited values. Overriding with a value is already the default.
For better UX to show the default, I suggested showing the inherited value as placeholder in the field in #2936826: Inherit parent metatags as placeholder in override forms.

I'm fine with every solution, but we definitely need a way to solve cases like this: #3247275: Remove canonical for 404 and 403 pages

DamienMcKenna’s picture

Looking at the current form, we have three elements:
The current Metatag UI showing the Page Title meta tag

  • Meta tag name
  • Meta tag field
  • Meta tag description

If we were to make the text field hidden by default it wouldn't make sense to have that verbose description still show up by default.

We could try something like this:
Idea #2, default value

Clicking the checkbox would then show the field and the description:
Idea #2 expanded to show the text field and description

Note: the text field would include the default value, my mockup tool doesn't let me fill in values into text field widgets X-)

DamienMcKenna’s picture

Version: 7.x-1.x-dev » 8.x-1.x-dev
Status: Active » Needs review
FileSize
1.68 KB

This is the sort of UI change I'm thinking of. Note that none of the data logic has been updated to match this, right now it just has the form field change. It also doesn't work with multi-value forms, like Robots.

DamienMcKenna’s picture

Slightly improved version of #13.

This is what it looks like initially:
Idea #2 refined - all of the meta tags using their default values

When you click on a checkbox it shows this:
Idea #2 refined - one of the meta tag overridden, the others using their default values

DamienMcKenna’s picture

#14 also includes some usability and accessibility help - there's a "title" attribute on the checkbox that says "Click to override the default value" while there's also an aria-label attribute that says "Override the default value of the '@label' tag".

Status: Needs review » Needs work

The last submitted patch, 14: metatag-n1798984-14.patch, failed testing. View results

Anybody’s picture

Very very nice @DamienMcKenna!!

From a UX and users perspective, the only thing I wouldn't be 100% sure about is, what happens if the value is left empty. One might assume that the meta tag is rendered with an empty string then.

I know this discussion is the same for the already existing UI where empty fields means metatag not being output, but perhaps we could use this chance to also point this out more clearly.

I just read the description in the head of the pages (master and edit):

  • admin/config/search/metatag
  • admin/config/search/metatag/global

and this is not mentioned.

Writing this, I still think it's not 100%self-explaning, but might be a separate issue (sorry your mockup lead me to this point ;))
So what do you think about using the placeholder attribute (which is only output if empty) to indicate that?

Something like "Unused"

For all fields without input of course. Base and override!
Perhaps you could add that to your next screenshot? Or better create a separate issue?

Sorry for being a bit off-topic. The rest is perfect.

DamienMcKenna’s picture

My idea is that if you override a value and then leave it blank it would not output that tag.

This might require a 2.x branch due to the possible API changes necessary.

thejimbirch’s picture

If you override a value and then leave it blank, shouldn't the parent then be used and it would only be blank if the parent didn't have a default?

Thinking Article up to Content up to Global, etc...

The UX of this is nice. Great thinking.

DamienMcKenna’s picture

The intention here is to be specific - if you are overriding the parent value then the parent value becomes irrelevant, the only thing output would be exactly what is in this form.

DamienMcKenna’s picture

This will be part of Metatag v2.

DamienMcKenna’s picture

Title: No easy/clear way to revert meta tags on an object to their defaults » Improve meta tag form to clearly distinguish between overriding or reverting the default value
DamienMcKenna’s picture

Title: Improve meta tag form to clearly distinguish between overriding or reverting the default value » Improve meta tag form to clearly distinguish between overriding or reverting the default value (D9)
DamienMcKenna’s picture

Another idea..

What if we used AJAX to load the text fields when the person wanted to override the string? Would that help performance due to the lack of tons of Form API state handlers, and help resolve problems from #3057523? Or would the AJAX interactions just cause more performance problems?

DamienMcKenna’s picture

Berdir suggested in #3057523-89: Content forms are painfully slow if multiple sub-modules are enabled that #24 would end up being slower and could be a larger performance hog, because FormAPI regenerates the entire form for AJAX actions, not just a part of it.

DamienMcKenna’s picture

Status: Needs work » Postponed
Parent issue: #3272774: Plan for Metatag 2.0.0 »

In the interest of getting 2.0 sooner, this will be done after 2.0 is released.

wilco’s picture

Hey Folks,

Love what this patch is proposing. Thankfully, the site I'm working with doesn't have a huge array of metatags, so performance is good. One little thing I noticed though was a JS bug throwing in my browser around certain metatag field labels vs naming which would cause the checkbox mechanism to fail:

['metatag-' . $this->name() . '-override']

The line above could resolve to a naming convention that looks like this: metatag-profile:first_name-overrider which as we all know is not a proper JS identifier. So, the front end would throw an error on the first instance of this and fail from that point on.

I believe the fix is to use the id of the tag rather then its name. This patch attempts to solve this issue.

wilco’s picture

Version: 8.x-1.x-dev » 8.x-1.22
FileSize
15.82 KB

I know development has mostly moved to version 2.x of the module and that this will likely not get any attention for a while, but I did run into some interesting problems with the Override / Form elements when saving my nodes with the patches in #14 and #27. Basically, when generating the output, tons of failures started happening as the override checkbox was getting involved in the processing.

While tracking through this problem I also noticed another issue: it was really hard to extend tags with extra field attributes unless using hook_attachment_alter() which I was not keen on doing for the large number of mods I was putting into place.

Because of the necessity to manipulate tags in a more "Front End" centric way and the addition of the Override checkbox functionality was impacting output and form creation, I looked to modify how metatag's processTagValue() method worked as well as a variety of other methods that were encapsulated in the problems I ran into. For processTagValue(), instaed of having it placed against the MetatagManager, I moved it into the MetaNameBase class. This way we can leverage the processing via the Tag object itself. As well, it had a bonus affect of allowing some configuration components to flow into the tags so I could do some more complicated computations with them. I brought in an array manipulator and flattener which controls better how forms and output leverage the Override / Form elements. As well as some minor tweaks to ensure conventions were adhered to.

The patch I am submitting is trying to solve getting these things factored in a more flexible way. I'm happy to discuss better approaches to anything I've suggested. I'm hoping this leads to a more robust version 2.x

Please note: I made this mod against 1.22 as this was what was working for me. the dev branch was proving to throw some more errors I didn't want to hunt down as of yet. Post March, I should have some time to integrate this into the dev branch.

wilco’s picture

In the interest of better separation of concerns, I'm going to break out the changes in my patch #28 into another ticket. The combination of this and the override was leading down some rabbit holes.

DamienMcKenna’s picture

Version: 8.x-1.22 » 2.0.x-dev
Status: Postponed » Needs work

This could be worked on again.