This module is blocking node_view access of modules that need to loop through all nodes.

An example of module that does not work with Content Language Access is XML sitemap, but probably Search module from core will face this problem too.

Steps to reproduce:

  • Create nodes with different languages
  • Configure XML sitemap module to create xmlsitemaps for all languages
  • Generate the XML sitemaps
  • XML sitemap will be generated correctly only for the current language you are using.
Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

rodrigoeg created an issue. See original summary.

rodrigoeg’s picture

Version: 7.x-1.x-dev » 8.x-1.x-dev
Issue tags: +Needs backport to D7

Upgrading issue to 8.x, but once a solution was found we need to backport it to D7

leon kessler’s picture

I'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.

leon kessler’s picture

I'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).

slv_’s picture

Hi! 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).

luisnicg’s picture

I'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.

rafmagsou’s picture

Deprecated 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

rafmagsou’s picture

Update 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

fabsgugu’s picture

Status: Active » Reviewed & tested by the community

This patch work for me.

parisek made their first commit to this issue’s fork.

parisek’s picture

rafmagsou, thank you for patch, I opened MR should be easier for mainainer to fix it.

  • rodrigoeg committed 4f38385f on 2.x authored by parisek
    Issue #2672542: Problems when some module uses node_view for index nodes
    
rodrigoeg’s picture

Status: Reviewed & tested by the community » Fixed
Issue tags: -Needs backport to D7

Thanks, 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

Status: Fixed » Closed (fixed)

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