🇳🇿New Zealand @dieuwe

dieuwe → created an issue.

Thanks everyone, I did miss this ticket and made a few more commits that I will resolve when I have some time. At this early stage there are some bits of undergoing very large refactors so I had been a bit sloppy. Will check this and put PHPCS into my workflow.

Should be ready with an alpha release and stable database definitions by the end of the year.

I'm afraid that I have no experience with Backdrop or any plans to use it. Happy for someone to port it though, and that might be as simple as changing a few function names - perhaps there are some automated tools to help?

I couldn't repeat the crash in a follow up test, but the notice to set a key would still be good as would having the settings link in the module list.

dieuwe → created an issue.

dieuwe → created an issue.

dieuwe → created an issue.

This somewhat restricts the checks to make sure that arrays exist before they are modified, and also removes the '_none' option from any required option lists.

dieuwe → created an issue.

That part wasn't missing and resulted in a duplicate key.

Someone else just reported the module broken due to that last commit: 🐛 Duplicate key "views.argument.menu_children" in schema Fixed

Have merged in a revert already, and am tagging rc4 right away so the module doesn't whitescreen people's builds.

Thanks for the easy fix there, have merged it right away to get your builds working again.

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

The 2.x branch was clashing with an abandoned D7 rework, so we are switching to 3.0.x

Some work on the basic entities and importers is done, along with views integration.

Ability to navigate the Bible entities by books and chapters out-of-the-box, CKEditor verse embeds, and BLS filter (inline JS popups of verses) are coming soon, and then notes will be tackled.

I've managed to extract all the old BC files (including strongs and tools) from the old drupalbible.org website using the Wayback Machine. These are now more easily accessible from this Github repository which can be integrated into the module in a completely configurable way so that the module is no longer dependent on any one 3rd party: https://github.com/dieuwedeboer/bible-context

After many years, no D8 port ever happened, but a Drupal 10 rebuild will be underway in a new issue: 📌 [META] Bible module Drupal 10 rebuild Active

dieuwe → created an issue.

Patch #19 with the access check change is working very well for us.

Thanks, this applies and runs well against the latest dev. Would be nice to get this committed after all these years.

dieuwe → changed the visibility of the branch 10.0.x to hidden.

dieuwe → changed the visibility of the branch 10.0.x to active.

dieuwe → changed the visibility of the branch 10.0.x to hidden.

dieuwe → created an issue.

Thanks for the report. Drupal doesn't support manual downloads of distributions packages, they have to be installed via composer.

If you did do that and still got an error, could you provide us with some logs for the specific error?

Forgot to reference the issue in the commit: https://git.drupalcode.org/project/sector_project_template/-/commit/e2f1...

dreambubbler → credited dieuwe → .

This bug applies to all modals inside modals.

There is an open issue against the old namespace for this module: ✨ It is not possible to have the embedded content modal open another modal. Needs review

I've rerolled Lee's patch for this module and attached it.

You also need a patch from 🐛 Nested modals don't work: opening a modal from a modal closes the original Needs work where I found that #199 🐛 Nested modals don't work: opening a modal from a modal closes the original Needs work is the one that actually works with core 10.1.6 (and maybe 7).

This fixed up media modals, however I found that the modal to change text formats still save changes with this setup. But it is an improvement.

In case anyone comes here and tries to implement a fix to reduce log noise (especially on a busy site that still uses db logging), I had a lot of trouble trying to override the service in a way that held.

You can adapt the code from comment #4 in a custom module, noting that there has been a change to the log method definition:

  public function log($level, string|\Stringable $message, array $context = []): void {

Then in your custom module's services file:

services:
  logger.channel.search_api_opensearch_no_debug:
    decorates: logger.channel.search_api_opensearch_client
    class: Drupal\my_module\OpenSearchNoDebugLogger
    arguments: [ 'search_api_opensearch_client', '@request_stack', '@current_user' ]

I've never had to use Symfony's decorates parameter before but it is really cool. (I struggled to find any Drupal-specific documentation on overriding services that really pointed me in the right direction.)

Thanks for the investigation on this drumm, very much appreciated.

A good lesson on the importance of namespacing for the team here :)

