🇺🇸United States @clayfreeman

clayfreeman → changed the visibility of the branch 3430739-manual-updates to active.

clayfreeman → changed the visibility of the branch 3430739-manual-updates to hidden.

clayfreeman → made their first commit to this issue’s fork.

clayfreeman → made their first commit to this issue’s fork.

clayfreeman → made their first commit to this issue’s fork.

I think I'm okay with this module acting after the page cache. We can't control page caching that happens outside of Drupal anyway, and I'd rather avoid introducing a discrepancy in behavior based on where the cached page comes from.

This module's restrictions are applied site-wide and do not target specific forms such as the registration and login forms. If you have any forms other than the registration and login forms that you want to allow an international audience to use, this module would not be a good fit for that use case.

Assuming you don't mind restricting form submissions on a site-wide basis, you can configure Geoblock's Applicable HTTP methods to suit your needs. If GET is not selected for this field, then Geoblock won't restrict an international audience from simply browsing the site.

Thanks for your contribution! I went ahead and tagged a patch release for this as well. Should be available for installation shortly.

I'm experiencing something similar. We had the comment module installed (via the standard install profile in Drupal core) and removed it recently because of the security advisory related to that module. This caused some roles to be updated to remove permissions that were provided by that module. As a result, views which used role-based access control and referenced a role that was updated were deleted. We were able to import these views without modification using Configuration > Development > Config synchronization > Import.

+++ b/src/Plugin/views/style/Zodiac.php
@@ -203,6 +211,12 @@ class Zodiac extends StylePluginBase implements ContainerFactoryPluginInterface
+        '#description' => $this->t('The text template used for the live region updates ...'),

Add punctuation to the end of this description.

I'm not sure if these test failures are real or not; they all pass locally except for GeolocationGeometryViewsBoundaryTest, which was already failing before I made any changes. Passing for review.

clayfreeman → created an issue.

clayfreeman → changed the visibility of the branch 3409805-allow-certain-entity to active.

clayfreeman → changed the visibility of the branch 3409805-allow-certain-entity to hidden.

clayfreeman → created an issue.

This issue introduces a major bug that breaks AJAX for form elements without a #submit key:

TypeError: in_array(): Argument #2 ($haystack) must be of type array, null given in in_array() (line 675 of /code/web/modules/contrib/token/token.module)

#0 /code/web/modules/contrib/token/token.module(675): in_array('::save', NULL)
#1 [internal function]: token_node_menu_link_submit('node', Object(Drupal\node\Entity\Node), Array, Object(Drupal\Core\Form\FormState))

The condition also needs to check whether the key exists, otherwise we may pass NULL to in_array().

This patch addresses a couple minor UX concerns with the value callback in prior iterations.

Oops, one last test fix.

Test this patch and let me know if it meets your needs. If so, I'll schedule a feature release for early July.

It seems that the project to which you refer in the issue description forked this project:

This simple module forked from Entity Bundle Permissions → but much more useful.

I'm not sure why the author of this downstream module decided to fork this project, but if you think these projects should be merged, then I would encourage you to open an issue on the downstream project to inquire about why a fork was necessary since that was not my decision.

This project will not add support for PHP 7 or Drupal 8, since both are EOL. My company will not spend time to support EOL software. If the primary feature request is to suppress excess permission checks and generation, you will need to adjust the scope of this issue or open a separate issue for our consideration.

Defining a menu link in the administration menu would require this module to establish a potentially disruptive, implicit dependency on Drupal's current menu structure -- in this case, the plugin ID of a given parent menu item provided by Drupal core. While the backward compatibility policy does state that "plugin IDs [...] can be relied upon," I've chosen to avoid this implicit dependency.

This module instead leverages the configure key in its *.info.yml, which adds a "Configure" link to the module's description on the "Extend" page. Should Drupal choose to forgo this concept in the future, there is no potentially disruptive dependency relationship to worry about.

Reliability is a primary priority for this module. I may be paranoid in making this decision, but given that unintended side effects could result in an inaccessible site, I want to reduce the incidence of these types of scenarios as much as possible.

All that being said, end users who need a menu link can still add one manually.

I am unable to reproduce the issue. How are you installing the module? If you're installing without using Composer, have you made the module's dependencies available? Namely, this module requires league/iso3166 for a canonical list of country codes.

This project uses a very strict interpretation of Drupal's backward compatibility policy → which prevents us from leveraging Drupal's administration menu out of the box. If you wish to add an item to Drupal's administration menu, you can still do so manually by navigating to Structure > Menus > Administration > Add link and using the following path: /admin/config/geoblock.