🇫🇷France @S3b0uN3t

It's good for me.
Thank you for your contribution!

Hello @oulalahakabu,

Thank you for your issue and your merge request.
We don't use tacjs regularly and prefer its alternative tarte_au_citron and we haven't seen this change yet.
We'll look into this very soon! :)

Regards

Here is my patch proposal.

I can create a fork and a merge request if it's good for you.

Hello,

I tested the current MR with the latest released version of the module (8.x-1.19). This fixes the cut wording issue (when the paragraph is expanded), however I now have 4 warnings:

• Warning: Undefined array key "top" in paragraphs_field_widget_single_element_form_alter() (line 530 of modules/contrib/paragraphs/paragraphs.module).
• Warning: Trying to access array offset on null in paragraphs_field_widget_single_element_form_alter() (line 530 of modules/contrib/paragraphs/paragraphs.module).
• Warning: Trying to access array offset on null in paragraphs_field_widget_single_element_form_alter() (line 530 of modules/contrib/paragraphs/paragraphs.module).
• Warning: Trying to access array offset on null in paragraphs_field_widget_single_element_form_alter() (line 530 of modules/contrib/paragraphs/paragraphs.module).

s3b0un3t → created an issue.

Fixed into release 1.5.0

After changes, the following behaviors can be noted:

1. The variant is no longer limited in terms of value (the enumeration has been removed)
2. No change when rendering component in Twig
3. Rendering component by render array:
4. Before Drupal core 11.2.0:
   • The variant declaration in "#props" is taken into account.
   • The variant declaration in "#variant" is not taken into account.
5. From Drupal core 11.2.0:
   • No more error when no variant is present.
   • The variant declaration in "#variant" is taken into account.
   • The variant declaration in "#props" is taken into account (and takes precedence over "#variant").

It seems OK!

Hello,

Thank you for your feedback.
I invite you to create a merge request with the desired modifications.

Could you also describe a test case to validate your merge request, please?

Regards,

Thanks for your feedback. I’m currently in vacation without computer.

I have forwarded the issue to the other maintainers to look it soon.

Hello,
This behavior change was specifically planned for 1.4.4 by systematically defining a default value for each "variant" property. To reproduce this bug, could you provide a concrete example (with the values ​​for the props used)?

Regards

Hello,

With the processing of the linked ticket #34880849, the issue is no longer reproducible as such. The bug is no longer reproducible on the development branch 6.3.x.

Hello,

A 1.4.4 release has been generated today, allowing card link management in download mode.
To do this, simply set the "is_download" property to "true".

Several components have changed in this release. Don't forget to read the release note → to prevent regression risks!

Sincerely,

Hello,

I finally managed to reproduce your bug.

Photon returns "New York" for the "state" property, while the "Address" module expects ISO2 codes (example: NY for New York).
I modified the script so that when the address component field is a select, it also tests the option label (if it doesn't match the value).

I will generate a new bugfix release.

Regards,

Hello,

I also needed to generate a CSV with headers even when there were no results.
I'm providing my code as an example for others who may have this issue.

In a *.module file, i declare a hook:

/**
 * Implements hook_views_post_render().
 */
function mymodule_views_post_render(ViewExecutable $view, array &$output, CachePluginBase $cache): void {
  if ($view->id() !== 'my_view_id') {
    return;
  }

  $options = $view->getStyle()->options;

  // The CSV output is empty when there is no result,
  // even if a header row is requested.
  if (
    empty($view->result) &&
    isset($options['csv_settings']['output_header']) &&
    $options['csv_settings']['output_header']
  ) {
    $header_row = [];
    foreach ($view->field as $name => $field) {
      $header_row[$name] = $field->label();
    }

    // Override output markup with the header row.
    $output['#markup'] = ViewsRenderPipelineMarkup::create(
      \Drupal::service('serializer')->serialize([$header_row],
        reset($options['formats']),
        ['csv_settings' => ['output_header' => FALSE] + $options['csv_settings']]
      )
    );
  }
}

Don't forget to rename the mymodule hook function name prefix with your module name and the my_view_id with your view ID.

Regards,

It seems the problem is also identified in another issue with a suggested fix.
I tested the suggestion; it seems to resolve the error.

I'm linking the two issues together.

Hello,

For anyone who also needs this, simply delete a line in the JS to reactivate the search (with a default value of at least 20 results).

I'm providing a patch if needed.

Hello,

I just tested the MR and also the @zabair-rana's patch on Drupal 11.
Everything works fine in my environment.

Sincerely,

Hello,

Thank you for using the dsfr4drupal theme!

The bg_boxes property is not intended to manage all card options.
We have chosen to update its type to an enumeration to limit its use to the purposes mentioned by the DSFR (See "Fonds et encadrés").

We apologize if this restriction caused regressions in your theme implementation.

We also prefer to limit the variant property to the card size as is the case for the majority of components.

There are so many possible options in cards that we don't plan to manage them all by properties today.

To use a card in download mode, it would be preferable to define the class yourself in the attributes property:

{% set attributes = attributes.addClass(['fr-card--download']) %}
{{ include('dsfr4drupal:card', ...) }}

or

{{ include('dsfr4drupal:card', {
  'attributes': attributes.addClass(['fr-card--download']),
  ...
}, with_context=false) }}

or

{{ include('dsfr4drupal:card', {
  'attributes': create_attribute({'class': ['fr-card--download']}),
  ...
}, with_context=false) }}

Regards,

s3b0un3t → created an issue.

Hello,

This module never had a stable release and is no longer maintained.

Perhaps you could try the Docusign eSignature API Integration → module instead.

Regards

Hello,

Hello,

I ran a test today with 'Madison Square Garden'. Everything seems fine.
I've attached a screenshot.

However, I noticed a JavaScript bug in Drupal 11 related to the "$.trim" method, which is deprecated and which I just replaced.
This prevented the autocomplete results from displaying.
I invite you to check your browser console in case this is also your problem.

I'm waiting for your feedback before pushing a corrective release.

Regards,

Thanks for your feedback

I'm currently at Drupal Dev Days Europe. I'll try to look at it tomorrow or this weekend.

Hello,

Thank you for your feedback. :)

