🇫🇷France @GuillaumePacilly

Duplicate of https://www.drupal.org/project/field_group/issues/3491233 🐛 Drupal 10.4 RC1 error with field_ui.js Active .
Fixed on 4.x

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

Updated patch for 5.1 with additional clean up.

I know this was long merged, but we are still using 5.1 version for now to avoid migration to bootstrap 5.

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

Thanks! we checked again and the error is gone, probably due to our own environment. Closing the issue

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

guillaumepacilly → created an issue. See original summary → .

Thanks :-)

Thanks for the update!

I agree with your approach.
But the single return URL also makes it difficult to properly catch failed or cancelled payments.
I would like to add an Handler to at least catch cancellation from the user and redirect him properly.

But I would prefer creating a separate issue and MR for this, based on this one.
Do you think this can be merged soon? Or should we work directly on this MR?

guillaumepacilly → created an issue.

Issue was unrelated, changes are not necessary

I am using version 1.0.0-beta3, but the issue is on all version, including 2.x

guillaumepacilly → created an issue.

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

Hi @beunerd

I ran into the same issue. I checked the core issue → you mentioned

While it indeed looks like a core issue, I feel unconfortable to patch core this way, as it could have an impact on many other things.

Other modules had a similar issues and suggested that each module should be responsible to deliver properly formatted value to the WidgetBase, see https://www.drupal.org/project/eca/issues/3457773#comment-15699522 🐛 An error occurred while trying to build an inline entity from submitted form values Fixed

I have create a MR with this approach, what do you think?

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

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

@tcrawford I have created the MR with your suggested changes and added an api.php file to provide some example.

I added an index variable to the hooks to facilitate the order_items array manipulation, let me know if you have a better idea.

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

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

Applied patch modifications into a MR and cleaned up references and annotations.

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

Applied original patch modifications to MR

guillaumepacilly → changed the visibility of the branch 3476192-fix-must-be to hidden.

guillaumepacilly → created an issue.

@DiDebru thanks for your update, worked fine for me! I added your changes to the MR of this issue, and added another hook to alter payment page initialization data as I need it on my projects.

guillaumepacilly → created an issue.

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

Thanks for the patch!
Updated for Commerce 2.4

guillaumepacilly → changed the visibility of the branch 3425346-views-caching-provide to hidden.

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

GuillaumePacilly → created an issue.

GuillaumePacilly → created an issue.

GuillaumePacilly → created an issue.

GuillaumePacilly → created an issue.

I had the same need and solved it by using custom tokens. Then you can apply conditions inside your hook_tokens().

/**
 * Implements hook_token_info().
 */
function mymodule_token_info() : array {
  $info = [];

  $info['types']['my_custom_tokens'] = [
    'name' => t('Custom Tokens'),
    'description' => t('Tokens available for specific use on this website'),
  ];

  $info['tokens']['my_custom_tokens']['custom_token'] = [
    'name' => 'Custom token',
    'description' => t('Custom token with conditions'),
  ];

  return $info;
}

/**
 * Implements hook_tokens().
 */
function mymodule_tokens($type, $tokens, array $data, array $options, BubbleableMetadata $bubbleable_metadata) : array {
  $replacements = [];

  if ($type == 'my_custom_tokens') {
    foreach ($tokens as $name => $original) {
      switch ($name) {
        case 'custom_token':
            $node = $data['node'];
            // Add your logic here.

            $replacements[$original] = $title;
          }

          break;

        default:
          break;
      }
    }
  }

  return $replacements;
}

Then just use your custom token in the auto_entitylabel configuration

@Drupalengue I added a MR with a possible approach. It gives the opportunity to activate or not the popup features for each ief widget.

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

GuillaumePacilly → created an issue.

GuillaumePacilly → created an issue.

Previous patch missed service argument for the PublicationDateSubscriber

GuillaumePacilly → created an issue.

For those still struggling with this:

The issue is raised by the method \Drupal\Core\Entity\EntityDisplayRepository::getAllDisplayModesByEntityType on line 115:
[$display_mode_entity_type, $display_mode_name] = explode('.', $display_mode->id(), 2);

PHP8 will throws a Notice: Undefined offset 1 if explode('.', $display_mode->id(), 2) returns an array with only on argument.
This will be the case if you have a display mode like this in your config: core.%display_mode_entity_type%.%node_type%. It should be core.%display_type%.%display_mode_entity_type%.%display_mode_name%

In my case I had an obsolete config like core.%display_mode_entity_type%.%node_type%. Removing it with drush solved the issue
drush config:delete core.%display_mode_entity_type%.%node_type% && drush cex -y

GuillaumePacilly → created an issue.

Hey, thanks a lot for the patch.

I have a similar issue when the user set a "publish on" date in the past from the node add form. In that case another scheduler event is triggered (Prepublish).

I have updated the patch to handle this case as well.

GuillaumePacilly → created an issue.

Hello,

First thanks for this patch, this features is really much appreciated.

I could be wrong, but I think the parameters order is inversed between outputfile and arguments in the viewsDataExport function. At least I add to inverse them for it to work proerly. Attached an updated patch with the right order.

GuillaumePacilly → created an issue.

I refactore the Tree Service to avoid missing indexes in the translations array.

However, I realize this feature would need additional work (probably major refactoring) to fully support multingual domains:
Currently the pagetree is build upon menu entities iteration, each domain having one menu, each menu a language and each node in the menu having translations.

This lead to inconsistency if translations belongs to a separate domain. Additionaly, the menu links language depends on the language defined for the menu, not the current language displayed.

GuillaumePacilly → created an issue.

GuillaumePacilly → created an issue.

GuillaumePacilly → created an issue.