🇨🇦Canada @maursilveira

I've created a merge request with the fix for the PHP 8.4 deprecation.

I'm also attaching here a patch file for the same fix, for composer patches.

Please let me know if you have any questions. Thank you.

maursilveira → created an issue.

I've created a merge request with the fixes for the PHP 8.4 deprecations.

I'm also attaching here a patch file for the same fixes, for composer patches.

Please let me know if you have any questions. Thank you.

maursilveira → created an issue. See original summary → .

I've created a merge request with the fixes for the PHP 8.4 deprecations.

I'm also attaching here a patch file for the same fixes, for composer patches.

Please let me know if you have any questions. Thank you.

maursilveira → changed the visibility of the branch 1.x to hidden.

maursilveira → created an issue.

Code looks good and fixes the PHP 8.4 deprecation messages.

Marking this as RTBC. Thank you.

Closing this issue as a duplicate of https://www.drupal.org/project/twig_tweak/issues/3500245 📌 Nullable types must be explicit Active .

maursilveira → created an issue.

Hello,

First of all, thank you for maintaining this module. I've been using it in many of my projects.

Is there any expectation of when we could have the Drupal 11 compatibility fixes merged, and a new version compatible with Drupal 11 released?

Thank you.

Hello,

Thank you for this module, it's extremely handy!

Any idea of when a new release could be created including the fixes from this issue? I'm using 2.1.1, and what I'm really looking for is the fix for the following PHP 8.4 deprecations:

Deprecated: Drupal\layout_paragraphs\Form\EditComponentForm::buildForm(): Implicitly marking parameter $layout_paragraphs_layout as nullable is deprecated, the explicit nullable type must be used instead in /app/web/modules/contrib/layout_paragraphs/src/Form/EditComponentForm.php on line 21

Deprecated: Drupal\layout_paragraphs\Form\EditComponentForm::buildForm(): Implicitly marking parameter $component_uuid as nullable is deprecated, the explicit nullable type must be used instead in /app/web/modules/contrib/layout_paragraphs/src/Form/EditComponentForm.php on line 21

Deprecated: Drupal\layout_paragraphs\Form\DeleteComponentForm::buildForm(): Implicitly marking parameter $layout_paragraphs_layout as nullable is deprecated, the explicit nullable type must be used instead in /app/web/modules/contrib/layout_paragraphs/src/Form/DeleteComponentForm.php on line 63

Deprecated: Drupal\layout_paragraphs\Form\DeleteComponentForm::buildForm(): Implicitly marking parameter $component_uuid as nullable is deprecated, the explicit nullable type must be used instead in /app/web/modules/contrib/layout_paragraphs/src/Form/DeleteComponentForm.php on line 63

Thank you!

TomTech → credited maursilveira → .

Please find attached a patch file with the same fix applied in the MR, if anybody needs an actual patch file.

I created a merge request for the fix. It registers the installed content libraries as dependent on the H5P main core library. This solves the errors, properly defining and constructing the H5P functions prior to their usage by the installed content libraries.

Please let me know if you have any questions about this. Thank you.

I'm fairly new to this module, and I have a question: shouldn't the library h5p/h5p.content be a dependency to all installed content libraries (in sites/default/files/h5p/libraries)? I believe this is the reason Drupal isn't guaranteeing those main H5P libraries are not being loaded before the content libraries.

For visibility, I opened a new task https://www.drupal.org/project/h5p/issues/3464434 🐛 Errors due to content libraries being loaded before main H5P libraries Active .

Thank you

maursilveira → created an issue.

Hello,

One thing I noticed that I believe can be the cause of the error I'm having is that the content libraries, located in /sites/default/files/h5p/libraries, are being loaded before the main libraries h5p.js and jquery.js, located in the vendor directory in the module folder, ando also before the file h5p-event-dispatcher.js, which I believe is where the aforementioned function is defined and constructed. Please see the attached screenshot.

Shouldn't the main libraries be loaded before, in order to ensure all the H5P core functionality is properly defined? Is this an issue you have experienced before? Any recommendations on how to solve this?

Please let me know if this sounds to you a different issue, and I can open a new one.

Thank you!

Hello,

I'm experiencing this issue even after applying the patch #17. I'm getting a Uncaught TypeError: H5P.EventDispatcher is undefined, most likely coming from one of the content libraries located in the public folder (/sites/default/files/h5p/libraries).

