Support for the new page feedback block

Adding MR with block plugin code.

Ahh cool, similar to the existing webform block for "Did you find what you were looking for?" but just ajaxed-in instead. Can test this out shortly today/tomorrow!

Yes! I was working on it during our previous project now another client has requested it so here it is!! lol. Thanks!! One thing is that i have hard-coded the 'theme' options selector. I am not sure if we should make those more dynamic, but I think the list is fairly static. Cheers!

This patch appears to be for wxt_library not wxt.

ah ya, since it's a new file the MR branch patch will still apply against wxt_library

https://git.drupalcode.org/project/wxt/-/merge_requests/22.patch take this patch, apply it against wxt_library , should work.

LGTM

Should this issue be moved to the wxt_library queue?

So only one small issue I can see:

public function defaultConfiguration() {
    return [
      'feedback_settings' => [
        'theme' => '',
      ],
    ];
  }

But then in the form, we look for the default value like this:

empty($this->configuration['theme']) ? '' : $this->configuration['theme']

I think the defaultConfiguration() method should be:

public function defaultConfiguration() {
  return [
    'theme' => '',
  ];
}

Then the default value could simply be:

$this->configuration['theme']

Oh actually maybe this was my oversight, I see how the field is nested under ['feedback_settings'], so this actually might not be an issue. Will pull this into my local and test, then merge with 5.4.x and 6.1.x. Thanks!

Agree with @liam, this should be moved to wxt_library and sit next to the existing blocks there, moving project now.

Since this PR was made against the wxt project, it will need to be recreated for wxt_library.

I did pull this block locally and added the block to the page footer. I noticed the AJAXed content contains wrapping column classes, but within a required div (#gc-pft), how are you guys handling this? I can't add column classes to the block UI since the markup is already wrapped with col-sm-10 col-md-9 col-lg-8, and that causes layout issues. I thought maybe data-wb-doaction could be used to remove classes, but it doesn't work on AJAXed content.

Typically, Will asked that all wxt issues are raised against wxt and that is why there are components for wxt_library and wxt_bootstrap on that issue queue. Let people know if this is changing.

Ya that makes sense for a ticket with only a patch file, but a PR would have to be against wxt_library if that's where you are adding the block class file, and you can't raise a PR against wxt_library in a wxt issue. And now that we have added GitLab tests to all sub-projects (wxt_library, wxt_bootstrap) it's nice to have the tests run against the PR so issues can be identified and fixed before merging.

The only thing preventing this from being merged to wxt_library is knowing how to deal with the column classes in the AJAXed content. Not sure why they would add wrapping column classes, that should be left to the system implementing the block. I'm not able to get the block in the proper layout without hacking the CSS and overriding the column class styles. How are you guys doing this? If the answer is fixing with CSS, I can merge as is and maybe we can ask them to remove those column classes from source. If you have a better way to handle this then it would be good to have documented in this ticket for others to see. Thanks!

I got it to work by removing the share widget. Agree, they really should not be adding those classes. Cheers!

Oh, and in block config I added col-sm-9, col-md-9, col-lg-10... not sure if that is correct, but it ended up looking ok.

Adding a patch file for composer.