🇨🇦Canada @Liam McDermott

Setting the correct status.

The feature module Layout Builder Expose All Field Blocks is deprecated and links to: https://www.drupal.org/node/3223395#s-layout-builder-expose-all-field-bl... →

However, this link is dead and there is nothing on this page about what Layout Builder Expose All Field Blocks is, or under what circumstances it may be uninstalled.

To fix that, would this addition to the page be suitable?

Layout Builder Expose All Field Blocks

The Layout Builder Expose All Field Blocks module, introduced in Drupal 10.3.0, is deprecated, and enabled by default on existing installations. This reflects changes to Drupal's default settings that aim to improve performance.

Uninstalling Layout Builder Expose All Field Blocks:

1. Review your site’s configuration for fields on entities without Layout Builder enabled (e.g., using grep -rn 'field_block:' config/sync/* and grep -rn 'extra_field_block:' config/sync/*).
2. In a development environment, uninstall the module, thoroughly test your site for missing fields, and then export the configuration.

Merged, thank you very much for this! I'll follow-up by adding a Permissions link.

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

Liam McDermott → created an issue.

Fixed, thanks for catching that!

That seems a little silly, I understand why that rule exists, but no-one is using those modules yet. I only just created them!

Anyway, sorry for making a mess, I'll try to clean it up as best I can. Thanks for looking into this.

Thanks for this Ilnur, switching to v3 is something I plan to have done ASAP. I'm just sorting out an issue with the module's name first!

Apologies, now when I install the module, I'm not seeing any problems when the module is namespaced `ecwid` but is inside the `ecwid-ecwid` directory. Any issues I was seeing were probably caused by moving the module on my local, I was careful, but maybe there was something in config or the caches that resulted in an error being thrown.

So, the only bug (IMO) is that I was allowed to create a new module with a name that's effectively already taken, leading to a weird usability issue for anyone `composer require ecwid`-ing without carefully reading the instructions. This is an assumption, but I'm guessing most people look at the final segment of the drupal.org/project/project_name URL to get what to use in their `composer require`, and not the instructions at the bottom of the project page.

I'd prefer users not have to deal with that, so could you please delete drupal.org/project/ecwid. Then also delete drupal.org/project/woolwich_ecwid as that name kinda sucks.

If it's easier for you to rename than delete, you could rename drupal.org/project/woolwich_ecwid → ecwid_drupal (but still delete ecwid). Thank you! And sorry for being a pain.

So, I'm wondering: what are the options?

If some other project already had the `ecwid` namespace, surely the site should have stopped me from registering the project? That seems like a bug.

FYI, I have registered: https://www.drupal.org/project/woolwich_ecwid → Just to get something working, but I'm still interested to know what the options are for the Ecwid namespace.

Liam McDermott → created an issue.

Never mind, it was just an issue on my local. Not sure why `composer update` wasn't working for me a few minutes ago, but it is now!

Sorry to waste your time. I'll leave this issue here, in case anyone else's composer is being weird: just clear composer's cache and try again.

Liam McDermott → created an issue.

Liam McDermott → created an issue.

Liam McDermott → created an issue.

Liam McDermott → created an issue.

Just a datapoint: a client has given us a file exported from Chameleon Creator, which places everything in the SCORM file in a sub-directory.
Also, bumping version as this issue is still relevant in 3.x

I created an MR that adds the dependency, and tested it.

Hey cornifex, thanks for the patch. Unfortunatelly it doesn't work for me and I'm still getting the error.

This would be due to patches being applied after composer has resolved dependencies, because of this, adding new dependencies in patches doesn't work.

Instead, if you add this to your project's `composer.json` as the first item under `repositories`:

        {
            "type": "vcs",
            "url": "git@git.drupal.org:issue/opigno_scorm-3281986.git"
        },

And put this under your `composer.json`'s `require` section:

        "drupal/opigno_scorm": "dev-3281986-json-schema-dep-missing",

It should fix the issue. Or you can add it as a direct dependency, like saurabh-2k17 suggested, but that won't help test the fix for this issue. If the above works for anyone else, please come and mark this as 'Reviewed and tested by the community'.

To reproduce this issue, install Opigno SCORM without any of the other Opigno modules, then upload a SCORM file to some content, load that content in the browser, then open the browser console and interact with the loaded SCORM content. When moving between steps this error should be shown in the console (it's a JS http request).

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

Seems this issue is outdated, as Opigno SCORM works on Drupal 9.

I have this module installed on Drupal 9 and the compatibility is there, so am closing this issue.

Hey @beautifulmind, just wondering, how is this coming along? Do you need anything or are you blocked on something in particular?

Might be worth just pushing what you have, even if it's broken/incomplete, so others can give feedback or help out.