🇺🇸United States @mikemccaffrey

chadhester → credited mikemccaffrey → .

chadhester → credited mikemccaffrey → .

I'm going to say that this is a critical bug, since it seems to have been causing content loss for the site we have been working on.

Here are the steps that caused the issue:

1. Delete a paragraph (other than the first paragraph).
2. Add a new paragraph.
3. Enter drag and drop mode (and see that the deleted paragraph has replaced the first paragraph).
4. Exit drag & drop mode and save the node.
5. The first paragraph is deleted from the page (or at least the relationship is deleted in the reference field table).

The patch from #5 seems to prevent that issue from happening.

@Berdir: They are not really though. block_content entities are exposed as block plugins and saving reusable blocks triggers a block plugin discovery. The more of them you have the more expensive that becomes.

This is an argument against using block_content entities at all due performance issues with the way they have been implemented, and not anything related to how they are referenced or added to a page.

Why does saving the content of a block need to trigger plugin discovery? The block existed before, and the block exists after, and the UUID should be the same, what could possibly need to be rediscovered unless blocks are created or deleted?

Not sure what to add here, other than I hope that the Drupal community will choose not to participate in a social space owned by a literal saluting nazi. Seems like the lowest possible bar to clear for a community of people who hopefully think genocide is a bad thing that shouldn't be supported.

Thank to everyone who is speaking up!

chadhester → credited mikemccaffrey → .

I was having this issue as well, but thanks to the advice above, clearing the default "field_breadcrumb_title" value out of the "Alternative title field name for breadcrumb" input made the "Use menu title when available" functionality work properly.

This seems like a big issue, since it is totally not obvious that the bread crumb field name has anything to do with the menu titles, and it is filled in by default on module install.

@duaelfr Deleted paragraphs showing in drag and drop mode seem like a separate problem, since it does not seem related to data being saved on form submit.

In regards to the save problem, I just want to mention that this is happening for me on a brand new site with only a single paragraph field with just two items, so the cause seems unrelated to "there are too many things" that people mentioned above.

mikemccaffrey → created an issue.

mikemccaffrey → created an issue.

In case anyone else stumbles here looking to do this, I believe this code will work perfectly well until the feature is added to core.

/**
 * Implements hook_form_BASE_FORM_ID_alter().
 */
function MODULENAME_form_commerce_order_item_add_to_cart_form_alter(&$form, FormStateInterface $form_state, $form_id) {

  // Redirect the user to the shopping cart on submit.
  $form_state->setRedirect('commerce_cart.page');
}

Here is a patch that adds a simple stub config page for promotions, so that the field api can add tabs to manage fields and the form/display settings.

mikemccaffrey → created an issue.

The patch works well. The only minor issue is that the style of the new tel svg doesn't resemble the extlinks and mailto icons, which are outline graphics even when filled, rather than a solid shape like this new phone.

Here is a patch to change the button back to "Move to", at least for the meantime, so everything matches (and the original client gets their preference.

Here is a patch to check whether there is actually a menu link weight element before starting to add additional attributes to it.

mikemccaffrey → created an issue.

I don't understand how the layout got messed up, and the flex isn't applying to the items to align the buttons to the right side, since it doesn't look like you specifically removed that in the PR.

If the button is going to be two words, it should be either uniformly breaking or non-breaking, so we should adjust the css so they are uniform.

The wording is still not perfect. If we can't figure out a really good solution to the name, we should probably make the button text configurable.

Unfortunately, the patch in #14 did not work for me, and there are not enough details in this ticket or the code comments for me to understand what the solution is supposed to be and exactly how it is supposed to work, so I am unable to easily figure out what is not working.

Weirdly, if I have debug set to true for twig.config in my development.services.yml, there is no issue, but if I turn that off, it suddenly starts throwing the error.

mikemccaffrey → created an issue.

I don't think the solution is to pass the value as is if it is wrong, since we do actually need to deal with the fact that the IP address is not a properly formatted range (or if someone had the gall to try to enter a range using asterisks).

The validateIpAddressElement function in IpAddressWidgetBase.php actually depends on there being an exception to validate the form field:

   // Instantiate our IP, will throw \Exception if invalid.
    try {
      $ip_address = new IpAddress($value);
    }
    catch (\Exception $e) {
      // Make error messages a bit more relevant.
      if ($settings['allow_range']) {
        $form_state->setError($element, t('Invalid IP or range.'));
      }
      else {
        $form_state->setError($element, t('Invalid IP.'));
      }
      return;
    }

The question is why the IpAddress function isn't being constructed within that try catch in the validation function on form submission.

Is there a reason that if it is a StackedRouteMatchInterface (which I am assuming is a sub-request) that it can't simple return out of the function, since the transaction has already be named by the parent transaction?

ultrabob → credited mikemccaffrey → .