seantwalsh → credited weekbeforenext → .
johnpicozzi → credited weekbeforenext → .
johnpicozzi → credited weekbeforenext → .
markie → credited weekbeforenext → .
Updated the branch for Merge Request 1 to fix merge conflicts upstream. Looks like I screwed up my git config for Drupal.org to find my account.
weekbeforenext → made their first commit to this issue’s fork.
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
Moved this issue to the MOSA project.
seantwalsh → credited weekbeforenext → .
weekbeforenext → created an issue.
Digging a little more into the code from #3469550 I'm understanding that I can revoke the "Create translations", "Delete translations", and "Edit translations" and leave the "Manage translations for any entity that the user can edit" permission enabled to get the functionality to work as I expect it to...
My bad. Closing this, but I hope it helps others that run across this issue.
weekbeforenext → created an issue.
The tests that are failing are tests I added. I will try to circle back to this on my own time.
mherchel → credited weekbeforenext → .
weekbeforenext → created an issue.
New config to indicate whether the site allows mixed-case paths or lowercase only. Based on that indicator, we ensure redirects aren't created that cause redirect loops. I think a similar functionality was available in the Drupal 7 version, so I went this route.
I don't know the history of not including it for D8+, so happy to pivot to another path that protects us against redirect loops.
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
markie → credited weekbeforenext → .
Made some updates to the update hook because it's not working on my site, but also continues to not work on my site.
The original issue I experienced was an alias was changed, only capitalizing some letters. When this happened, a redirect was created from a completely lowercase version to a mixed-case version and caused a redirect loop.
Aside from the update hook not setting the new config value, my updates do allow for toggling between allowing mixed-case URLs in redirects and aliases and working only with lower case URLs.
Notes
In thinking about possible validation and checking if there are already aliases or redirects with mixed-case, a query like this seems to work:
select * from path_alias where alias regexp binary '[A-Z]';
I would like some input on the direction I'm heading before I add more functionality and tests.
This functionality seemed to be important enough to be included in the main module. My site doesn't use the redirect_domain sub module, so I created MR !102 working towards a main module solution.
Next steps:
- Manual testing
- Review/fix pipeline issues
- Write tests
I opted to set the new config value to false if the module is newly installed, but to true if the module is being updated. This is because a site could have mixed-case aliases and redirects and I don't want it to break functionality. I guess this isn't completely foolproof because a site can have aliases before enabling this module.
Thinking "out loud"
An additional feature when toggling the case-sensitivity off or updating the module might be to check if the site does have mixed-case URLs and provide a log message. We could provide a validation error that doesn't allow the user to toggle the option off if there are paths that would be affected. Maybe a batch update feature, if one doesn't already exist.
weekbeforenext → made their first commit to this issue’s fork.
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
seantwalsh → credited weekbeforenext → .
Looking back at #8, our site does have at least one other access control module installed which could be causing the issue for us.
I was able to build off the work in #2856720 and add conditions to handle entity_browser_forms. If you aren't referencing the 4.x-dev version, you'll need the patch from that issue.
Attached is a video comparing the conditional fields functionality of a standard inline entity form and one in an entity browser.
The recent work requires the patch from #2856720 so I'm relating that issue.
weekbeforenext → changed the visibility of the branch 3063335-support-for-entity to hidden.
weekbeforenext → made their first commit to this issue’s fork.
volkswagenchick → credited weekbeforenext → .
seantwalsh → credited weekbeforenext → .
Needs tests :/
Uploading my changes as a patch to run tests.
I was experiencing the same issue. The domain_access_node_access() hook implementation never checks to see if the content should be accessible on the active domain.
I updated the fork with the latest from origin and added some logic, similar to domain_entity, to forbid access if the active domain is not checked in the domain access field, or the all affiliates field is not checked.
I assume setting this back to "Needs review" will kickoff tests. I am reviewing tests to see if we can add one specific to this case.
weekbeforenext → made their first commit to this issue’s fork.
volkswagenchick → credited weekbeforenext → .
Resolved merge conflicts in the MR, then realized that the patch from #35 applies to 10.2.4. :shrug:
weekbeforenext → made their first commit to this issue’s fork.
volkswagenchick → credited weekbeforenext → .
Re-rolled the patch from #27 for dev-4.x.
#27 applies to 4.0.0-alpha5, but not the dev branch.
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
seantwalsh → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
froboy → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .
volkswagenchick → credited weekbeforenext → .