🇨🇦Canada @franceslui

@seanr, In comment #10, you mentioned the plan to split the widget out into its own project. I was wondering if you ended up doing that? If so, would you mind sharing a link to the code? I am currently working on a related task and would like to see whether your solution could help address the issue.

Thank you again for your work on this.

The commerce_registration_change_host submodule allows the product variation to be changed after a registration is made. However, our site requires the ability to change the product itself, rather than just the variation. As a result, this submodule does not fully meet our needs.

To address this, we followed the approach used in ChangeHostSubscriber within this submodule to find and display all products and their variations.

Here is our code in case others need to implement a similar solution:

use Drupal\commerce_product\Entity\ProductVariationInterface;
use Drupal\registration_change_host\Event\RegistrationChangeHostEvents;
use Drupal\registration_change_host\Event\RegistrationChangeHostPossibleHostsEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

final class ChangeHostSubscriber implements EventSubscriberInterface {

  /**
   * Add possible hosts.
   *
   * @param \Drupal\registration_change_host\Event\RegistrationChangeHostPossibleHostsEvent $event
   *   The registration change host event.
   */
  public function getPossibleHosts(RegistrationChangeHostPossibleHostsEvent $event) {
    $registration = $event->getRegistration();
    $set = $event->getPossibleHostsSet();
    $entity = $registration->getHostEntity()->getEntity();
    if ($entity && $entity instanceof ProductVariationInterface) {
      $products = \Drupal::entityTypeManager()->getStorage('commerce_product')->loadMultiple();
      foreach ($products as $product) {
        if ($product) {
          foreach ($product->getVariations() as $variation) {
            $access = $variation->access('view label', NULL, TRUE);
            if ($variation->id() != $entity->id() && $access->isAllowed()) {
              $possible_host = $set->buildNewPossibleHost($variation);
              if ($possible_host->getHostEntity()->isConfiguredForRegistration()) {
                $set->addHost($possible_host);
              }
            }
            // A variation could become a possible host if it became accessible
            // or configured for registration.
            $set->addCacheableDependency($access);
            $set->addCacheableDependency($variation);
          }
          // Any new variations added to the product could be possible hosts.
          $set->addCacheableDependency($product);
        }
      }
    }
  }

  /**
   * {@inheritdoc}
   */
  public static function getSubscribedEvents(): array {
    return [
      RegistrationChangeHostEvents::REGISTRATION_CHANGE_HOST_POSSIBLE_HOSTS => 'getPossibleHosts',
    ];
  }
}

I am unable to allocate time to implement a test at the moment. I would greatly appreciate assistance with this, or I can revisit it when my schedule permits. Thank you for your understanding.

franceslui → made their first commit to this issue’s fork.

After upgrading the module from version 4.0.0-alpha5 to 4.0.0-alpha6, I encountered the warning and error described in issue 🐛 Warning: Trying to access array offset on value of type null in Drupal\conditional_fields\ConditionalFieldsFormHelper::formFieldGetValues() Active . Upon investigation, I found that three specific lines had been removed at https://git.drupalcode.org/project/conditional_fields/-/commit/962c0a834.... To resolve the issue, I submitted a merge request in issue 🐛 Warning: Trying to access array offset on value of type null in Drupal\conditional_fields\ConditionalFieldsFormHelper::formFieldGetValues() Active to restore these lines.

franceslui → created an issue.

franceslui → made their first commit to this issue’s fork.

franceslui → made their first commit to this issue’s fork.

I concur with @smustgrave’s comment #24 that the check I implemented in my patch might obscure a deeper issue. Therefore, I have removed my patch from this issue. Upon further investigation, I discovered that the problem stems from the static_page module rather than Drupal core. The detailed information can be found in the related issue at https://www.drupal.org/project/static_page/issues/3386719 🐛 Revision object is returned instead of revision id due to core type upcasting change. Needs review . You can also find my new patch in my comment at https://www.drupal.org/project/static_page/issues/3386719#comment-15649482 🐛 Revision object is returned instead of revision id due to core type upcasting change. Needs review .

@sahilgidwani Thank you for submitting the patch in your comment #2. I have reviewed it and found that it worked correctly.

Since node_revision_load is deprecated in Drupal 10.1.0 and will be removed in Drupal 11.0.0, I have submitted a new patch that uses \Drupal\Core\Entity\RevisionableStorageInterface::loadRevision instead.

The current implementation of ContentEntityStorageBase::loadRevision() and ContentEntityStorageBase::loadMultipleRevisions() does not adequately handle invalid or empty revision IDs. This can lead to potential errors or unexpected behavior when these methods are called with invalid parameters.

Solution:
1. Added validation in ContentEntityStorageBase::loadRevision($revision_id) to check if $revision_id is either an integer or a string. If not, the method exits early and returns NULL.
2. Added a check in ContentEntityStorageBase::loadMultipleRevisions(array $revision_ids) to exit early and return the revisions array if no revisions can be loaded, ensuring the method does not proceed with empty data.

