🇨🇦Canada @franceslui

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.