Yes, this works fine for all other project, but the drupal/sector package is still broken.

Here is an example (assuming no one hit auto-update before you see it):

Latest tag on Packagist is "10.0.0-alpha3" (https://packagist.org/packages/drupal/sector)

Latest tag on Drupalcode is "10.0.0-alpha4" (https://git.drupalcode.org/project/sector/-/tags), pushed 4 days ago.

Packagist will pick it up if someone manually pushes "Update Now".

Thanks for that, and I have fixed the error in that old branch.

Packagist still reports: "This package is not auto-updated" and we have to do it manually every time we tag a new release.

dieuwe → created an issue.

dieuwe → created an issue.

dieuwe → created an issue.

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

Default config was all replaced with YAML files in this commit here: https://git.drupalcode.org/project/sector_content_audit/-/commit/fc6870b...

Thanks for this - I made a few changes to bring the composer.json into line as well. Hopefully good, but since we're in dev any issues can be picked up in pre-release testing.

I believe this and other config issues are going to be fixed here: 🐛 Update views config to work sector's required VBO version Active

dieuwe → created an issue.

dieuwe → created an issue.

This is good - we won't be going to 10.0 because Sector 10 already requires 10.1 at a minumum.

If I had used the Gitlab UI that might have been avoidable... lesson for next time

Chroid → credited dieuwe → .

Chroid → credited dieuwe → .

These 3 legacy modules are now gone from Sector 10 and only available via the Sectory Legacy package.

Cheers, this should be done and dusted now - but any further issues and we can follow up next week. Adding a reference to the Sector issue that removes these from the 10.0.x branch.

Add related issue which adds these modules to sector_legacy while preserving git history.

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

Ah, I've just checked one of my other general projects and it auto-updates. So must be an issue with a converted project that requires more action?

One more question that I can't find an easy answer to: how do we set up packagist auto-update on general projects?

The module needs quite a bit of work to be completely up to scratch, so I think a followup ticket will be needed.

But for now:

• Remove the optional workflow that came from core's default install profile.
• Rename the helper class from WorkflowExtrasBase to simply SectorWorkflow (todo: convert this to a proper container class).
• Check that the node from the route has a moderation state before modifying local menu tabs.
• Refactor a few bits and pieces, like the use of string translations, a var_dump, and other simple cleanup.

dieuwe → created an issue.

This is no longer relevant with the switch to CKEditor 5.

Namespace change has been confirmed, likely nothing else to do on the Sector end, other than to include this change in all future release notes.

dieuwe → created an issue.

dieuwe → created an issue.

I'm not sure about those commits referencing this ticket, they are not related. I have gone through and updated the namespace manually in the 10.0.x branch and forgot to reference this ticket, so it is done.

I have opened an infra ticket in the composer queue to have us moved to a general project: https://www.drupal.org/project/project_composer/issues/3388717 📌 Convert the Sector Distribution to a general project Fixed

Once that has been approved we can update all the documentation, READMEs, and composer requires.

Namespace for the template is: drupal/sector_project_template

Namespace for the profile is: drupal/sector

dieuwe → created an issue.

dieuwe → created an issue.

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

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

The problem is that the requirement for guzzle/guzzle7 is a hard requirement through the league/omnipay package. Drupal core 9.5 does have the multiple version ranges allowed (6 and 7).

I think with D9 EOL so close and jumps to D10 needing to happen in the next few months this is probably a fine caveat.

We could probably do "league/omnipay": "^3.0 || ^3.2", in commerce_dps to allow for both D9+D10 and PHP7+PHP8 support to co-exist for a bit longer.

Switching to needs review instead of RTBC for now, and will come back to this once I have done more testing.

I wonder if the dependencies for this module should be more permissive or is that a separate issue? (use ^ instead of ~)