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
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | new_pattern_types_don_t-2809447-19.patch | 4.34 KB | berdir |
| #19 | new_pattern_types_don_t-2809447-19-test-only.patch | 1.34 KB | berdir |
| #14 | new_pattern_types_don_t-2809447-14.patch | 3 KB | jaykandari |
Comments
Comment #2
joachim commentedComment #3
berdirCan'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.
Comment #4
berdirOk, 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.
Comment #5
darrenwh commentedI can replicate this too, starting investigation
Comment #6
darrenwh commentedFreeing up ticket
Comment #7
darrenwh commentedUpdating description
Comment #8
jaykandariComment #9
jaykandariCreated an event subscriber which clears fielddefinition.
Removed cache clearing logic from submitForm() as given in issue description.
Kindly Review! Thanks !!
Comment #10
jaykandariComment #11
darrenwh commentedThat works,
Enabling module, user shows up without adjusting settings page on Add pathauto pattern page.
Comment #12
berdirHere 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
Comment #13
jaykandariComment #14
jaykandariHi @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/addit has 3 values initially.- So, which two values to check to confirm our test case.
Thanks!
Comment #15
berdirI need to have a look at this myself. Thanks for the patch, will try to test this next week.
Comment #17
jaykandariRe ran the test, it passed.
Comment #18
darrenwh commentedComment #19
berdirHere'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.
Comment #22
berdirCommitted, thanks everyone.