[error] Drupal\Component\Plugin\Exception\ContextException: The context is not a valid context.

Seeing this thrown with pathauto (Pathauto 8.x-1.10 and dev 8.x-1.x; Drupal Core 9.4.4}

Rolling back commit https://git.drupalcode.org/project/ctools/-/commit/9e412258eaaa840524350... makes it go away.
Edit for clarity: This commit is in 4.0.1 and 8.x-3.10; it's not in 8.x-3.9.
Pathauto has a very generous "*" in its composer.json. Pathauto seems to be in the process of removing ctools dependency, but it's still there of dev at the moment.

Not had time to investigate so don't know if other modules using ctools are causing this error with 4.0.1 and 8.x-3.10 or if it is just the way pathauto uses it.

Drupal\Core\Executable\ExecutablePluginBase->getContext(NULL) (Line: 116)
Drupal\Core\Executable\ExecutablePluginBase->getContextValue(NULL) (Line: 91)
Drupal\Core\Entity\Plugin\Condition\EntityBundle->evaluate() (Line: 77)
Drupal\Core\Condition\ConditionManager->execute(Object) (Line: 84)
Drupal\Core\Condition\ConditionPluginBase->execute() (Line: 376)
Drupal\pathauto\Entity\PathautoPattern->applies(Object) (Line: 320)
Drupal\pathauto\PathautoGenerator->getPatternByEntity(Object) (Line: 41)
Drupal\pathauto\PathautoWidget->formElement(Object, 0, Array, Array, Object) (Line: 353)
Drupal\Core\Field\WidgetBase->formSingleElement(Object, 0, Array, Array, Object) (Line: 220)
Drupal\Core\Field\WidgetBase->formMultipleElements(Object, Array, Object) (Line: 111)
Drupal\Core\Field\WidgetBase->form(Object, Array, Object) (Line: 181)
Drupal\Core\Entity\Entity\EntityFormDisplay->buildForm(Object, Array, Object) (Line: 121)
Drupal\Core\Entity\ContentEntityForm->form(Array, Object) (Line: 127)
Drupal\node\NodeForm->form(Array, Object) (Line: 106)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object)

Same issue on 3.10 version

Got this on all content add pages until reverting the 3.9.0 to 3.10.0 upgrade.

Seems to introduce a NULL context and it does not handle it well?

Same error on 3.10.0 version

It works for me when going back to version to 3.9.0 and Drupal Core 9.4.4.

confirmed reverting to composer require 'drupal/ctools:3.9.0' resolves the issue

