🇺🇸United States @jcandan

A patch supporting the Name field.

Using the existing constraint, if I could just get it to run the AddressFormatConstraintValidator before RequireOnPublishValidator, I think I would then be able to alter the $this->context->getViolations.

Tried increasing the module weight with module_set_weight() to no avail.

I was able to Disable HTML5 validation → to get around the Address module's required attribute. So, similar to Name, I am getting the required subfield validation.

I wonder if this module will play well with others. Take a look at Require on Publish → .

Just had an idea, noting it here so I don't forget.

What if I tackle this from a new Constraint?

Gave this a shot.

/**
 * Implements hook_field_widget_complete_form_alter().
 */
function require_on_publish_field_widget_complete_form_alter(&$field_widget_complete_form, FormStateInterface $form_state, $context) {
  $field_config = $context['items']->getFieldDefinition();
  $field_name = $field_widget_complete_form['widget']['#field_name'];
  /** @var \Drupal\Core\Entity\EntityFormInterface $form_object */
  $form_object = $form_state->getFormObject();
  if ($form_object instanceof EntityFormInterface) {
    /** @var \Drupal\Core\Entity\ContentEntityInterface $entity */
    $entity = $form_object->getEntity();
    if (_require_on_publish_entity_is_publishable(get_class($entity))) {
      // $field = $entity->getFields()[$field_name];
      // $field_config = $field->getFieldDefinition();
      if (($field_config instanceof FieldConfigInterface)) {
        if ($field_config->getThirdPartySetting('require_on_publish', 'require_on_publish', FALSE)) {
          $place_breakpoint_here = 'Analyze the available Widget';
          // Loop the widget sub-fields and determine if they're required. Then,
          // treat each required subfield as if it were required on publish.
        }
      }
    }
  }
}

Tried similar attempts from preprocess hooks, like require_on_publish_preprocess_form_element(). The problem is that I cannot get a combination of render array and the entity context necessary to alter the render array to:

1. Determine the subfield's parent is required on publish.
2. Remove the required attribute.
3. Somehow implement the require_on_publish logic.

I am open to suggestions and willing to accept DMs in #slack.

Original report

The original report proposed that all subfields should be marked optional when reproducing this issue. It then suggested that the field could be subsequently submitted as Published without the desired required fields. This makes sense because there was no field marked as required. ROP validation kicks in if the field is left completely empty.

For the Address field, this means that to not have selected a Country, it would not pass Require on Publish validation. And it correctly does not.

For the Name field, it does not even allow you to set all subfields as optional, at least Given or Family must be required:

If I were to fill in the Given and Family fields, and Select a Country, this is able to be saved as Published.

Updated title to clarify that this isn't about cardinality, but fields types that include multiple fields--compound fields.

Updated the description to take into account how the https://www.drupal.org/project/address and https://www.drupal.org/project/name modules let site-builders manage which sub-fields are required.

Refactored the example a bit.

I guess this MR into 3.7.x is obsolete. Need a 3.8.x branch.

jcandan → created an issue.

jcandan → created an issue.

jcandan → created an issue.

Following the usage docs, I am able to get this to work with the following:

Note: The node.html.twig file doesn't provide any twig-blocks to hook into. So, I ended up adding the markup via a preprocess hook:

function MYMODULE_preprocess_node(&$variables) {
  // Specify the wrapper class.
  $variables['content_attributes']['class'] = 'usa-in-page-nav-container';
  // Prepend the content with the sibling aside element.
  // Specify the appropriate data-main-content-selector.
  $variables['content']['#prefix'] = '<aside
    class="usa-in-page-nav"
    data-title-text="On this page"
    data-title-heading-level="h4"
    data-scroll-offset="0"
    data-root-margin="0px 0px 0px 0px"
    data-threshold="1"
    data-main-content-selector=".block-system-main-block"
  ></aside>';
}

For future consideration, the community might be able to help better if you provide more detail about how to reproduce your issue.

Hope this helps!

Fun note: I stumbled upon how this bug was introduced. Turns out that in #2789097 🐛 No Block Output Fixed , Rajab Natshah → submitted patch #11 🐛 No Block Output Fixed , and promptly submitted a patch the required use statement. But, when it was finally committed over a year and a half later, the commit was missing the changes from patch #12 🐛 No Block Output Fixed . Hopefully this gets adopted sooner.

Move example patch name to a new line.

Wrapping the patch convention example in a code block.

I am unable to find the previously available documentation depicting the example patch naming convention. This change provides the patch naming convention.

jcandan → created an issue.

Yeah, if you’re on board for it being just a clean up, this is a great first issue, and I’ve got a colleague I’d like to mentor on the process.

This may not be so simple.

It seems that, while the item variable is as yet undefined for the top portion, it is effectively acting as a default setter for link_attributes, necessary for the if duplicate_parent statement just below it.

So, keep the parent.url.getOption('attributes') and perform the set menu_item_type = 'link' at the outset.

jcandan → created an issue.

Technically, this project is still open source, even without a dev branch, and within GPL2 license rules.

However, I agree with the sentiment of #33 → and #34 → . Follow, comment, and share support for #3426669: Publish a 3.2.x development release → . Let the maintainers know the community wants to be behind them. There are plenty of examples of successful distributions that are supported by the larger Drupal community while still maintaining the final decision for adoption by the maintainers.

