The plugin configurations, whether a specific meta tag automatically handles multiple values, or converts URLs to absolute, etc, cannot be edited through the UI.
That said, if a meta tag plugin has the wrong definition, please open an issue an we can change it.
Please update the MR to allow either ^2.5 or ^3. Thank you.
Configuration -> Search and metadata -> Metatag
Done: https://www.drupal.org/project/backup_migrate/releases/5.1.0 →
Thanks everyone!
I think the two email fields could be left as a string, to allow for multiple values, local-only usernames, etc:
notify_success_email:
type: email
i.e. only admins should be setting that, so let's leave it more open.
Yeah, while I'd love to include this, I don't know why it's failing on gitlab but works locally for me too.
I committed the logo files to the repo, which is a rendition of the existing logo file.
We can discuss updating the project's logo in a separate issue.
Thanks everyone.
Let's use this to improve the documentation.
Done: https://www.drupal.org/project/exif/releases/8.x-2.6 →
Thanks Nick!
damienmckenna → created an issue.
damienmckenna → created an issue.
damienmckenna → created an issue.
I can confirm that MR 3329621-fix-coding-standards-2.x solves some coding errors I was setting in 2.0.11, thank you.
Did you check the module's documentation?
https://www.drupal.org/docs/contributed-modules/metatag →
https://www.drupal.org/docs/contributed-modules/metatag/standard-usage-s... →
To adjust metatags for a specific entity, the Metatag field must be added first. Follow these steps:
1. Go to the "Manage fields" of the entity type.
2. Select "Meta tags" from the "Add a new field" selector.
3. Fill in a label for the field, e.g. "Meta tags", and set an appropriate machine name, e.g. "meta_tags".
4. Click the "Save and continue" button.
5. If the site supports multiple languages, and translations have been enabled for this entity, select "Users may translate this field" to use Drupal's translation system.
The included README.md file also says this.
Is that enough, or is it missing any details that would be useful? Or could the wording be improved? I'm happy to improve it.
Thank you.
Should this be a higher priority?
Bumping this to major as it affects this basic functionality from working as expected.
IMHO if you're building a site now it's worth starting with v2 and get used to its (limited) changes, rather than having to deal with it later.
I'm glad you were able to work out a solution.
Let's turn this into a documentation task so others can be aware of the problem.
Thank you for providing that, I ran into it on a site that was using 2.0.x but when it went away when I upgraded to 2.1.x I thought I had just borked up a patch locally.
We'll get this out in a new release so the 2.0.x branch can be stable again.
Definitely need to add more test coverage to cover more scenarios, as something's not quite right.
I can confirm that in 3.0.0-beta3 the modules work together as expected.
After looking through all of the facet options, it turns out that all you have to do is uncheck the "Hide facet when facet source is not rendered" option.
damienmckenna → created an issue.
damienmckenna → created an issue.
The current documentation file (in the _documentation directory) is also out of date and needs to be updated.
What you need to do is:
* Open the "Processors" settings page of the index you want to add the glossary to.
* Enable the "Glossary processor" processor.
* In the "Processor settings" section, open the "Glossary processor" tab and enable the field you want to use for the glossary.
* Save the index.
* Add a facet to the view or Search API Page that points to the "Glossary AZ" field that corresponds to the field above.
* Set the facet to use "Glossary AZ" widget.
* Work through all of the options that include "Glossary" in their name, enable the ones that you want.
* Save the facet.
* In the block layout settings, use the "Place block" option to open the block selection, and add the glossary facet you created above; adjust the block visibility settings as necessary.
I was fumbling in the dark a bit, but this seems to work.
Ran into this today, the workaround was to disable the drag UI and just edit the weights manually.
Marking the existing work as RTBC as it works really well.
While testing the latest MR it gave an error that dynamic properties was deprecated, so adding the $adminCache property resolves the error.
I would suggest creating a follow-on issue to rework some of the logic to properly use DI for \Drupal::cache(), and some of the other things that are loaded via services.
damienmckenna → made their first commit to this issue’s fork.
damienmckenna → created an issue.
damienmckenna → created an issue.
damienmckenna → created an issue.
damienmckenna → created an issue. See original summary → .
Please don't mark something RTBC if you haven't checked the test pipeline, because unfortunately these changes broke a lot of tests. Also, it seems to have added a cspell issue.
Please try naming the field something different, e.g. "meta_tags", see if that works. If it ends up being a compatibility issue we can add a note to the docs and via hook_requirements().
How did you create the field without the typical "field_" prefix? I wonder if there's a collision happening somehow?
This has been completed in the D11 issue.
Thank you for creating this issue.
Test coverage to confirm the backup works is 100% the way to go.
I'm sorry the module hasn't been working for you. Please help us make it better by testing the current dev release and reporting issues that show up. Thank you.
Going to give it a few days for people to test before I tag this release, just to make sure there aren't any regressions.
Going to give it a few days for people to test before I tag this release, just to make sure there aren't any regressions.
Committed.
damienmckenna → changed the visibility of the branch 8.x-1.x to hidden.
Committed.
Committed. Thanks everyone!
This is what I'm going with.
Committed! Thanks everyone!
Committed. Thanks.
There's a regression in the tests against D11, that needs to be fixed then it'll be ready to go.
Committed. Thank you!
Meta tags that allow multiple values will automatically have a note added to their description.
Committed. Thank you!
damienmckenna → created an issue.
Committed. Thank you!
Committed.
Committed.
Fixed.
damienmckenna → created an issue.
damienmckenna → created an issue.
Committed.
damienmckenna → created an issue.
Committed. Thank you everyone for digging through this.
Ok.. so at some point today the default build changed from 10.3 to 11.0. I'll do a separate issue to update the tests to also test 10.3, but otherwise this is ready to go.
The v2 upgrades fail because the d9 fixtures file was removed. That makes sense.