🇯🇲Jamaica @axle_foley00

axle_foley00 → created an issue.

See patch attached to fix this typo.

axle_foley00 → created an issue.

@levmyshkin and @rohitsharma401, okay great thanks! I'll update the modules in my install to get the new changes.

@levmyshkin, okay thanks. I'll update the modules in my install to get the new changes.

Ok noted. Thanks again.

Hey @levmyshkin,

Okay I understand your motivation now for having things the way they currently are. The use case of being able to quickly add an image/icon with the Title is a useful one. I had a project that required something like that but I just decided to add those icons beside the titles as a background image using CSS.

I do agree that ideally we wouldn't want to make the configs too big and complicated.

I'm wondering if adding an option similar to the Style settings in Views could work. So as you said, have the select list with the options H2, H3, H4, None, etc.. and then display based on that.

I forgot to ask, should the wording in the comments and error message also be updated so say 'width' instead of 'breakpoints' as was done in the EBT module fix?

For example:

// Define the array with breakpoints values.

should be

// Define the array with width values.

and

// Get the unique breakpoints removing the repeated values.

should be

// Get the unique width values removing the repeated ones.

and

$form_state->setError($form, $this->t('All the breakpoints must be different'));

should be

$form_state->setError($form, $this->t('All the width values must be different'));

and so on?

Hey levmyshkin, okay great! Thanks. Confirming it is fixed in the latest update.

Have a great day.

axle_foley00 → created an issue.

I dug into this a little more and found the issue in the src/Form/EptCoreSettingsForm.php file.

    // Define the array with breakpoints values.
    $breakpoint_values = [
      $ept_core_mobile_breakpoint,
      $ept_core_tablet_breakpoint,
      $ept_core_xxsmall_width,
      $ept_core_xsmall_width,
      $ept_core_small_width,
      $ept_core_default_width,
      $ept_core_large_width,
      $ept_core_xlarge_width,
      $ept_core_xxlarge_width,
    ];

    // Get the unique breakpoints removing the repeated values.
    $unique_breakpoints = array_unique($breakpoint_values);

    // If there is repeated breakpoints, set a validation in the form error.
    if (count($breakpoint_values) !== count($unique_breakpoints)) {
      $form_state->setError($form, $this->t('All the breakpoints must be different'));
    }

So the count of the $breakpoint_values is not equivalent to the count of $unique_breakpoints. But aside from that I noticed that in the array of $breakpoint_values that $ept_core_desktop_breakpoint is also missing. So that is why I only needed to change the mobile and table breakpoint values. Should the breakpoint values be mixed with the Width values in this form validation check?

Also Is it really necessary for the Breakpoint values to be different from the Width values? If so, then perhaps a proposed solution could be to set the default Breakpoint values to be different from the Width values at module installation time in ept_core.settings.yml.

Hope that helps.

@Gábor Hojtsy

So in my case I had a team member who accidentally tried to run the composer command in the web directory instead of the directory above and when it complained about a composer.json file being missing then they ended up adding a new composer.json file there. So once I realized and cleared that up with them we removed the incorrect one.

I do believe the changes to the message you suggested could help to point future users in the right direction though. I also agree we shouldn't suggest removing other composer.json files that might be legitimately be added by users.

axle_foley00 → created an issue.

I had the same issue and am confirming that I had a stray composer.json file in the web folder. Once that was removed the error disappeared.

After looking back at the MR and patch and trying it on a D7 site, I realize it might still have been missing something. Please see new patch that I think addresses the issue. The properties $createLDAPAccounts and $createLDAPAccountsAdminApproval needed to be declared in the LdapUserConf class. I hope this helps anyone else having this issue.

I'm currently experiencing this issue. Here's an attempt at generating a patch based on the MR.

Uploading patch in case anyone needs to fix this in an old D7 site with this module.

axle_foley00 → created an issue.

Thanks @levmyshkin, the steps you provided in #5 🐛 EPT Columns/container won't load Closed: cannot reproduce helped me with this same issue. While I am not using Mercury, switching to using the Layout paragraphs widget and setting the depth to at least 4 helped with the EPT Columns not displaying when selected. 👍🏽

I had this same issue and the patch in #12 worked for me.

This has been reviewed and merged into the latest dev commit

I got this same error as well. Had to rollback the update to 2.0.0-alpha3 for now.

Out of curiosity was the Section that used the tabs in layout builder removed first? I had this issue as well but I figured it was because I forgot to remove the Section that used the tabs before I uninstalled the module.

I had this issue as well and the patch in #17 worked for me.

It might be a silly question but based on what I read from your article, for someone who has created a Drupal 7 module following the convention 7.x-X.Y and now trying to upgrade that module for Drupal 10, is the recommendation using semver to just use 1.0.0 or 2.0.0 instead of 10.x-X.Y?

Confirming that I stumbled across this issue as well. Patch in #3 fixes this issue.

Confirming the patch in #3 worked for me as well.

I believe "confirms" should really be "conforms" in the first paragraph.