Closed (fixed)
Project:
Content Language Access
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
20 Feb 2016 at 23:54 UTC
Updated:
19 Sep 2023 at 20:59 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
rodrigoeg commentedUpgrading issue to 8.x, but once a solution was found we need to backport it to D7
Comment #3
leon kessler commentedI've run into a similar issue (although with another module).
I think this is caused by the fact that
hook_node_access()does not pass through the language that we want to view the node in. So instead we assume it's the current site's language. Hence this in content_language_access on line #24:$language = \Drupal::languageManager()->getCurrentLanguage();Sometime's we will want to perform the view operation on a different language then the site's current one.
One possible solution would be to use hook_node_access_records instead. As this does support languages.
Comment #4
leon kessler commentedI've created a separate ticket for my issue. As although they are related, I think there may possibly be separate resolutions for each issue.
I also think using hook_node_access_records would be the wrong approach, as this is more based on account privileges and not regarding the specific contents of a node. Also it doesn't support other entity types, which I think we should do (another ticket maybe).
Comment #5
slv_ commentedHi! This also doesn't work when generating "hreflang" links for the
<head>section of pages. Content Translation module will check access to view the entities, which gets denied by content_language_access, resulting in hreflang links being omitted for anonymous users (or any user without the permission to see entities in a different language other than the current language).Comment #6
luisnicg commentedI've been facing the same issue with Simple Sitemap and XML site module, the node_access check is blocking the translated nodes from being indexed.
I was able to solved by removing the access check in a custom URL Generator using the Simple Sitemap module, but I have some sites that use the XML Sitemap module, so I created a patch to apply a bypass check if you are running a batch, cron or CLI process (still thinking the the last one is needed).
This option can be enabled during the content language configuration.
Comment #7
rafmagsou commentedDeprecated please use patch #8
Update the previews ideas, to resolve another issue related to file access by an anonymous user
- add a list of routes to be configured
- add a config manager service
- improvements in the logic
Comment #8
rafmagsou commentedUpdate fix patch #7 ( Consider user patch #8 instead)
Correct some comment problems to the last patch and additions:
- hook install to import routes for solution #6
- New route added "system". files to bypass validation of private file URLs
- Interdiff to the last patch #6 and the #8
Comment #9
fabsgugu commentedThis patch work for me.
Comment #12
parisekrafmagsou, thank you for patch, I opened MR should be easier for mainainer to fix it.
Comment #14
rodrigoeg commentedThanks, all!
Merged on branch 2.x (with a few adjustments: moved hook_update to hook_install, since the previous patch has never been pushed to the repository).
Removed that tag to backport to Drupal 7 because of low usage. In case someone needs backport, please submit a separate issue