When the Panels / Page Manager integration was added in #2563657: Panels / Page Manager integration it was managed via a separate page on the Metatag configuration. It would be really useful if it could be possible to edit the Metatag definitions directly within the Page Manager UI instead of having to go somewhere else.

Issue fork metatag-2988154

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

DamienMcKenna created an issue. See original summary.

sophiavs’s picture

Status: Active » Needs work
StatusFileSize
new1.89 KB

Hey, i made the first patch for this new feature. There's still some ways to improve, but for a first patch I believe this is good :)

damienmckenna’s picture

Status: Needs work » Needs review

Thank you for putting that together. Let's see what the testbot says, just to be safe.

sophiavs’s picture

StatusFileSize
new2.25 KB
new2.17 KB

Sorry, the last patch was missing some part of the diff.
The first patch (2988154-4-v122.patch) is a patch to apply in metatag:^1.22, and the second one (2988154-4.patch) to 8.x-1.x-dev.

sophiavs’s picture

StatusFileSize
new2.59 KB
new1.1 KB

Hey, i made some changes to make the modal work right in the version 1.22.

sophiavs’s picture

StatusFileSize
new3.28 KB
new4.59 KB

I moved the hook to be inside the metatag_page_manager module and created this new patch.
It will work for both 1.22 and 8.x-1.x-dev branches.

vpoltronieri’s picture

StatusFileSize
new3.36 KB
new625 bytes

I just added a small validation to make the metatags edit button visible only if the user has the "administer meta tags" permission.

damienmckenna’s picture

Is the permission change useful? Do people want to require the permission be given to users who are editing Page Manager pages in order to also edit the meta tags?

vpoltronieri’s picture

The permission is already necessary if the user wants to edit the metatags because it is the permission for the "entity.metatag_defaults.edit_form" (route used for editing the metatags in this patch).
I'm just hiding the button in case the user doesn't have permission for the route the button would direct him to. :)

damienmckenna’s picture

Ok, fair point.

damienmckenna’s picture

Status: Needs review » Needs work
StatusFileSize
new131.16 KB

I tested the patch and it needs work.

What I was envisioning would be that the Metatag configuration would show up as a link alongside "General", "Contexts", etc in the left sidebar, and would not be a link in the interior area.
The changes from patch #7

Furthermore, when I clicked the link it resulted in an error in the JSON response:

{"message":"The \u0022metatag_defaults\u0022 parameter was not converted for the path \u0022\/admin\/config\/search\/metatag\/{metatag_defaults}\u0022 (route name: \u0022entity.metatag_defaults.edit_form\u0022)"}

vpoltronieri’s picture

Makes sense, I'll work on it.

vpoltronieri’s picture

Hey Damien, the first part is going to take a little longer to implement, so now I'm going to focus on the error you encountered. I was unable to replicate this error in my local environment. Could you provide more information on how to reproduce it? NVM, I managed to replicate now.

damienmckenna’s picture

I was testing with the latest git checkouts for CTools 8.x-3.x and Page Manager 8.x-4.x, I edited the existing node view page, I added a new variant, filled in the initial dialog to give it a name, as soon as I submitted that form it gave a WSOD error because $form['wizard_tree']['#wizard'] was empty. I wrapped that in a quick if(!empty()) (forgot to upload a new patch), then was able to create the variant and get to the point I could see the link. The error logged in #11 was visible in the browser's console when I clicked the "edit" button.

vpoltronieri’s picture

StatusFileSize
new4.33 KB
new3.85 KB

Hey, I'm done fixing the bug you found (and a few others I found during testing), this patch release contains these fixes.

The next step is to move the meta tags option to the correct location, as directed by you, Damien. Soon our team will work on it.

ivnish’s picture

Status: Needs work » Needs review
ivnish’s picture

StatusFileSize
new4.34 KB

I rerolled patch to 2.0 version

ivnish’s picture

DamienMcKenna can you test it again? I don't see any problem

rafmagsou’s picture

StatusFileSize
new4.36 KB
new997 bytes

Update logic came from patch #15, to prevent error regarding missing "wizard_tree" field
more details in the interdiff

ivnish’s picture

Version: 8.x-1.x-dev » 2.0.x-dev
ivnish’s picture

Status: Needs review » Needs work

ivnish’s picture

Assigned: Unassigned » ivnish
Status: Needs work » Needs review
krakenbite’s picture

Status: Needs review » Reviewed & tested by the community

MR works for me. Please commit

ivnish’s picture

Assigned: ivnish » Unassigned
ivnish’s picture

up!

damienmckenna changed the visibility of the branch 2.0.x to hidden.

damienmckenna’s picture

StatusFileSize
new4.35 KB

Rerolled.

damienmckenna’s picture

Status: Reviewed & tested by the community » Needs review
StatusFileSize
new4.42 KB

Improving wording.

damienmckenna’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests

This still needs some work.

I created a variant on the default "node_view" page definition and the "edit" or "add" link didn't show. I changed the code to skip the $wizzard_tree-instanceof-PageWizardBase check and the link showed, but then clicking the "add" button didn't let me define the meta tags, it showed the add-metatag-defaults form with no options on the entity bundle selector.

This means the UX needs to make it more clear what types of pages are allowed, what types are not, and the UX should adjust accordingly. While it would be complicated to link to the meta tag forms based upon the selection criteria definitions for each variant, I think links could be added for the metatag defaults definitions for the entity types, and help text needs to be included explaining what the link opens.

andypost’s picture

Would be great to create merge request to run pipelines for regressions

ivnish’s picture

I created MR in #22

dabbor’s picture

StatusFileSize
new4.51 KB

When updating cweagans/composer-patches to version 2.0.0 the patch from #29 can NOT be applied anymore, providing message: No available patcher was able to apply patch.

Related reading: #3564942: composer-patches version 2 is not yet compatible with Drupal?. Composer-patches 2.x applies patches using git apply and requires patches in git diff format.

I re-created the patch from #29 using git diff to work properly when used by git apply.