To easily test, reproduce, and correct this, could you provide me with an example of the address provided, the results obtained, and the expected results?

Thank you in advance.

Hello @5,

Thanks for your feedback.

We've already identified this bug, and it's no longer present on the main branch (1.x).

Testing is currently underway before generating a new release with new features and fixes (= 1.4.0).
This new release is expected to be released at the end of the week.

If needed, you can fix the problem by deleting the last </div> from the "templates/form/input--password.html.twig" file.

Regards,

Adding latest version of MR !23 as a patch file too.

Tested with Drupal 11.1.5 and Field permissions 8.x-1.4. It works like a charm.

Thank you!

Hi,

I ran the drush command and fixed the returns that seemed relevant to me.
The developments are currently being reviewed and will be merged soon.

Thanks!

Hello,

In the current version of the merge request, a 500 error occurs when you try to insert a paragraph from a content creation form.
It tries to load the content, but it doesn't exist yet.

Hello @niranjan_panem,

You're patch for Drupal 11 is incorrect. There are comments conflict into your patch:

+<<<<<<< Updated upstream
     // This is safe because we are manually scrubbing the values. It is
     // necessary to do it this way because $a and $b are formulas when using an
     // offset.
+=======
+
+    /*
+    This is safe because we are manually scrubbing the values.
+    It is necessary to do it this way because $a and $b are formulas when using an offset.
+     */
+>>>>>>> Stashed changes

Hello,

Unlike the other two issues mentioned, I think the fix for this one is the most elegant and comprehensive.

Tested and validated in version 3.0.0 (in Drupal 11.1.3).

THANKS !

Thanks for your review. I merge and fix the issue.

Hello,

Default configuration update is missing.

I purpose to add social media item :

  bluesky:
    enable: 1
    text: Bluesky
    api_url: 'https://bsky.app/intent/compose?text=[current-page:title]'
    api_event: href
    default_img: 0
    weight: 5
    attributes: "target|_blank\r\nclass|pinterest\r\nrel|nooopener noreffer"
    drupalSettings: ''
    library: ''
    img: ''

Otherwise it works perfectly!

Regards

Hi @pdureau,

Thanks for your analyze. We check your feedback as soon as possible.

Regards,

s3b0un3t → changed the visibility of the branch 3499341-submit-button-without to active.

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

I haven't access to "gouvfr" slack.

You can find me on Slack (with the same username) :

• Drupal (drupal)
• Drupal FR (drupalfr)
• Association Drupal France (drupalfrance)

Hello,

During various audits, we received feedback regarding the presence of the "value" attribute on a button HTML tag.
We will try to reproduce your bug in order to identify the origin of the problem.

We are interested in learning about your forms implementation. We can communicate via Slack to simplify our discussions if you wish.

Sincerely,

Hello,

Thank you for your feedback and your proposed correction.

We will analyze your request as soon as possible.

Sincerely,

Thanks for your screenshot.

Hello,

Can you provide more details about the problem you are experiencing?
Can you provide one or more screenshots that explain your problem (before and after correction)?

Thanks.

I push changes in this commit.

A new release will be generated soon.

Thanks for your help.

