🇫🇷France @S3b0uN3t

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,

Hello,

Thanks for your feedback.

I try to purpose a new version with address >=2.0 compatibility as soon as possible (at best this weekend).

Cheers

Hello !

I applied your patch and created a new release.

Thanks for your help ! :)

Hello.

You’re all right. I’m currently in holidays without computer. I apply your patch as soon as possible.

Thanks

S3b0uN3t → created an issue.

It's done !

Don't hesitate to let me know your opinion. ;-)

Hello,

I will try to find time next weekend to provide an example sub-module and a screen capture of it.

Fixed in main branch

Fixed in main branch

Fixed in main branch

Fixed in main branch.

Fixed in main branch.

Fixed in main branch.

S3b0uN3t → changed the visibility of the branch 1.0.x to hidden.

Hello,

Thank you for your task. I totally agree.

You have not created a merge request.
I commit the modification to the project directly
I generate a new release immediately.

Hello,

Thank you to all three for this feedback, the patch and the tests.

I tested it on my side and everything seems ok.

I apply the patch and generate a new release.

Tested with version 3.8 of the AMP module in PHP 8.3.
The Merge Request resolves the deprecated issue and does not result in a new issue.

I update the issue in RTBC.

Thanks for your fix !

Hello,

I tried to apply patch on comment #50, but it's thrown an error in datetime module :

Warning: Undefined array key "type" in Drupal\datetime\Plugin\views\filter\Date->getOffset() (line 180 of core/modules/datetime/src/Plugin/views/filter/Date.php).

Without this warning, the patch works perfectly on Drupal 10.2.2!

Hello,

@camilo.escobar : I've try to use your patch in issue #2982968 but it's return an error.
I will add a comment on your issue in order to trace the error.

The patch #25 seems to work on Drupal 10.2.2.

Cheers.

Hello,
It seems that this function was accidentally deleted.
It ensures that the tokens used in custom parameters do not infringe the GDPR (prohibition on the transmission of private data).

I added this method.
It is based on the same code as the Matomo module.

I am pushing a fix and will generate a new release quickly.

THANKS !

Hello,

When submitting the form, you need to generate a DocuSign envelope and redirect user to DocuSign (as in my examples).

In a Webform context, you need to use your own WebformHandler → to add you redirection in ::postSave() (Webform example here) in which you will do the same redirection principle as in my examples.

Hope my answer helped you.

Cheers,

Hello,

The module is currently available in a development version and cannot be considered stable. Its use is at your own risk.

However, I would like to help wherever possible.

I confirm that the electronic signature examples are now operational, provided that the template and associated fields exist

Simply follow the DocuSign example and documentation if you want to perform more advanced operations.

Can you provide a clear example of the workflow you are trying to do ?

S3b0uN3t → created an issue.