The code attempts to access array elements based on $index without checking if the $index is within the bounds of the $thresholds array. This leads to "Undefined offset" errors when the $names array has more elements than the $thresholds array.

We need to ensure that the index access within the $thresholds array is safe by checking that $index is within the array bounds. In my attached patch, I assume that $thresholds[0] should be used if $thresholds[$index] is not set. Please see my attached patch for details.

franceslui → created an issue.

@john.oltman Thank you so much for the prompt information provided! Your quick response is greatly appreciated.

franceslui → created an issue.

@john.oltman. Thank you very much for your quick reply and fix. I greatly appreciate your help!

@john.oltman Thank you very much for your quick reply and asking questions to help resolve the issue.
I have found out what caused the issue. So, I have modified the section "Steps to reproduce" to explain how the issue can be reproduced.

To get around the issue, I added the following code

function hook_entity_delete(EntityInterface $entity) {
  if ($entity instanceof OrderItemInterface) {
    // When an order item is deleted, change status of all existing registrations in the cart to 'canceled'.
    // An order item can be deleted by the module commerce_cart_redirection because we have checked the checkbox
    // "Clear cart before add" with help text "Select whether everything that is currently in the cart will be
    // removed before adding a new item" at /admin/commerce/config/commerce_cart_redirection.
    $storage = \Drupal::entityTypeManager()->getStorage('registration');
    $registrations = $storage->loadByProperties([
      'order_id' => $entity->getOrderId(),
    ]);
    if (!empty($registrations)) {
      // The following code is originally from OrderSubscriber's function onOrderUpdate(OrderEvent $event)
      foreach ($registrations as $registration) {
        if ($registration->isActive() || $registration->isHeld()) {
          if (!$registration->isComplete()) {
            if ($workflow = $registration->getWorkflow()->getTypePlugin()) {
              if ($workflow->hasState('canceled')) {
                $registration->set('state', 'canceled');
                $registration->save();
              }
            }
          }
        }
      }
    }
  }
}

Do you think you could do something similar in your module? Thank you again for your help.

franceslui → created an issue.

@john.oltman Thank you very much again for fixing the issue.

I am sorry that I mistakenly changed the status from 'Fixed' to 'Needs review'.

Your opinion about my suggested change makes sense to me. Thank you for that too and have a nice day!

@john.oltman Thank you again for fixing the issue mentioned in its description.

Do you think that you could also fix the related issue mentioned in comment #2: cancelling a registration does not change cart status to 'Canceled'? I would say that if a cart contains only a registration, canceling this registration should also cancel the cart. What do you think?

@john.oltman I greatly appreciate your help of fixing it so quickly! Have a nice day!

Our workshop has a limit of certain number of registrations, so we would like to cancel some carts to free up some spaces for new registrations.

Currently, to work around the issue of registration status not changed to 'Canceled' for cancelled carts, we have to cancel pending registrations manually after cancelling carts.

franceslui → created an issue.

Rerolling for 10.2.x because we are using this patch.

I re-roll it to 10.2.x.

Reroll of merge request 1624 for Drupal 10.1.x. These were what I did:
- changed the function name from 'testFilterGrouping' to 'testFilterGroupingWith2DifferentTerms' in my patch for the file TaxonomyIndexTidUiTest.php because the function testFilterGrouping exists in this php file in Drupal 10
- added the statement 'use Drupal\views\Plugin\views\ViewsHandlerInterface;' in my patch for the file ManyToOneHelper.php
- removed hunk #8 (the last hunk) from the original patch in merge request 1624 because the same code changes are already in Drupal 10

I am going to re-roll it to 10.1.x.

In the function og_menu_form_menu_edit_menu_alter of the module og_menu.module, $ogm is false at line 526 if users edit regular menus (i.e. non-OG menus). To fix this bug, I have modified the code to check if $ogm is not false before retrieving its array item. Please see my attached patch. Thank you.

franceslui → created an issue.

@ joelpittet Thank you so much for pointing out that my previously submitted patch was not compatible with PHP 5.3.3. I don't think we should enforce PHP >= 5.4.0 in your info file because doing so may make other people's sites not working.

I have submitted a new patch that should have no compatibility issues. Please see the attached. Thank you.

I greatly appreciate your help to implement my requested waitlist feature so quickly.

To fix the issue, I have modified the function _resource_conflict_get_timespans so that $start and $end are always strings. Please see my attached patch. Thank you.

franceslui → created an issue.

franceslui → created an issue.

I work with @joelpittet.

Because @joelpittet was not able to install DrupalCI Testbot on his machine, I installed it on my machine and could reproduce the errors in it locally.

When we used 7.x-1.6, we did not have any errors caused by this module. After updating this module to 7.x-1.7, we got this error:

EntityMalformedException: Missing bundle property on entity of type taxonomy_term. in entity_extract_ids() (line 8090 of
/.../includes/common.inc).

To get rid of this error, we load an entity inside the loop. Please see the attached patch.