Problem/Motivation

I've enabled User entities under 'Enabled entity types' at admin/config/search/path/settings, but at admin/config/search/path/patterns/add I still don't see User as an option for patterns.

It looks like the problem is to do with caching: I enabled a new module (Plugin module, so I could debug this ;) and the new type now shows at admin/config/search/path/patterns/add.

So it looks like the settings form isn't clearing the plugin definitions cache for the alias_type plugins.

Proposed resolution

The logic in \Drupal\pathauto\Form\PathautoSettingsForm::submitForm() needs to move to a config save event subscriber, similar to \Drupal\redirect\EventSubscriber\RedirectSettingsCacheTag.

Remaining tasks

Write event subscriber as above.

User interface changes

none

API changes

none

Data model changes

none

Comments

joachim created an issue. See original summary.

joachim’s picture

Title: can't add patterns for users. » new pattern types don't show after saving settings form
Issue summary: View changes
berdir’s picture

Status: Active » Postponed (maintainer needs more info)

Can't reproduce this. Went to the add form first, then visited the settings page enabled one (Poll in my case), went back to add and it was shown by default.

We also have \Drupal\pathauto\Tests\PathautoEnablingEntityTypesTest::testEnablingEntityTypes that works without a cache clear. It doesn't use the UI to create the type, feel free to change that if you think that might make a difference.

berdir’s picture

Status: Postponed (maintainer needs more info) » Active
Issue tags: +Novice

Ok, was able to reproduce this kind of after a new install but actually not exactly like you said.

After a clean install, user is already enabled in the settings. But it doesn't show yet. Saving after checking another then works.

The reason is then that we only clear the cache in the UI when the types actually change. I think user was already enabled in your case.

The logic in \Drupal\pathauto\Form\PathautoSettingsForm::submitForm() needs to move to a config save event subscriber, similar to \Drupal\redirect\EventSubscriber\RedirectSettingsCacheTag.

darrenwh’s picture

Assigned: Unassigned » darrenwh
Issue tags: +mssprintjan17

I can replicate this too, starting investigation

darrenwh’s picture

Assigned: darrenwh » Unassigned

Freeing up ticket

darrenwh’s picture

Issue summary: View changes

Updating description

jaykandari’s picture

Assigned: Unassigned » jaykandari
jaykandari’s picture

Status: Active » Needs review
StatusFileSize
new2.8 KB

Created an event subscriber which clears fielddefinition.
Removed cache clearing logic from submitForm() as given in issue description.

Kindly Review! Thanks !!

jaykandari’s picture

Assigned: jaykandari » Unassigned
darrenwh’s picture

Status: Needs review » Reviewed & tested by the community

That works,
Enabling module, user shows up without adjusting settings page on Add pathauto pattern page.

berdir’s picture

Status: Reviewed & tested by the community » Needs work
+++ b/src/Form/PathautoSettingsForm.php
@@ -260,12 +260,6 @@ class PathautoSettingsForm extends ConfigFormBase {
 
-    // Clear cached field definitions if the values are changed.
-    if ($original_entity_types != $config->get('enabled_entity_types')) {
-      $this->entityFieldManager->clearCachedFieldDefinitions();
-      $this->aliasTypeManager->clearCachedDefinitions();
-    }
-

Here we had logic that the settings actually changed, that means we're now doing more cache clears than we need to.

We should be able to use https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Config%21... for that.

Also, a test would be great

jaykandari’s picture

Assigned: Unassigned » jaykandari
jaykandari’s picture

Status: Needs work » Needs review
StatusFileSize
new3 KB

Hi @Berdir,

I have updated the patch which checks for getOriginal() values of config.

Kindly help me here!
As far as writing test is concerned, I'm writing drupal test for first time. I have managed to write a test case, but problem I'm having here is to which values to assert as described below:

- When I try to check default values of $this->config('pathauto.settings') it shows an array with single value "node" in it.
- There are two default values(Content & Taxonomy) are already checked in settings page.
- And, when we navigate to /admin/config/search/path/patterns/add it has 3 values initially.
- So, which two values to check to confirm our test case.

Thanks!

berdir’s picture

I need to have a look at this myself. Thanks for the patch, will try to test this next week.

Status: Needs review » Needs work

The last submitted patch, 14: new_pattern_types_don_t-2809447-14.patch, failed testing.

jaykandari’s picture

Assigned: jaykandari » Unassigned
Status: Needs work » Needs review

Re ran the test, it passed.

darrenwh’s picture

Issue tags: +Needs tests
berdir’s picture

Here's a test for this, by using the API to change the settings and verify that the things were updated that need to.

Reproducing in the UI is complicated I think.

The last submitted patch, 19: new_pattern_types_don_t-2809447-19-test-only.patch, failed testing.

The last submitted patch, 19: new_pattern_types_don_t-2809447-19-test-only.patch, failed testing.

berdir’s picture

Status: Needs review » Fixed

Committed, thanks everyone.

  • Berdir committed 163ac34 on 8.x-1.x authored by JayKandari
    Issue #2809447 by JayKandari, Berdir: new pattern types don't show after...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.