🇺🇦Ukraine @Matroskeen

The problem is: The code suppose the $entity_types is array. It is not if you have not setup the module, its NULL

I wonder how the module hook implementation is being called if the module is not installed?

Hi Remco,

You're very welcome to collaborate and submit your code suggestions to dedicated issues. Feel free to use 2.0.x branch, that I created but haven't had time to make something real.

Unfortunately, I'm not available to actively collaborate and review the code, since I'm in the army now.
You can try involving other community members to review the code. If you add some automated tests to cover new changes, that would be even better.

Let me know if you need anything else to start working.
Thanks!

Thanks!

Thanks for the confirmation! Closing it

In the meantime, here is a patch that you can try.

rabbit_hole_update_8105() update is looking at rabbit_hole.behavior_settings.* config objects.
Can you confirm that it fails when action property is empty?

Re #29, Based on some work I have done in Tus issues queue ( #3313657: Use file uploader service from Drupal core → ), I can't find anything specific. I see I added some todos, that are already planned to be addressed in Drupal core.

Speaking of specific issues, I do remember that it was somehow difficult to overcome the file size validation - by default, it's looking into environment limitations, but it should not be the case when small chunks of the file are uploaded. Anyway, it seems to be out of the issue scope.

I'm not diving into the details, but I hope the contributors will keep in mind the support of resumable file uploads. Example: https://www.drupal.org/project/tus → .

It would be hard to fix the tests now, so we'll proceed without test coverage for now.

Matroskeen → created an issue.

Matroskeen → created an issue.

Committed to 2.0.x branch.

Matroskeen → created an issue.

Matroskeen → created an issue.

Since we're still in alpha, I think it's okay to go ahead and commit.
Looking forward to more testing and feedback from the community ✌️

There was another report of this issue, so we should probably go ahead and release it as soon as possible.
Committed to 2.0.x.
Thanks!

I'm trying to understand how this is possible. The 2nd parameter of array_map call is $entity_types, which contains enabled_entity_types property of rabbit_hole.settings config.

There is a default value for this property defined in config/install/rabbit_hole.settings.yml. So how did you manage to install the module without applying the default configuration?

Can you check please?

Duplicate of 🐛 In_array(): Argument #2 ($haystack) must be of type array, null given in in_array() Fixed .

Matroskeen → created an issue.

Matroskeen → created an issue.

Matroskeen → created an issue.

Matroskeen → created an issue.

Here is the initial proposal. We have 3 new services:
shopify.shopify_client - contains a single instance of Shopify\Clients\Rest
shopify.shopify_client_factory used to create instance of Shopify\Clients\Rest
shopify.shopify is our wrapper on top of contrib HTTP client, where we'll keep some helper methods

Usage:

Procedural/static:
$shopify = Shopify::get();

Services:
Inject shopify.shopify service.

Matroskeen → created an issue.

Matroskeen → created an issue.

Matroskeen → created an issue.

Matroskeen → created an issue.

Matroskeen → created an issue.

Matroskeen → created an issue.

Matroskeen → created an issue.

Matroskeen → created an issue.

Matroskeen → created an issue.

Most likely, you have guzzle ^6.x.

You have to add manually php-http/guzzle6-adapter: composer require php-http/guzzle6-adapter
Just tested using Drupal 9.5.10 and PHP 8.1.

Mailgun 2.0.0 is out: https://www.drupal.org/project/mailgun/releases/2.0.0 →
Thanks!

Mailgun 2.0.0 is out: https://www.drupal.org/project/mailgun/releases/2.0.0 →
Thanks!

Still waiting for some details that will help to track the root cause of this issue.

I wasn't able to reproduce this issue using 8.x-1.x or 2.0.x. Feel free to re-open with more details.
Thanks!

I wasn't able to reproduce the issue, and there are no clear steps that might help to do that. Feel free to re-open with more details.
Thanks!

Sorry, there was no clear plan for 2.0.x version. The alpha version is already available for testing and your review.
See: https://www.drupal.org/project/rabbit_hole/releases/2.0.0-alpha1 →

If you have some feedback about 2.0.x, you can use this task: 🌱 Rabbit Hole 2.0 testing (upgrade, config, usage) Active .
Thanks!

8.x-1.x won't have a stable release due to some issues, that were hard to fix.
2.0.x will have a stable release, eventually. There are no identified blockers, it just requires more manual testing and usage.

Thanks!

This issue won't be fixed in 8.x-1.x version. You're welcome to upgrade to 2.0.x, which provides another data model and hopefully doesn't have this issue. See the change record for more details of 2.0.x version: https://www.drupal.org/node/3359194 →

Support for ECK and any other content entities with canonical path was added in 2.0.x version. More details are available in this change record: https://www.drupal.org/node/3359194 → . Participants are welcome to review and test a new version.

8.x-1.x won't receive any additional features, so the patch won't be committed here.

I'll set this issue to "Fixed" because it was technically fixed, although in a different way.

Cheers!

Both releases are already compatible with Drupal 10.

✨ Add message for admins to indicate what action would happen Fixed just landed into 2.0.x. This issue will be open to make the message configurable (if there is a reasonable argument to do that).

1) There is a new checkbox, saved in the bundle settings;
2) Done;
3) Suggestions/improvements will be accepted in the follow-up issue;
4) Done.