Any ideas or recommendations? Any help is much appreciated!

Thank you!

I've created a merge request with the deprecation fix.

maursilveira → created an issue.

I've just created a merge request with the change, which is quite trivial indeed.

maursilveira → created an issue.

I've just created a merge request with the adjustment.

maursilveira → created an issue.

I've created a merge request with the adjustment.

I've created a merge request with the fix, which is in fact quite trivial.

maursilveira → created an issue.

maursilveira → created an issue.

I've just created a merge request for both dev versions 2.0.x and 3.0.x with the change.

maursilveira → created an issue.

I'm sorry, I've just noticed this has been fixed in the dev branch. Closing this task.

Apologies for all the noise.

maursilveira → created an issue.

Ok, different browsers display different warning messages in the console, but after doing multiple tests, this is the message that I get only and in all situations when the error happens:

Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://js.stripe.com') does not match the recipient window's origin ('https://my-site-url-here').

Researching by this type of error returns many results, and apparently this may happen when the postMessage() function is called before the actual element in the DOM has finished loading, but I'm not sure that is the case here. This message is coming from the following function in https://js.stripe.com/v3/

function(e) {
    var t, n = e.targetOrigin, r = e.type, o = n;
    switch (r) {
    case "sibling":
        t = (0,
        l.Hb)(e.targetFrameId);
        break;
    case "child":
        t = window.frames[e.targetFrameId];
        break;
    case "parent":
        o = o || "*",
        t = window.parent;
        break;
    default:
        (0,
        s.Rz)(r)
    }
    if (o = o || u.jQ,
    t && "function" == typeof t.postMessage) {
        var i = e.message.delegate ? {
            targetOrigin: o,
            delegate: e.message.delegate
        } : o;
        t.postMessage(JSON.stringify((0,  // <= Error happens here
        c.Z)((0,
        c.Z)({}, e), {}, {
            __stripeJsV3: !0
        })), i)
    }
}

I'm not very familiar with how the checkout pane is built or how the Stripe library is called and executed, therefore it's been hard for me to find where a fix should go.

Any thoughts?

Hello,

Doing some more tests today, I was able to get the following error in the browser's console:

Uncaught IntegrationError: payment Element didn't mount normally.
    at e._handleMessage (v3/:1:88665)
    at e._handleMessage (v3/:1:101570)
    at v3/:1:87423

This is coming called from the following function:

this._setupPostMessage = function() {
    r._listenerRegistry.addEventListener(window, "message", (function(e) {
        var t = e.data
          , n = e.origin
          , o = e.source
          , a = (0,
        l.$G)(t);
        a && ((0,
        T.uW)(u.jQ, n) ? r._handleMessage(a, o) : (0,
        x.Z)(n))
    }
    ))
}

Which ends up in this case statement:

case "stripe-frame-error":
  throw new I.No(a.payload.message);

Any help is greatly appreciated!

maursilveira → created an issue.

Thank you @apaderno and @vishal.kadam for all your support with this. I really appreciate it.

The recommended changes have been merged into the main branch of the repository.

Marking this as fixed.

@vishal.kadam Thank you for the update, I wasn't familiar with the review process.

The changes have been committed into the main branch of the project:
https://git.drupalcode.org/project/field_label_override

@apaderno I applied the adjustments you recommended. They haven't been merged to the main branch yet, nor I have created a new release of the module. These adjustments are in the following merge request:

https://git.drupalcode.org/project/field_label_override/-/merge_requests...

Could you please review it and confirm the adjustments comply to the Drupal coding standards, and they should suffice? Then I'll merge the changes and create a new release of the module, which we can hopefully mark as covered by Drupal's security advisory policy.

Thank you.

maursilveira → created an issue.

@apaderno I really appreciate you taking this module into consideration, and even more the extensive review you reported in #7.

I'll carefully review your comments, and apply the necessary adjustments to the module. I'll keep you posted in this thread when I would expect you to review the adjusted code.

Once again, thank you!

Hello @vishal.kadam, thank you for your quick reply.

I agree, the module is quite simple/small, but mainly because the purpose of it it's pretty simple too: allowing administrators to configure different labels for fields per entity view mode.