We saw this issue until updating our existing Pathauto patterns (re-saving them) so that they were saved using the entity_bundle:node condition plugin in their selection_criteria instead of node_type. Pathauto 8.x-1.10 actually included a database update for updating existing Pathauto patterns with this change (#3222776: Replace the node_type condition with entity_bundle:node) but because we also have some of ours exported as install config in custom modules, we still had some that were not updated by the Pathauto DB update function.

I see this error as well after the ctools update to 3.10 and drupal core 9.4.4, reverting to 3.9 fixes it i confirm

Here is what is going on indeed as was mentioned above path auto was not able to convert node_type to entity_bundle:node into config entities for all pathauto.patterns

Either write a hook update recommended approach,

Or for a fast fix go into the DB select from config table by name containing pathauto.pattern, inspect data

Replace serialized content s:9:"node_type" with s:18:"entity_bundle:node"

Make sure you export the configurations from db into code after that

Hope this will help someone

#5 works for me, Thank you!

Setting the version with a version constraint for drupal/ctools in our composer.json such as:

"drupal/ctools": "3.9 as 3.10"

fixes the issue for creation content in our site that uses wxt:4.3.1 and drupal/core:9.3.19

Same problem in view_mode_page... Maybe view_page_mode and pathauto should constrain the version to 3.9.0...

This error was generated on the node edit form for me. Reverting ctools with #8 resolved it. Definitely critical.

Found this error with ctools 3.10. In addition to breaking node edit forms on all content types as well as content/add, also breaks node creation migrations with the same error. Reverting to ctools 3.9 averts this error. Definitely critical, seeing the multiple reports of breaking errors here.

I'm getting this error with both drupal/ctools 3.10.0 and 4.0.1. Reverting to 3.9.0 fixed the issue for me.

Reverting the changes made to file src/Plugin/RelationshipBase.php in 3.10 back to 3.9 seems to have resolved this error.

Providing a patch to revert src/Plugin/RelationshipBase.php to the implementation in 3.9, preserving all other 3.10 changes.

#5 works for me, Thank you!

With patch from #17, I still get the same error.

Having same issue as well.
Reverting back to 3.9 worked but not patch on Drupal 9.4.3

Facing the same issue with Drupal 9.4.4

Temp fix in projects:

    "drupal/ctools": "3.9.0 as 3.10.0"

FYI there's zero benefit to doing "3.9.0 as 3.10.0" in composer.json, just set it to "3.9" or "3.9.0".

Given that CTools broke Pathauto, was it caused by an intentional API change in CTools that Pathauto needs to adjust to, or is it just a bug in CTools that needs to be fixed?

Reverting the status as there's nothing to review.

Not sure exactly.

For those looking for a quick fix, the easiest I find is to add a conflict to composer.json.

"conflict": {
        "drupal/ctools": "^3.10"
}

Thanks everyone. #17 didn't work.

If you are running version ^4.0 add

  "conflict": {
    ...
    "drupal/ctools": "^3.10 || ^4.0.1"
  },

and then run composer require drupal/ctools:^4.0 -W

You are right Damien
Tested with "drupal/ctools": "3.9"
Working

I'm only trying to find a way for all needed used modules like page_manager, panels, paragraphs, password_policy, total_control

#3293825: Update Chaos Tool Suite (ctools) module compatibility from ^3.1 to ~3.0 || ~4.0
#3299865: Integrate with Ctools context plugins
#2877040: Remove dependency on CTools
#3293839: Update Chaos Tool Suite (ctools) module from ~3.0 to ~3.0 || ~4.0

composer require 'drupal/ctools:3.9.0' then clearing the Drupal cache fixed the error for me.

#26 did the trick for me x)

Many thanks !

Withdrawing/hiding patch #17.

As a friendly reminder, an issue summary needs more than just an error. Trying to expand with context based on comments, please edit and expand as needed.

Hello,

Met this exact issue after updating ctools to 3.10.0 (prev. 3.7.0).

What happens in my case, is default content (default_content 1.x) is being imported, and while it's trying to solve pathauto for node, it fails with the exact message mentioned in the description.

Even though the bug occurs only after ctool update, pathauto sort of is aware of the ContextException.

When this bug occurs, the trace has following function called: \Drupal\pathauto\Entity\PathautoPattern::applies which has following code;

        if ($condition instanceof ContextAwarePluginInterface) {
          try {
            $context_handler->applyContextMapping($condition, $contexts);
          }
          catch (ContextException $e) {
            watchdog_exception('pathauto', $e);
            return FALSE;
          }
        }
        $result = $condition->execute();

Adding same try/catch over the $condition->execute() does work too (at least in my case), but I'm unsure whether it acts as a 'fix' or 'bury the problem'.

As stated in comment #10 -- this is probably the issue people are having. We should probably add an update hook to ctools itself. The code shouldn't have removed node_type in the 3.x branch, and hasn't.

If someone has a sample database they can send me in slack, pm japerry and I'll take a look.

#24 Worked for me. Reverting to 3.9.0.

Thank you, Jakob, and Daniel for the hint in
https://www.drupal.org/project/pathauto/issues/2925169#comment-14635641

• #3301361: Change node_type to entity_bundle:node for default pathauto pattern configs for the Basic Page content type
• #3301363: Change node_type to entity_bundle:node for default pathauto pattern configs for the Landing Page (Layout Builder) content type
• #3301364: Change node_type to entity_bundle:node for default pathauto pattern configs for the Blog Post content type

Not sure if a generic hook update for this could follow on entity types with patterns
Doing that on needed entity types

I don't understand those changes to entity bundle classes in that commit at all.

#2857279: Duplicate node type visibility condition in block settings dealt with the entity bundle issue, was backwards and forwards compatible from 9.0 to 10.0. It was committed to 8.x-3.x. included in 4.0.0 which was unpublished and that was tested on D9 and D10.

Those additional changes in that commit changes are IMHO not necessary and wrong, they completely break the node_type condition plugin. That is ctools fault as explained in #2925169-9: PluginNotFoundException: The "node_type" plugin does not exist. You can _not_ use the generic class for old node_type definition. Maybe it causes some phpstan errors, but there were no actual problems. I don't understand what the code is trying to do.

There are more strange things in the 3.10 commit, on one hand it requires 9.3 but then contains completely unnecessary backwards compatibility code for older versions of core (file_create_url()).

Note that people who have this problem would have run into this when updating to D10, but ctools broke it early in a minor update.

Note2: What ctools can _not_ do is provide an update function, as it doesn't know where these plugins are used. That's the responsibility of code using those plugins and both core and pathauto did that, but neither can fix default config in modules and install profiles like varbase.

Thanks for all the insights, Berdir.

Looking at the site where this broke, it is likely because pathauto configurations weren't properly exported after pathauto_update_8108() ran.

To fix your site so that it can use the latest CTools, search your site's configuration for "node_type" in the pathauto.*.yml files and replace it with 'entity_bundle:node'; alternatively just rerun pathauto_update_8108() (or copy its contents to your own custom module) and re-export the settings.

In my case, my site was using ctools 3.10.0 and pathauto 1.8.0 (which doesn't include pathauto_update_8108). Updating to pathauto 1.10.0 and running database updates resolved the issue for me. Thanks @berdir and @damienmckenna!!!

> Looking at the site where this broke, it is likely because pathauto configurations weren't properly exported after pathauto_update_8108() ran.

Note that there is a difference between default configuration in modules/install profiles (which must be updated manually) and the config sync folder of a specific site. the live config of a site _MUST_ always be re-exported after running updates*. Not doing so will cause many other problem as well and has caused problems in the past.

* It's a bit more complicated when you export on staging and then re-import on production, but even then, you can get into problems with new configuration and mismatching UUIDs so you need to be careful there.

I have now also released pathauto 8.x-1.11, which no longer depends on ctools, so if you are not using ctools otherwise, you can uninstall it now.

Reminder: If your site broke now, it would have broken in D10 even without this problem. You might have the same problem with core block config definitions if you use node type conditions, double-check block.* files as well and adjust accordingly.

Ahhh yes comment #8 makes a lot of sense. What I was trying to avoid was having ctools blow up when you use it in Drupal 10, since any old content with the existing node_type condition would just error out since NodeType doesn't exist anymore.

Clearly the simple "replacing it with a derived class" isn't going to work. Attached is a patch that will restore broken sites in D9. However, if you upgrade to D10, without upgrading your condition classes first, it will break.

The 9.2 changes were removed in the subsequent commit, which 3.10 is release with. I don't think I missed anything?

The following patch goes a bit further, renaming EntityBundleConstraint back to EntityBundle, which removes the need to deprecate EntityBundle and simplifies the info_alter hook.

This causes some more unused code, and have added deprecation notices to them.

Either patch should fix the immediate error. Only question now is whether the removal of EntityBundleConstraint is a BC break too or if it's OK because it only existed for a few days ;)

And yes, repeating myself again as well for extra clarity for everyone who ends up here (context is #39, see instructions there or if you maintain a module/distribution with pathauto default config, see the referenced varbase issues and related discussion in #2925169: PluginNotFoundException: The "node_type" plugin does not exist):

Reminder: If your site broke now, it would have broken in D10 even without this problem. You might have the same problem with core block config definitions if you use node type conditions, double-check block.* files as well and adjust accordingly.

Or alternatively, you were using an old version of pathauto like #40. In that case, just update.

Thanks to @DamienMcKenna in #39, editing the pathauto.*.yml and view_mode_page.*.yml config files fixes the issue.

Just change the id in selection_criteria :

selection_criteria:
  52aa3b60-2f7c-43fe-a03d-6d09e1d4fd17:
    id: node_type

to

selection_criteria:
  52aa3b60-2f7c-43fe-a03d-6d09e1d4fd17:
    id: 'entity_bundle:node'

Updated Issue Summary for main points from the discussion, primarily Berdir's points to make it explicit how to resolve this.

What remaining steps do we have on this? I need to update the IS for remaining tasks, but I'm not sure if there's anything left to do?

@webbeh we should probably update the release notes for 3.10 and 4.0.1 to call out the change from node_type to entity_bundle.

Fixed mine using technique in #45.

It works for me when going back to version 3.9.0

After consulting with berdir and some other ctools maintainers, I've updated the patches to do the following:

1) Rename EntityBundleConstraint introduced in 3.10 back to EntityBundle. Its extra code thats not needed. If someone managed to a) depend on this class directly and b) do it in 72hours... I expect you'll be able to fix it again ;)