Thanks for the test, I'll see about implementing this change soon.

Regarding the prerequisite to +10.3.0, this is related to the dependency on the "Single Directory Components" module (sdc) which became a placeholder from 10.3.0 and which will no longer exist in Drupal 11.
We could therefore not keep this prerequisite when activating the theme.
Rather than having several Git branches to maintain for this single constraint, we decided to encourage theme implementers to upgrade to Drupal >=10.3 to continue to benefit from fixes and developments.

You can use the Leniant Composer plugin → if tomorrow you are blocked by this constraint.

Hello,

I agree with your remark. I also noticed this at the end of last week.

Wouldn't using base_path() be a better choice?

I purpose :

  $variables['dsfr_path'] = base_path() . ltrim(Dsfr4DrupalInterface::LIBRARY_PATH, '/');

Released in 1.2.6. I close this issue.

Released in 1.2.6. I close this issue.

Hello @kgaut,

Thanks for your vigilance!

I am merging now and will generate a corrective release soon.

Regards,

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

Thanks for your feedback.

I push changes and create a new release soon.

Hello,

You can't use the component dsfr4drupal:display-modal with context=false for this reason.
I use it on several sites without the context=false. It works correctly without.

If you have another suggestion for a more elegant implementation, do not hesitate to submit it to us.

Regards,

Hello,

Thank you for the work done!

I notice that the "Revisions" link in the primary local tasks is not positioned in the same place as on the node entity type:.

Indeed, an entry is missing in taxonomy.links.tasks.yml.
Here is the one present in the node entity type:

entity.node.version_history:
  route_name: entity.node.version_history
  base_route: entity.node.canonical
  title: 'Revisions'
  weight: 20

What do you think?

Good morning,
I created this model in 2021 following the needs of a POC.
As there is no equivalent module in Drupal 8+, I took the opportunity to publish the sources. I never took the time to release a stable version to this day, which means that it is still in "dev" today.

The docusign_esign module was created in 2022 and is reported as stable.
I therefore invite you to use their module if it meets your needs.

Sincerely,

No response, I close the issue.

@kgaut, don't hesitate to come back to us if your problem persists.

Hi @kgaut,

Are you still making this bug?
If so, can you provide more information?

Without feedback, I will close the issue.

For a simple change I prupose to add these lines in css/ckeditor.css :

/* Manage "Gin" theme dark mode. */
.gin--dark-mode .ck-content {
  --grey-200-850: #cecece;
  --grey-200-850-hover: #a8a8a8;
  --grey-200-850-active: #939393;
}

Extracted from DSFR library dark mode :

• File dist/scheme/scheme.css
• Selector :root[data-fr-theme=dark]

I think the best approach would be to use CkEditor 5's CSS variables as much as possible: https://ckeditor.com/docs/ckeditor5/latest/getting-started/setup/css.html#customizing-the-editors-look.

Example for the lark theme (used for dark mode): https://ckeditor.com/docs/ckeditor5/latest/framework/deep-dive/ui/theme-customization.html#customization-with-css-variables

Hi @kgaut,

Color management in dark mode is actually not interpreted correctly.
Your scenario will work well with Gin but the problem may arise for other dark themes.

Also, are we sure that it is only necessary to declare this property for everything to work correctly?

Hello,

Thanks for the detail of your issue.

My first tests do not demonstrate the problem on the sites where the module is implemented.
This bug is probably be related to Captcheat official assets or your website but not the module implementation.

I will carry out further testing as soon as I have availability.

Thanks for your review.

I close the issue.

I've checked with original healtcheck API :

In sandbox mode (with sandbox credentials) : https://sandbox-api.piste.gouv.fr/piste/captcha/healthcheck`

array(2) {
  ["status"]=>
  string(2) "UP"
  ["components"]=>
  array(4) {
    ["captchaTestHealth"]=>
    array(1) {
      ["status"]=>
      string(2) "UP"
    }
    ["diskSpace"]=>
    array(2) {
      ["status"]=>
      string(2) "UP"
      ["details"]=>
      array(4) {
        ["total"]=>
        int(0)
        ["free"]=>
        int(0)
        ["threshold"]=>
        int(0)
        ["exists"]=>
        bool(true)
      }
    }
    ["memcachedHealth"]=>
    array(1) {
      ["status"]=>
      string(2) "UP"
    }
    ["ping"]=>
    array(1) {
      ["status"]=>
      string(2) "UP"
    }
  }
}

And in production mode (with production credentials) : `https://sandbox-api.piste.gouv.fr/piste/captcha/healthcheck` :