If that fails, we should consider supporting a fork. But, that will not be a small endeavor. There are quite a number of modules in the Opigno ecosystem and it would require a dedicated effort by a handful of folks to guide the process.

Turns out I was using patch #10 → from #3088028: Impossible to logout with a user authorized to log in the standard way.

So, I've opted to remove that patch and go with the deactivate-saml-in-lower-environments recommendation from comment #11 in #3088028 → .

This seems to have fixed my issue.

jcandan → created an issue.

jcandan → created an issue.

Unfortunately, it is not public. See #3426669: Publish a 3.2.x development release → , noted in #22 above.

Fixes the below error.

PHP Fatal error: Cannot declare class Drupal\Commands\radix\SubThemeGenerator, because the name is already in use in /app/drupal/web/themes/contrib/radix/Commands/radix/SubThemeGenerator.php on line 13

Fatal error: Cannot declare class Drupal\Commands\radix\SubThemeGenerator, because the name is already in use in /app/drupal/web/themes/contrib/radix/Commands/radix/SubThemeGenerator.php on line 13
[warning] Drush command terminated abnormally.

Needed to start the namespace path with Drush, not Drupal.

Radix 4 supposed to support Drush 12. Patch rolled for Radix 8.x-4.x.

Need to support Radix 4 just slightly longer for our projects. Patch #6 successfully applies to Radix 4.13.0. Those wishing to apply this patch and update their sub-themes may find these instructions → helpful.

Additionally to upgrading the dependencies, this patch captures the latest Bootstrap _variables.scss and imports list. Additionally it removes redundant items already captured through package dependencies, such as sass and node-sass (captured via sass-loader).

jcandan → created an issue.

Was this abandoned? I don't see any Storybook implementation in the 5.0.x, 5.1.x, or 6.0.x branches.

Rolled patch #2 into MR !6.

@Akram Khan → , your mixed patch is already addressed at 🐛 Argument #1 ($seconds) must be of type string|int, null given RTBC . It seems best to not mix fixes.

Marking this RTBC. Rolled patch #5 into MR !7.

jcandan → created an issue.

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

I concur, this is RTBC. Rolled patch #3 into MR !5.

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

Duplicate of 🐛 Incorrect "$format_state" used in call to HMSService::formattedToSeconds RTBC .

I concur, this is RTBC. Any chance for a merge and stable release with this fix?

While awaiting this MR to be merged, rolling the change into this patch for a stable composer capture.

Confirmed big_pipe enabled on my project. I was getting this $element.fontIconPicker is not a function browser console error. Patch #2 resolved this issue for me.

For reference: HTML defer Attribute.

I was considering posing the same question. Pending a response on #3426669: Publish a 3.2.x development release → , I would support a fork.

jcandan → created an issue.

It happens when the $role_settings is passed by reference to the role create loop. It is treated as a reference going forward, and the next place to pick that up is when the users get created.

To fix, I just renamed the user loop to $user_role_settings.

Patch forthcoming.

Actually, it turns out that, if you look at the list of users, the Member role users are assigned a Reviewer role, and therefore there are duplicate Reviewer role assigned users.

jcandan → created an issue.

I realized that when someone is presented with a 403 Forbidden, they are given the opportunity to log in and are thusly redirected successfully to their desired, previously forbidden destination.

My use-case was to require registration before e-commerce checkout. This assumes registration is open to visitors without at either email verification or admin approval--a poor choice for user validation. I realized it would be better if I ensured that an account is created when the user completes checkout (not using Drupal Commerce for my implementation).

Leaving this here for posterity. Marking Closed (works as designed).

jcandan → created an issue.

Not resolved. But the above solution is a valid work around.

This issue's premise is sound. This module should not have a hard dependency on the Color module, since an Aristotle sub-theme or other custom theme may opt to not utilize this feature. Additionally, the color module is deprecated in Drupal core as of 9.4, and is removed in Drupal 10. Support for this module is carried via the new contrib module.

Patch #5 successfully applies, but the Trying to access array offset on value of type null in Drupal\color\ColorThemeDecorator->getPalette() warning persists. I believe we'll need a $palette = \Drupal::service('color.theme_decorator')->getPalette($theme);

Anyone have any concerns about ✨ Change event data object pattern Active not bumping minor version? Please proceed with the conversation in comments in that ticket. Thanks!

Since we've already release a Beta, and considering the docs → suggests that, in

Beta releases...APIs are frozen enough so that contributed module and theme authors can start upgrading their projects.

I would normally suggest this requires a bump to 2.1.x. However, considering our current usage stats for 2.0.x, what say we keep the current version when we adopt this API change?

jcandan → created an issue.

jcandan → created an issue.

5 days to Drupal 9 end of life. Any updates?

Anybody have any thoughts about how to capture active upload field for paste for UI indicator?

Moving the bits about the undocumented scopes ( ✨ Document default, pre-selected scopes in config field help text Active ) and the passthrough scopes always requiring authorization ( 📌 Note that bot and webhook.incoming passthrough scopes always require authorization Active ).

Development version 4.0.x-dev → released.

jcandan → created an issue.

jcandan → created an issue.

jcandan → created an issue.

I agree. But, maybe let this stew a bit to ensure no concerning bugs pop up. If any do, they can be added here.

Thanks everyone who helped see the remaining tickets through! This was an incredibly efficient turn around.

Maintainers, do you agree? Should we time box this a few days or weeks? Not sure what the typical protocol here is.