Download the PHP package faithcatholic/custom_node_access without Composer
On this page you can find all versions of the php package faithcatholic/custom_node_access. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download faithcatholic/custom_node_access
More information about faithcatholic/custom_node_access
Files in faithcatholic/custom_node_access
Package custom_node_access
Short Description Adds option for page access by role
License GPL-2.0+
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package custom_node_access
Custom Node Access
Custom Node Access lets an editor restrict who can view a single node by
picking user roles on the content form. The selection is stored in a field the
module provides, and turned into node access grants through core's node grants
system, so a restricted node disappears from listings and views for everyone
outside the selected roles, not just from its own page. A node with no roles
selected stays unrestricted. The module also grants authenticated users view
access to nodes while /system/files is being served, so private files
embedded in a restricted node still load.
Requirements
Drupal 10.3 or later, or Drupal 11. Core's Node and Field UI modules, nothing from contrib.
The module does nothing on its own. It expects a field to exist on every content type you want to control:
- Field type Access (
access_type), provided by this module. - Machine name
field_access, exactly. The name is hardcoded in the grants hook and in the widget's#statesselector, so a field with any other name is ignored without an error. - Cardinality 1. Only the first value is read.
Grant the Edit custom node access permission to any role that should see the setting on the content form.
Installation
Enable at /admin/modules, or drush en custom_node_access.
Then add the field_access field described above to each content type you want
to restrict. Without it the module is inert, which is the usual reason it looks
like it does not work on a fresh install.
Usage
- Go to Manage fields on a content type, add a field of type Access, and set
the machine name to
field_access. Keep the default settings. - Edit a node. Users with the Edit custom node access permission get a User role access section in the sidebar of the content form.
- Select one or more roles to limit who can view that node. Select none to leave it open to everyone. Roles flagged as admin roles are not offered, since they bypass node access anyway.
- Grants are written when the node is saved. If grants look stale, for example
after adding the field to an existing content type, rebuild them at
/admin/reports/statusor withdrush php:eval 'node_access_rebuild();'. - The field formatter renders the selected roles as a comma separated list of role labels, so you can show the restriction on the node if you want to.
Development
The repository is the module itself. DDEV builds a Drupal site around it:
web/ and vendor/ are ignored by git, and the module is symlinked into
web/modules/custom/custom_node_access.
ddev start runs the bootstrap in .ddev/post-start.sh: it fetches core and
dependencies with ddev poser, installs the site if the database is empty,
symlinks the project, enables Devel and this module, and prints a drush uli
login link. The account is admin with password 1.
Checks:
ddev phpcsandddev phpcbffor Drupal coding standards.ddev phpstan --level=6 -c ../../../../phpstan.neonfor static analysis. Pass the config explicitly. Plainddev phpstansymlinks the config into the module directory with a relative path that does not resolve, so it silently runs at level 0 with no configuration.
Add-ons in use: ddev-drupal-contrib, ddev-drupal-contrib-extras, ddev-drupal and ddev-pimp-my-shell.
Notes
- Grant IDs are derived from the role machine name: underscores are stripped,
the result is converted from base 36 to base 10, and the first five digits
are used. Two roles can therefore end up with the same grant ID, and
content_editorandcontenteditoralways do. Renaming a role changes its grant ID, so rebuild permissions after a rename. - The
/system/filesrule grants view access to any node for any authenticated user while that path is being served. It exists so private files embedded in restricted nodes keep loading. Keep it in mind if you rely on node access for anything else served from that path. - The three field plugins still use annotations rather than PHP attributes. Annotations are deprecated and will be removed in Drupal 12.
- The procedural hook functions in
custom_node_access.moduleare thin delegates kept for Drupal 10, which has no attribute based hooks. They can be deleted once the minimum supported version is Drupal 11.1. - The Drupal 10 path is untested. The delegates and the autowired service definition are there for it, but everything in this repository has only been run against Drupal 11.4.
CUSTOM_NODE_ACCESS_GRANT_ALLis defined but never used.
