🇺🇸United States @hotwebmatter

Minor edits to issue summary

johnpicozzi → credited hotwebmatter → .

pebosi → commented 14 January 2021 at 07:58 [ #10 💬 Local mirrror of packages.drupal.org in Artifactory Postponed: needs info ]

I had the same problem using sonatype and packages.drupal.org and i solved it using another solution: building a static repository with composer/satis mirroring packages.drupal.org.

Looking into this possibility for my organization now, and sharing some resources as a breadcrumb trail for others to follow:

Open-source options for self-hosted Composer repositories

Satis repository manager and Satisfy UI:

• Handling private packages > Satis (official Composer documentation)
• composer/satis README.md (official Satis GitHub repository)
• project-satisfy/satisfy README.md (Satisfy: Satis Composer repository manager with a simple web UI)
• eventum/composer README.md (Reference implementation of a static Composer repository provided by Satisfy)
• Setting up and securing a private Composer repository (article by Alex Vanderbist of Spatie)
• Private Satis authentication backed by Laravel (Part two of the article linked above; focus on the "securing" part)

Packeton (Satis fork):

• Official Packeton documentation
• vtsykun/packetonREADME.md

Hopefully, these resources will help others who need to host a private repository to mirror PHP/Composer packages and metadata, but cannot use jFrog Artifactory due to the bug documented here.

Wow. This may be the most beautiful Issue Queue in the history of Drupal.

<3

Tested Merge request !3

With unpatched module, http://d9.lndo.site/admin/config/system/m4032404 is redirected to 404, whether or not the "Enforce on Admin Only" boolean is set TRUE.

After applying patch, if no Pages are specified, the default behavior remains the same, and http://d9.lndo.site/admin/config/system/m4032404 is redirected to 404, whether or not the "Enforce on Admin Only" boolean is set TRUE.

After specifying /admin/config/system/m4032404 in Pages, the following behavior occurs:

• When "Redirect the above paths to 404" radio button is selected:
  

  $ wget --spider http://d9.lndo.site/admin/config/system/m4032404
  Spider mode enabled. Check if remote file exists.
  --2023-05-09 18:12:29--  http://d9.lndo.site/admin/config/system/m4032404
  Resolving d9.lndo.site (d9.lndo.site)... 127.0.0.1
  Connecting to d9.lndo.site (d9.lndo.site)|127.0.0.1|:80... connected.
  HTTP request sent, awaiting response... 404 Not Found
  Remote file does not exist -- broken link!!!

• When "Do not redirect the above paths to 404" radio button is selected:
  

  $  wget --spider http://d9.lndo.site/admin/config/system/m4032404
  Spider mode enabled. Check if remote file exists.
  --2023-05-09 18:12:40--  http://d9.lndo.site/admin/config/system/m4032404
  Resolving d9.lndo.site (d9.lndo.site)... 127.0.0.1
  Connecting to d9.lndo.site (d9.lndo.site)|127.0.0.1|:80... connected.
  HTTP request sent, awaiting response... 403 Forbidden
  Remote file does not exist -- broken link!!!

Reviewed and tested by the community.

This seems correct.

I will note, however, that the behavior appears to be sticky until caches are cleared.

So ... either invalidate caches for the specified routes when config is saved, or take the lazy route and add some text saying "Rebuild caches after saving configuration."

Does that make sense?

hotwebmatter → created an issue.

hotwebmatter → created an issue.

Upgraded Drupal container to use drupal:10-apache image. Note, however, that older images are available; refer to hub.docker.com/_/drupal for a list.

For what it's worth, I've duplicated the bug on a clean install of Drupal 9.5.3 while attempting to scan my Sessionize Embed Block → contrib module.

Error message
Error while parsing Sessionize Embed Block 1.0.1.

Fail while processing Sessionize Embed Block 1.0.1
Raw rector output shown below for debugging purposes. If you believe the errors are due to the tool used not the code processed, look for an existing issue or submit a new one for Drupal-rector.

 [ERROR] Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator::__construct(): Argument #1
         ($container) must be of type Symfony\Component\DependencyInjection\ContainerBuilder,
         RectorPrefix202302\Symfony\Component\DependencyInjection\ContainerBuilder given, called in
         /var/www/html/vendor/rector/rector/vendor/symfony/dependency-injection/Loader/PhpFileLoader.php on line 67

The Rector project GitHub issue linked in the issue summary above contains a possible workaround, but it involves patching the rector.php file. Unfortunately, there are several rector.php files in my vendor directory, and it's not clear which one I should patch:

$ find . -name rector.php                         
./vendor/rector/rector/vendor/rector/extension-installer/rector.php
./vendor/rector/rector/vendor/rector/rector-symfony/rector.php
./vendor/rector/rector/vendor/rector/rector-doctrine/rector.php
./vendor/rector/rector/vendor/rector/rector-phpunit/rector.php
./vendor/rector/rector/vendor/rector/rector-php-parser/rector.php
./vendor/rector/rector/vendor/symplify/easy-parallel/rector.php
./vendor/rector/rector/bin/rector.php
./vendor/drush/drush/rector.php
./vendor/palantirnet/drupal-rector/rector.php

hotwebmatter → created an issue.

hotwebmatter → created an issue.

This issue is fixed, and the project can now be installed via composer require.

As new dependencies are added to the project, we should add them to the composer.json in the same way.

Thanks for the patch, @cindy_codediaries → !

weekbeforenext → credited hotwebmatter → .

hotwebmatter → created an issue.

Create Issues for the following:

• Drupal.org infrastructure issue preventing composer install
• Unable to create a test Candidate

hotwebmatter → created an issue. See original summary → .