Thank you!

Adding screenshots to the issue description

@james.williams I appreciate your feedback, but I must mention that 8.x-1.x won't include new features. I'll make sure it's described on the module page.

In the meantime, feel free to take some time and test a new 2.0.0 version that should not have this issue.
Here is a change record with all major changes in 2.0.x: https://www.drupal.org/node/3359194 →

It should be good to go. The title and description of new checkbox might be improved, so if you have any suggestions - feel free to open a follow-up task. Thanks everyone!

Editing the issue summary

@Greg Boggs thanks for the manual testing. I started from a bit different approach, but after giving it a second thought, I think the original idea of no_bypass property is good and will play nicely along with ✨ Add message for admins to indicate what action would happen Fixed .

It'll be committed after adding some tests. I'll work on it tomorrow.

If we'll look into \Drupal\taxonomy\Entity\Term and @ContentEntityType annotation, we'll see that canonical link exists by default:

*   links = {
 *     "canonical" = "/taxonomy/term/{taxonomy_term}",
 *     "delete-form" = "/taxonomy/term/{taxonomy_term}/delete",
 *     "edit-form" = "/taxonomy/term/{taxonomy_term}/edit",
 *     "create" = "/taxonomy/term",
 *   },

We also have proof in the functional tests that "Taxonomy" is available in the supported entity types:

$this->drupalGet('admin/config/content/rabbit-hole');
$this->assertSession()->fieldExists('entity_types[user]');
$this->assertSession()->fieldExists('entity_types[node]');
$this->assertSession()->fieldExists('entity_types[taxonomy_term]');

After that, I noticed this in rabbit_hole_href.module. No surprise it's not working - canonical link for taxonomy terms is not available anymore:

function rabbit_hole_href_entity_type_alter(array &$entity_types) {
  // @todo Determine the entity types which have rabbit_hole_href enabled as
  // rh_action, see Drupal\rabbit_hole\BehaviorInvoker, and go through them
  // instead of only taxonomy_term:
  // behaviourInvorker->getRabbitHoleValuesForEntityType($entity_type, $bundle);
  // NOTE: Currently the uri callback is always set, even if redirect is set to
  // 404 etc.!!
  $entity_types['taxonomy_term']->setUriCallback('rabbit_hole_href_redirect_uri');
  $links = $entity_types['taxonomy_term']->get('links');
  unset($links['canonical']);
  $entity_types['taxonomy_term']->set('links', $links);
}

Maybe the unset is not necessary? For example, in one of the core modules this is not happening:

/**
 * Implements hook_entity_bundle_info_alter().
 */
function forum_entity_bundle_info_alter(&$bundles) {
  // Take over URI construction for taxonomy terms that are forums.
  if ($vid = \Drupal::config('forum.settings')->get('vocabulary')) {
    if (isset($bundles['taxonomy_term'][$vid])) {
      $bundles['taxonomy_term'][$vid]['uri_callback'] = 'forum_uri';
    }
  }
}

Let me know if you think that conditions in Rabbit Hole should be different.

The backtrace was actually helpful, it showed that there might be some update hooks that eventually will lead to calling the BehaviorSettingsManager::entityTypeIsEnabled() method. It will fail if this method is called before rabbit_hole_update_8103() update hook, when the enabled_entity_types is initialized.

@hchang can you strat the update from scratch using the patch?
If it fails, can you send the whole console output so we can see the order of executed update hooks?

@gaddman you should have either Guzzle 7 or Guzzle 6 + guzzle6-adapter.

If your project requires drupal/core-recommended, you won't be able to upgrade to Guzzle 7 before you upgrade to Drupal 10. In that case, you should manually require guzzle6-adapter.

Otherwise, you should be able to upgrade to Guzzle 7 while you still have 9.5.9.

We'll make it clear in the release notes.

I messed up the default fork branch, so here is a patch.

Matroskeen → created an issue.

Ok done :)

All child issues are fixed and available for testing in 2.0.x branch.
See https://www.drupal.org/node/3359194 → for more details.

Please see my comment #2 and provide some steps to reproduce.

We also have a test for the upgrade path, so if the issue exists, the test should fail.

Hi @Avinash_patil! Thanks for the report. Is it reproducible after running the database updates? (drush updb -y)

Matroskeen → created an issue.

There is no strict format to define the parameters types in hook definitions. If you would check the Drupal core, you'll see that both formats are present.

I actually like using the full namespace, as it gives me a working function when using autocomplete suggestions in IDE. Let's keep it as-is.
Thanks!

Updating the issue summary to be more generic.

Done 👌

It should be better for now. We might revisit it again later.

No, it won't be done :)
Since it was my request many years ago, I'm just closing the task.

Profile (and any other) entity types are supported in a new 2.0.0 → version. Thanks!

Access to entity canonical page and layout builder page are 2 different issues. Access to Layout Builder pages is controlled via multiple levels of permissions.

Access to canonical page is very special since it uses "view" entity operation. The same operation is used when entity is viewed in other contexts (teaser, row in admin table, etc.). That's why Rabbit Hole exists - it targets specifically the canonical page and keeps the entity accessible in other places.

I believe that handling the layout builder page is not the responsibility of this module. Please take a look into layout builder permissions, and I'm sure it'll cover your needs.

Thanks!

Since there were no additional details, the issue is closed.