🇳🇱Netherlands @Marceldeb

Hi Pedro,

I just cleared cache and all works again. Thanks!

Marcel

Hi Pedro,

I am upgrading from 2.30. When going to a newer version, this error will occur. I can't flush caches using the interface, because the entire website is blocked because of the white error screen.

I will try to flush using command line and report back. Thanks for your reply so far.

Marceldeb → created an issue.

Thanks, i applied the patch as it works the same way in the 3.x.x release.

I will create a new release for 8.x-2.x branch but i recommend upgrading to 3.x.x.

Released in version 3.0.1

Patch attached. The error was in the javascript. It only occured when using 'shared fields' acros multiple node bundles.

I fixed the javascript so it re-selects the correct field.

Hi again,

I was able to reproduce the issue. Will come back with a fix asap!

Hi,

Thanks for reporting. I could not find an issue in the code that generates the form.

Which Drupal version are you on?

Tested on Drupal 9.5.5

Drupal\Core\File\Exception\NotRegularDirectoryException: private:// is not a directory. in Drupal\Core\File\FileSystem->scanDirectory() (line 665 of core/lib/Drupal/Core/File/FileSystem.php).

Hi,

Thanks for you elaboration and I'm leaving this open until I've updated the readme / project description a bit more. I understand what you mean.

I'm used to having the https://www.drupal.org/project/node_view_permissions → module also active. This modules work great together with access_by_ref. By using node_view_permissions you can solve the missing separated bundle view permissions you are talking about. And then you can solve the situation that all published nodes are always accessible because of permissions.

I actually forgot you need a separate module for that :-D

Hello Anybody,

I think you are partly right. In the use case you are describing you have to make sure you have your permissions set up correctly.

So, let's say the content type of your special page you want to display only to specific users is called 'special_content_type'.

Then you should not give permission to anonymous users to view this kind of nodes. This is Drupal native functionality in core/permissions administration screen. Because if you give access to anonymous users to view your 'special_content_type' this wil (obviously) interfer with this module. By setting this permission, all anonymous users will be indeed allowed to access the node. That's how the Drupal permission screen works. So to solve your case you do not set the permission for the anonymous user to view your 'special_content_type' in the Drupal permission administration screen.

You only configure this module to give access when a user is referenced in the specific node. Job done!

I'm not sure why you would want to give access to anonymous users using this specific module? This use case is indeed not supported. I also don't see a valid use case for that?

Thanks, this makes it clearer for those that did not read this in the readme ;-)

In each case, the rule only applies to logged-in users with general permission
to access nodes by reference, and only on the node types and field names set in
the configuration page.

Merged in 3.x.x dev

I checked my config to see what changed after my above fix. It seems that the query tags were first saved as object in the database, and now as an null.

So the bug is in the Drupal config which changed..and probably during upgrades core devs forgot to handle this.

See image.

I could not reproduce this issue but i would like to share a fix. Apparently something in the database is not correct in some of the views / displays.

How to fix:

319 of core/modules/views/src/Plugin/views/query/Sql.php:

    $form['query_tags'] = [
      '#type' => 'textfield',
      '#title' => $this->t('Query Tags'),
      '#description' => $this->t('If set, these tags will be appended to the query and can be used to identify the query in a module. This can be helpful for altering queries.'),
      '#default_value' => implode(', ', $this->options['query_tags']),
      '#element_validate' => ['views_element_validate_tags'],
    ];

Then remove the following line:

      '#default_value' => implode(', ', $this->options['query_tags']),

Open your display / view. Open the query settings. Re-save the view.

Now restore the 319 of core/modules/views/src/Plugin/views/query/Sql.php back to original state.

My guess is that for some reason $this->options['query_tags'] sometimes returns a string. Which is strange because in my case the value was empty. Maybe something old in the database? Who knows. I did a check using kint($this->options['query_tags']) and the value was empty / null.

Anyway, i did not see any bug in the Drupal code.

Closing this issue, seems to be a core issue and not related to this module.

https://www.drupal.org/project/drupal/issues/3292763#comment-14973267 🐛 TypeError: implode(): Argument #1 ($pieces) must be of type array, string given in implode() Postponed: needs info

Subscribing. Having the same issue.

i also upgraded the Drupal version and php version (from 7.x to 8.x). Currently on Drupal 9.5 and still having the issue.

On my site only the REST Export view type seems to be affected.

This one is fixed in both the 8.x-2.x branch and the 8.x-3.x branch (3.0.0).

Released in 8.x-2.1 and 3.0.0

Sure, hit me up with that patch and I will look into it!

Thanks,
Marcel

Version 8.x-2.x is D9 compatible.

I created a tag for 3.0.0 version based on the 9.x-3.x branch. That version is now also released.

Closing this request because it is implemented in 8.x-2.x.

We will not implement this in the 7.x branch as 7 is outdated.

Changes are added to the new 8.x-3.x branch because these changes will no longer work with Drupal 8.

I did some basic testing on Drupal 9 and all seems to work fine. Would be nice to have some more testing done.

Thanks again for all the commits. I made one small javascript change to make sure 'old' filled in values are not saved. When the the 'extra field' and the 'item rights type field' were hidden, their values would still be saved. This would lead to an overview screen that is not entirely correct. This bug was already present in the 8.x-2.x branch but i ran into it doing some tests on your changes.

Changes are added to the new 8.x-3.x branch because these changes will no longer work with Drupal 8.

I did some basic testing on Drupal 9 and all seems to work fine. Would be nice to have some more testing done.

You are right. I can't seem to change it. Probably a rights issue. I've contacted the original creator of this module.

Thanks a lot, i will create a new release after i did some testing!

Marceldeb → created an issue.