🇺🇸United States @DamienMcKenna

damienmckenna → created an issue.

damienmckenna → created an issue.

damienmckenna → created an issue.

damienmckenna → created an issue.

Is this the correct approach or are there other considerations or appraoches to fixing this that I didn't take into account?

This is the code I'm prototyping:

if ($this->moduleHandler->moduleExists('tvi')) {
  if (str_starts_with($display->getBaseId(), 'views_')) {
    $term = \Drupal::routeMatch()->getParameter('taxonomy_term');
    if ($term instanceof TermInterface) {
      $tvi = \Drupal::service('tvi.tvi_manager');
      $term_view = $tvi->getTaxonomyTermViewAndDisplayId($term);
      if (!empty($term_view) && isset($term_view['view_id'], $term_view['display_id'])) {
        $display_plugin_definition = $display->getPluginDefinition();
        if (isset($display_plugin_definition['view_id'], $display_plugin_definition['view_display'])) {
          if ($term_view['view_id'] == $display_plugin_definition['view_id'] && $term_view['display_id'] == $display_plugin_definition['view_display']) {
            return TRUE;
          }
        }
      }
    }
  }
}

It feels a bit unclean, besides the \Drupal::service() usage. Is there a better way?

A prototype that checks if the current path is managed using TVI, then compares the current facet's Search API display against TVI's display.

damienmckenna → created an issue.

I think SearchApiDisplay::isRenderedInCurrentRequest() needs to be extended to check if the configured view is displayed on the current page.

I'm running into a similar issue where I'm using the "page" display via TVI and the facets aren't being displayed though the block plugin is supposed to show.

damienmckenna → created an issue.

The problem appears to be this:

class ViewfieldFormatterDefault extends FormatterBase {
..
  public function viewElements(FieldItemListInterface $items, $langcode) {
..
        if (!empty($view->result) || $always_build_output) {

This doesn't have any logic to check if the exposed form is supposed to be displayed.

It works if I select the "Always build output" option..

damienmckenna → created an issue.

For consideration:

diff --git a/core/lib/Drupal/Core/Url.php b/core/lib/Drupal/Core/Url.php
index d16ef550651..b3a8e0e0d41 100644
--- a/core/lib/Drupal/Core/Url.php
+++ b/core/lib/Drupal/Core/Url.php
@@ -276,6 +276,11 @@ public static function fromUserInput($user_input, $options = []) {
    * @see \Drupal\Core\Url::fromUserInput()
    */
   public static function fromUri($uri, $options = []) {
+    // Special handling for <nolink>.
+    if ($uri == '<nolink>') {
+      return Url::fromRoute('<nolink>');
+    }
+
     // parse_url() incorrectly parses base:number/... as hostname:port/...
     // and not the scheme. Prevent that by prefixing the path with a slash.
     if (preg_match('/^base:\d/', $uri)) {

damienmckenna → created an issue.

Thank you for reporting the bug and providing a merge request, hopefully some folk will be able to test this and work towards committing a fix.

As a reminder, please set the "Assigned" field to "Unassigned" after you're finished with your work - attribution/credit for issues is tracked separately. Thank you.

This breaks the taxonomy hierarchy display.

A structure like this:

- Term 1 (weight 0)
  - Term 1.1 (weight 0)
    - Term 1.1.1 (weight 0)
  - Term 1.2 (weight 1)
- Term 2 (weight 1)
- Term 3 (weight 2)
  - Term 3.1 (weight 0)

This turns into the following:

- Term 1 (weight 0)
- Term 1.1 (weight 0)
- Term 1.1.1 (weight 0)
- Term 3.1 (weight 0)
- Term 2 (weight 1)
- Term 1.2 (weight 1)
- Term 3 (weight 2)

(or worse)

damienmckenna → created an issue.

In patch format.

FWIW wrapping the code in a try-catch block works around the issue, e.g:

    try {
      $installed_version = InstalledVersions::getPrettyVersion('drupal/search_api_solr');
    }
    catch (\Exception $e) {
      return self::SEARCH_API_SOLR_MIN_SCHEMA_VERSION;
    }

damienmckenna → created an issue.

There's an existing issue to fix this problem: 🐛 "Drupal\migrate_tools\Commands\MigrateToolsCommands" not found PathRedirectImportCommands Postponed: needs info

Does the problem still happen with the current release?

Does the problem still happen with the current release?

This needs to be turned into a merge request so the tests can run.

This needs to be turned into a merge request so the test scan run.

This needs to be turned into a merge request so the tests can run.

The module currently requires braintree_php ^6.12.

This was fixed in 📌 Move to gitlab Fixed .

The merge request needs to be updated.

Looks reasonable.

There's an existing issue for this.

Done: https://www.drupal.org/project/link/releases/7.x-1.12 →

Committed. Thank you.

Done: https://www.drupal.org/project/views/releases/7.x-3.30 →

Thanks everyone!

The correct test patch.

Committed. Thank you.

Committed. Thank you.

Committed. Thank you.

Fixed some copy pasta on CheckboxWidget.php.

It was mentioned in 🐛 github.com/waza-ari/msdropdown library is gone Active that https://github.com/waza-ari/msdropdown was removed, so a different location is needed or this work needs to be done.

Please continue the discussion in 📌 Update code to be compatible with ms-dropdown library Version 4 Needs work .

Please test the latest release of the module and provide an update on whether it's now working. Thank you.

Could you please test to see if you can see any JS errors on the page on your phone? That would help determine where the problem is. Thank you.

Please test out the latest 8.x-2.3 branch and provide an update. Thank you.

Thank you for the bug report and the patches.

Because Drupal has moved away from using patches to using merge requests, the latest patch will need to be turned into a merge request.

Also, please remember to set the "assigned" field to "Unassigned" when you're finished working on an issue, that way others will know they can review it, continue working on it, etc.

Thank you for the bug report and the patches.

Because Drupal has moved away from using patches to using merge requests, the latest patch will need to be turned into a merge request.

Also, please remember to set the "assigned" field to "Unassigned" when you're finished working on an issue, that way others will know they can review it, continue working on it, etc.

Drupal 9 has not been supported since June 2024, so I recommend upgrading.

Drupal 9 has not been supported since June 2024, so I recommend upgrading.

A patch for v3.0.x - I tried to create a merge request for it but gitlab wouldn't let me pick 3.0.x as a destination branch, even after I updated the issue fork from the main repo.

Am working on porting it to v3.

This needs to be reworked for v3.

damienmckenna → created an issue.

damienmckenna → created an issue.

damienmckenna → created an issue.

damienmckenna → created an issue.

damienmckenna → created an issue.

Needed to skip this meeting due to a project emergency.