array(2) {
  ["status"]=>
  string(2) "UP"
  ["components"]=>
  array(4) {
    ["captchaTestHealth"]=>
    array(1) {
      ["status"]=>
      string(2) "UP"
    }
    ["diskSpace"]=>
    array(2) {
      ["status"]=>
      string(2) "UP"
      ["details"]=>
      array(4) {
        ["total"]=>
        int(0)
        ["free"]=>
        int(0)
        ["threshold"]=>
        int(0)
        ["exists"]=>
        bool(true)
      }
    }
    ["memcachedHealth"]=>
    array(1) {
      ["status"]=>
      string(2) "UP"
    }
    ["ping"]=>
    array(1) {
      ["status"]=>
      string(2) "UP"
    }
  }
}

At the launch of V2 (in June 2024), not all APIs were available in "/v2". This apparently is now the case. I plan to migrate them all to the new version.

My patch for fix site install on 3.x version.

I get the same error on site install with existing configurations in drush command.

Hi @kgaut,

I took the liberty of retouching your Merge Request.
This bug only occurs if the "Navigation" module is activated, I prefer that we overload the header in this case.

If you can validate what I did. ;-)

Hello,

This module is used in several projects without problem today.

I consider your issue and try to check it (and your patch) as soon as possible.

Hello !

I've tested your changes. It's ok for installing project but an error occurs on config form :
ArgumentCountError: Too few arguments to function Drupal\Core\Form\ConfigFormBase::__construct(), 1 passed in /var/www/web/modules/contrib/domain_simple_sitemap/src/Form/DomainSimpleSitemapConfigForm.php on line 73 and exactly 2 expected in Drupal\Core\Form\ConfigFormBase->__construct() (line 43 of core/lib/Drupal/Core/Form/ConfigFormBase.php).

It seems to be a Drupal 11 compatibility error.

Hi @kgaut !

Thanks for your feedback and your Merge Request. I check it as soon as possible.

Hi,

The submitContactForm() method is called both during postSave() and during validation if the form contains a phone field.
This method ends with the creation of a contact on Brevo, which should normally only happen at postSave().
I propose a workaround so as to no longer create contact upon validation.
This is not ideal; In my opinion, the design of this part of the module will have to be reworked.

Cheers,

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

s3b0un3t → created an issue.

Hello,

I meet the same message with "paragraphs_library_item" entity type on URL "/devel/token/paragraphs_library_item/{id}": "Exception: Object of type Drupal\paragraphs\Entity\ParagraphsType cannot be printed".

It try to generate a token "[paragraphs_library_item:paragraphs:entity:type:entity]" as EntityType object.

Your patch seems to fix my issue. It's not perfect but the page loaded correctly.

Thanks !

Hello,

We have just generated new releases to manageDrupal 11 compatibility with SDC module :

• A Drupal 1.1.2 release with Drupal 11 compatibility removed (based on new protected branch 1.1.x)
• A Drupal 1.2.0 release with SDC dependency removed (base on default branch 1.x)

Thanks for your help.

Cheers,

Hello @kgaut,

Thanks for the additional documentation.

I gave you a brief feedback in the Merge Request.

Cheers,

HI kgaut,

Thanks for your feedback and your merge request!

We check it soon.

Cheers,

Hello Kevin,

The dependency is directly made on the SDC module of the Drupal code (drupal:sdc) and not the community module (sdc:sdc).

So I don't understand why you can't install the theme with Drupal +10.1 code.

It is actually not a good idea to remove this dependency, otherwise the inclusion of components would no longer work on a site without the SDC module.

Even if the SDC module no longer does anything in Drupal 11, it is still present: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/sdc/s.... yml?ref_type=heads

I will look into this problem as soon as I have some time (I am in the middle of house moving).

We can discuss this topic via Slack if you wish.

Hello Kevin,

The "navbar" variable is by default defined with the content of the "header_navbar" region in the "page.html.twig" and "page--404.html.twig" templates.

If you have declared a child theme, make sure that this region exists in your new theme.

In an evolution, we can also consider setting a default value if the region does not exist.

You can contact me via Slack if necessary.

Hello,

There is currently no stable version of this module. This is a draft which is only available in development version.
The choice to use it is at your own risk.

In my last tests, all examples were functional.
Have you looked at the logs to identify any errors reported by the DocuSign API response?

If you ever identify a bug, don't hesitate to suggest a patch or a merge request.

Sincerely,

Helllo,

Thanks for your feednack. I have fixed all missing returns.

Cheers,

Hello,

I have just generated a 1.3.0 release which ensures compatibility with the Address module in version 2.x.
This major version of the Address module does not cause incompatibility with previous versions of my module.
That's why, release 1.3.0 still remains compatible with versions 1.x of the Address module.

Cheers,