I have some other contributions, which you can see on my Drupal.org profile, but really the vast majority of my code work as a Drupal developer and solutions lead is client work, which I acknowledge you don't have access to view. I can send the link of those sites, if that works, but I'm not sure if this is of any help.

I'd be honoured if I was granted the ability of opting projects into security advisory coverage, but honestly, that's not my main purpose at this moment, and I'm fine with opening a new issue like this in the future for any new module I eventually contribute. All I'm looking for at this moment is having this project Field Label Override covered.

Please let me know what we can do to achieve this.

Thank you very much.

maursilveira → created an issue.

@shwetaDevkate Thank you for creating the MR. The code overall works as expected. I made an adjustment to ensure the attribute colspan is only added to fields that do not have the label overridden when at least one field does.

I'm marking this issue as fixed, and I'll be creating a new release of the module soon.

Thank you.

I tested the patch #2 against the version 2.10.0 of the module, and it does fix the issue.

Thank you @thatguy!

@shwetaDevkate Thank you for looking into this issue and submitting a patch. This is much appreciated!

Following Drupal.org guidelines, we should prioritize merge requests over patch files, now considered deprecated. Therefore, I'll ask you to create a merge request with your suggested fix.

Thank you.

Release 1.0.0-alpha2 → has been created comprehending this fix.

Release 1.0.0-alpha2 → has been created comprehending this fix.

I noticed the same typo was present in the README.md file, which was also fixed.

maursilveira → created an issue.

maursilveira → created an issue.

This has been merged.

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

@mark_fullmer Thank you for your response. I wasn't sure if I was missing something or it was indeed a feature not implemented.

I'm changing the issue category to "Feature request", so we can look into implementing it, if possible.

maursilveira → created an issue.

Hello,

I second @Nicolas Bouteille on what was said in #3 about the risks and efforts involved in upgrading stripe/stripe-php from the currently used version 7.x to the latest one (13.x). At the same time, I am not an expert in either Commerce Stripe module or Stripe itself. However, perhaps if we were able to summarize what needs to be covered, we could split efforts and test the module against the latest library version. I volunteer to help out with this work, but would certainly need guidance from someone with experience in the module.

One example of issue I'm having now with the library's old version is that I'd like to search customers by their email addresses in a custom functionality, using Customer::search(), but I get the error message:

Search is not supported on api version 2013-02-13. Update your API version, or set the API Version of this request to 2020-08-27 or greater.

Restating what @Nicolas Bouteille said in the description, we are probably missing out sticking with an old version, taking the risk of having to run into an urgent upgrade if Stripe eventually stops supporting other functionalities, similar to the above.

maursilveira → created an issue.

@jonathanshaw Thank you for your response, but I've just figured out the cause of the issue: I am using Stripe Payment Element, and the patch #3 only adds the name item to the class Stripe.

I created a new patch that adds the name for both payment gateways. Moving the issue back to "Needs review" status.

Please let me know if you have any questions, concerns or comments.

Thank you.

@LeDucDuBleuet

Thank you for the patch, but I'm a bit confused here, and not seeing the expected result.

I applied the patch, and have Realname → configured in my site with [user:field_first_name] [user:field_last_name] as pattern. When I call ::getDisplayName() elsewhere I get the correct user name format. However, when I complete a purchase using Commerce Stripe for a new customer, it gets created in Stripe with the name empty. All I see is the email address and the description "Customer for ".

Am I missing something here? Do I need any other configuration for getting the user display name to have this working?

Thank you.

I tested the patch from #9 and it works as expected. It applies cleanly and fixes the issue with the aggregated CSS.

Thank you @jrglasgow!

Patch from #18 works for me and fixes the error.

Thank you.

I ran into this same issue, and the patch #14 fixes it.

I ran into the same issue in a Drupal 10 site, when testing this module for the first time (version 4.0.0).

Changing the version to 4.0.0, since version 8.x-3.x-dev works with Drupal 8 and 9, which are not supported anymore.

Leaving this note here, in case other have the same issue.

I had the same error when trying to execute database updates (via drush updb) after upgrading from 8.x-3.11 to 4.1.x. I noticed that I had a sitemap regeneration in progress in the Sitemap status. After simply clicking on "Rebuild queue", I was able to execute the database updates with no errors.

Hello,

I tested the patch #242 and it works as expected.

Thank you!