2) Took the NodeType class from core and put it into ctools 3.x. This will avoid the issue @berdir suggested in comment #37 where D10 upgrades would fail due to the missing class. This allows users using the 3.x version of ctools to upgrade to d10 without this bug occuring. Users will have to update their code before ctools 4.1.0, but this is a bigger update in the ctools ecosystem which will require other testing as well, including page manager.

3) Simplified the condition_info_alter hook and added the NodeType annotation there instead of in the plugin. There was some concern that duplicate plugin ids would conflict if they had the same annotation. This way we can manually insert it in D10+ when NodeType doesn't exist in core.

+++ b/ctools.module
@@ -90,22 +92,28 @@ function template_preprocess_ctools_wizard_trail_links(&$variables) {
+  // BC Layer Shim for Drupal 10. Remove before ctools 4.1.0.
+  else if (!isset($definitions['node_type'])) {
+    $definitions['node_type'] = [
+      'context_definitions' => [
+        'node', new EntityContextDefinition("entity:node", t("Node"))
+      ],
+      'id' => 'node_type',
+      'label' => t('Node Bundle (Deprecated)'),
+      'class' => NodeType::class,
+      'provider' => 'ctools'
+    ];
   }
 

I don't understand this part. node_type only exists in D9, and the check above ensures that it's only replaced if it exists, in D10 this will simply not do anything. If the class would be loaded it would fail, but it won't be as the condition plugin no longer exists.

If you want to be careful for phpstan you could define a if !class exists above it in the file so that loading the file is a no-op.

But by duplicating it you cause the opposite problem of what this issue does right now. You delay breaking their old configuration using the node_type condition and then it will break when they update to ctools 4.

Thanks for the review!

I don't understand this part. node_type only exists in D9, and the check above ensures that it's only replaced if it exists, in D10 this will simply not do anything. If the class would be loaded it would fail, but it won't be as the condition plugin no longer exists.

+ else if (!isset($definitions['node_type'])) {

This should fire if the 'node_type' definition doesn't exist, which is in the case of Drupal 10. It adds back the node_type definition so conditions will load properly. (Supposedly, according to Eclipsegc, this condition_info_alter hook occurs during the discovery phase so any plugin configurations depending on node_type should load successfully, even in D10.

Yes, duplicating node_type does kick the can down the road. However, the argument l am making is its probably better that we support the legacy condition in ctools to ease the upgrade to Drupal 10. The 4.1.x branch of ctools will take longer (which means less likely people are using the legacy condition) and will try to include an upgrade path for contexts but may require users to manually update custom code and config. Since they're already having to update their config, we add a bit ensuring node_type is renamed as well.

We also have the option in subsequent 3.x releases to create a warning to users that use the deprecated node_type condition in the UI.

Sorry, that wasn't clear. I understand what the code is doing. Just not why or maybe even clearer, don't agree with your argument I guess.

I don't think that ctools can provide an upgrade path. drupal core provided an upgrade path for blocks, its only use of condition plugins. pathauto did it for its config entities. If another module like panels uses condition plugins in their config entities then those modules must provide an upgrade path. ctools/the condition plugin system can't know about that. That's what https://www.drupal.org/node/2983299 has documented.

Maybe you could do some creative discovery based on config schemas and which config schema uses condition plugins, but there's not even a guarantee that it's limited to config. Commerce uses conditions on content entities (although its own condition system AFAIK) for example.

IMHO it's not ctools job to postpone that removal/deprecation. One problem is the special logic in core that conditionally hides/alters the deprecated node_type plugin. That actually wasn't removed yet in \Drupal\block\BlockForm::buildVisibilityInterface(), but it should have been and will be at some point, which will cause the deprecated option to show up again. Also, while testing that, I actually realized that the current context_definitions entry is broken, you define two array values instead of key => value. This causes a fatal error right now on the Block UI but there are no tests for any condition UI's in this module.

Rerunning pathauto_update_8108() and exporting the settings worked for me with 3.10

#55 do the work with 4.0.1

drush pmu pathauto
composer remove drupal/pathauto
composer require drupal/pathauto
drush en pathauto
drush cr

Works for me

@R3m that "drush pmu pathauto" looses all your pathauto settings... so it is not good advice for other users...

I encountered this issue in relation to the View Mode Page module (v 4.0.1), which creates pattern-based aliases to show different view modes. Those aliases no longer work. The view mode page configuration notes that the node bundles are (deprecated) but not that they will fail. A brainless fix based on #39 was to replace 'node_type' with 'entity_bundle:node' in /view_mode_page/src/Form/PatternEditForm.php (3 replacements). I then deleted the old aliases and replaced them. So far so good.

Yes, someone else mentioned that module too. The situation is the same.

That it fails now is a ctools bug that is being fixed by the patches here. But it will fail in D10 and that module should add an update function for its config and hide the deprecated option if not in use to prevent using it As part of preparing for D10. I suggest that you create an issue there.

This issue and the error also affects all of the migrations I've built. Any attempt to issue a new import or update throws the error highlighted in the OE ticket.

Migrate core 9.4.5
migrate_devel 2.x-dev
migrate_manifest ^3
migrate_plus ^5.1
migrate_process_entity ^1.0
migrate_report ^1.0
migrate_scanner 1.0.0
migrate_skip_on_404 ^1.0
migrate_source_csv ^3.4
migrate_source_ui ^1.0@RC
migrate_tools ^5.1
migrate_upgrade ^3.2
migration_tools ^2.4

Running Ctools 3.10

Reverting to Ctools 3.9.0 resumes operation.

@emptyvoid: applying the patch in #50 got migrations working for me.

Removing pathauto info from the IS and documented in #2925169-12: PluginNotFoundException: The "node_type" plugin does not exist. It is awkward to have pathauto-related fixes in a ctools issue, and can minimize searchability of this fix.

Updated IS for where we're at, requesting additional feedback and testing on #50. Also added tests given the feedback from Berdir on this.

I've pushed up the recommended patch in #43 to 3.x and have made a new RC release for people to test with composer. Upgrade to 3.11-rc1 and report back issues here. After a few days I'll make a full release of 3.11 which should fix this issue.

Thanks @japerry, looking forward to 3.11 "soon"

Tested with "drupal/ctools": "3.11-rc1"

But faced the following error with updated configs

Drupal\Component\Plugin\Exception\PluginException: Plugin (entity_bundle:node) instance class "Drupal\ctools\Plugin\Condition\EntityBundleConstraint" does not exist. in Drupal\Component\Plugin\Factory\DefaultFactory::getPluginClass() (line 97 of ###########/core/lib/Drupal/Component/Plugin/Factory/DefaultFactory.php).

Considering using the 4.0.x branch (4.0.1) , but #3293825: Update Chaos Tool Suite (ctools) module compatibility from ^3.1 to ~3.0 || ~4.0 maybe is needed or a new branch ( 5.0.x ) for the Page Manager module.

To have all new updated configs work with entity_bundle:node
Or the 8.x-3.x branch should support that, or no longer supports that in the next stable release.

Rajab: Did you rebuild the site caches after you updated to 3.11-rc1?

3.11-rc1 solved it for me, thanks so much for the quick turnaround ! 4.0.x doesn't work for me using D9.4.5

You are right Damien.

Thanks for the note!

• Tested on a new install with 3.11-rc1
• Automated testing for 160 scenarios (158 passed, 2 failed) .. 2 failed related to Entityqueues context with nodes
• Tested the update with 3.11-rc1

Before I had 160 scenarios (134 passed, 26 failed)

Using "drupal/ctools": "3.11-rc1"
composer update
drush cr

Now after clearing the cache and re-testing, I have 160 scenarios (160 passed, 0 failed)

Thank you :)
To me, it feels safe to release 3.11 stable

@Berdir thanks for the explanation, but Pathauto 8.x-1.11 still requires pathauto in its composer.json although no longer in its info file: https://git.drupalcode.org/project/pathauto/-/blob/8.x-1.11/composer.json

Maybe it should be removed from there too ?

@fgm: That's on purpose - you can't uninstall a module from Drupal if the files aren't present, so removing CTools from Pathauto's composer.json would have caused more problems than it solved.

Yes exactly. That also happens to be documented in detail on the release node: https://www.drupal.org/project/pathauto/releases/8.x-1.11.

Thanks for the details. I usually check such removals to do two-step updates, but this is nicer indeed.

Thanks @japerry! I was able to upgrade to 3.11-rc1 and edit my site without any issues.

Thank you, Jakob for releasing the fix in 3.11-rc1
Tested. It's working well.

With ctools 4.0.1 I get this error:

php-error <server> <datetime> Uncaught PHP Exception Drupal\Component\Plugin\Exception\ContextException: "The context is not a valid context." at /mnt/www/html/<site>/docroot/core/lib/Drupal/Core/Plugin/ContextAwarePluginTrait.php line 184 request_id="v-<id>"

Downgrading to 4.0.0 with
"drupal/ctools": "4.0.0" in composer.json

Then it works, using Drupal core version 9.4.5 and PHP 7.4.30

Edit: #27 is a better way to resolve this issue.

You shouldn't be using the ctools 4.x branch, its unsupported. I'll make sure to add a note in the 4.0.2 release notes, which will bring forward this patch. and add a warning to 'downgrade' to 3.11.

@japerry , perhaps unpublish the 4.x releases and delete the 4.x branch if possible?

Hi! To avoid removing pathauto patterns I've fixed this by adding pathauto_update_8108() in hook_update or hook_install, like this

function mymodule_install($is_syncing) {
  if (!$is_syncing && \Drupal::moduleHandler()->moduleExists('pathauto')) {
    // Code from pathauto_update_8108().
    foreach (\Drupal::configFactory()->listAll('pathauto.pattern.') as $pattern_config_name) {
      $pattern_config = \Drupal::configFactory()->getEditable($pattern_config_name);
      if ($pattern_config->get('type') === 'canonical_entities:node') {
        $selection_criteria = $pattern_config->get('selection_criteria');
        foreach ($selection_criteria as $uuid => $condition) {
          if ($condition['id'] === 'node_type') {
            $pattern_config->set("selection_criteria.$uuid.id", 'entity_bundle:node');
            $pattern_config->save();
            break;
          }
        }
      }
    }
  }
}

Facing error with:
Drupal\Component\Plugin\Exception\ContextException : The context is not a valid context. dans Drupal\Core\Executable\ExecutablePluginBase->getContextDefinition() (ligne 184 de /home/xx/www/xxx/sited9/web/core/lib/Drupal/Core/Plugin/ContextAwarePluginTrait.php).
that give a WSOD on editing node page.

Fixed by reverting ctools from 4.x to 3.x

 - Downgrading drupal/ctools (4.0.1 => 3.11.0): Extracting archive

 -------- ---------------- ------------- -------------------------------------
  Module   Update ID        Type          Description
 -------- ---------------- ------------- -------------------------------------
  ctools   remove_entitybundleconstraint   post-update   Invalidate the service container to force EntityBundleConstriant is Removed.

It took me a while to understand what is written here, but https://www.drupal.org/project/ctools/issues/3300682#comment-14637093 (credit to many others in this thread as well) appears to be the best way foreward.

Example config: config/sync/pathauto.*.yml

before:

uuid: 6d42db91-c54a-4f7f-ad89-568bf2f4ff44
langcode: de
status: true
dependencies:
  module:
    - node
_core:
  default_config_hash: 4pZ5yAeIUVx5jlotE2RgyqSdDx3G-Jr8vnQL6c4yHRY
id: page
label: Seite
type: 'canonical_entities:node'
pattern: '[node:menu-link:parent:url:path]/[node:title]'
selection_criteria:
  c7356ded-00a4-424c-8c38-c9ce15d09b24:
    id: node_type # <-- this needs to change
    negate: false
    uuid: c7356ded-00a4-424c-8c38-c9ce15d09b24
    context_mapping:
      node: node
    bundles:
      page: page
  a8ba3b23-472d-4122-825f-e6d34dbbda95:
    id: node_type # <-- this needs to change
    negate: false
    uuid: a8ba3b23-472d-4122-825f-e6d34dbbda95
    context_mapping:
      node: node
    bundles:
      page: page
selection_logic: and
weight: -5
relationships: {  }

After:

uuid: 6d42db91-c54a-4f7f-ad89-568bf2f4ff44
langcode: de
status: true
dependencies:
  module:
    - node
_core:
  default_config_hash: 4pZ5yAeIUVx5jlotE2RgyqSdDx3G-Jr8vnQL6c4yHRY
id: page
label: Seite
type: 'canonical_entities:node'
pattern: '[node:menu-link:parent:url:path]/[node:title]'
selection_criteria:
  c7356ded-00a4-424c-8c38-c9ce15d09b24:
    id: 'entity_bundle:node'
    negate: false
    uuid: c7356ded-00a4-424c-8c38-c9ce15d09b24
    context_mapping:
      node: node
    bundles:
      page: page
  a8ba3b23-472d-4122-825f-e6d34dbbda95:
    id: 'entity_bundle:node'
    negate: false
    uuid: a8ba3b23-472d-4122-825f-e6d34dbbda95
    context_mapping:
      node: node
    bundles:
      page: page
selection_logic: and
weight: -5
relationships: {  }

Then run the import again and if you're lucky the issue will be gone.

Patch #50 worked for me.
Here is the same version with the first comments removed

Same problem upgrading pathauto to 8.x-1.11 and ctools to 4.0.1 on Drupal 9.3.13. Fixed downgrading ctools to 8.x-3.11

So please correct me here if I'm wrong, but the solution is to MANUALLY change config files? There is no way it can be solved with the update script in the ctools module? Isn't that the standard procedure?

Yes #88. That is correct. In my case I had to change in every pathauto.pattern.*.yml file
the string id: node_type
to the string id: 'entity_bundle:node'
And then import the yml files using drush cim
After that creation of nodes was working again.

Thanks a lot @pierregermain for your last comment, it really helped clarifying the change needed in config files.

I would like to gladly confirm as well the solution described at #85 fixed our issue.

Tested with:

• Drupal: 9.4.8
• Chaos tools: 4.0.1
• Pathauto: 1.11.0
• PHP: 7.4

We encountered the same fatal error with the following stack trace, which led to this ticket:

Drupal\Component\Plugin\Exception\ContextException: The context is not a valid context. in Drupal\Core\Executable\ExecutablePluginBase->getContextDefinition() (line 184 of core/lib/Drupal/Core/Plugin/ContextAwarePluginTrait.php).
Drupal\Core\Executable\ExecutablePluginBase->getContext(NULL) (Line: 116)
Drupal\Core\Executable\ExecutablePluginBase->getContextValue(NULL) (Line: 91)
Drupal\Core\Entity\Plugin\Condition\EntityBundle->evaluate() (Line: 77)
Drupal\Core\Condition\ConditionManager->execute(Object) (Line: 84)
Drupal\Core\Condition\ConditionPluginBase->execute() (Line: 376)
Drupal\pathauto\Entity\PathautoPattern->applies(Object) (Line: 321)
Drupal\pathauto\PathautoGenerator->getPatternByEntity(Object) (Line: 41)
Drupal\pathauto\PathautoWidget->formElement(Object, 0, Array, Array, Object) (Line: 353)
Drupal\Core\Field\WidgetBase->formSingleElement(Object, 0, Array, Array, Object) (Line: 220)
Drupal\Core\Field\WidgetBase->formMultipleElements(Object, Array, Object) (Line: 111)
Drupal\Core\Field\WidgetBase->form(Object, Array, Object) (Line: 181)
Drupal\Core\Entity\Entity\EntityFormDisplay->buildForm(Object, Array, Object) (Line: 121)
Drupal\Core\Entity\ContentEntityForm->form(Array, Object) (Line: 127)
Drupal\node\NodeForm->form(Array, Object) (Line: 106)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 531)
Drupal\Core\Form\FormBuilder->retrieveForm('node_section_index_edit_form', Object) (Line: 278)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 97)
Drupal\autosave_form\Form\AutosaveFormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 564)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 159)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 709)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

 
After taking a closer look at the pathauto pathauto.pattern.*.yml config files, we found a remaining instance of node_type in one of the config files.

Replacing with 'entity_bundle:node' seems to have fixed the problem, just as described at #89 and initially suggested at #85.

Note this works whether importing the pattern through the backend from /admin/config/development/configuration/single/import or through drush cim.

In all cases, as soon as the active configuration is updated, the error disappears and the problem is fixed.
 

Getting back to #88, this could indeed most likely be fixed as well with a hook_update in the pathauto or ctools modules and code contributions would surely be greatly appreciated.

Any additional feedback, questions, comments, suggestions or code contributions would be welcome.
Thanks again for sharing the solution to the issue.

Hi,

So @pierregermain, to fix this issue with pathauto, we need to patch the ctools module in v 3.11 or 3.x ? If yes, which patch ?
Then edit manually config files about pathauto and reimport them ?

Thanks

F.S

ok I upgraded ctools to 4.0.3 and same behaviour for pathauto. It appears that certain content type doesn't create alias automatically because the box is uncheked...but I don't find where I can set this by default...

Patch #57 worked for me.

If it is not too much work... you can manually remove and recreate your Pathauto patters.

@schoenef thanks! For me #85 was the simplest solution.