Hi, since I updated the project to composer v2, I got all release belt packages that go to 502 :

This is true on local and client server.

Any idea on this? thx :)

Ok this might not be a issue with release-belt but I'm not sure.

Composer installs and creates two directories and thus WordPress won't see or list the plugin installed from zip via release belt.

Example: wordpress-plugin/awesome/my-hello-dolly.1.0.0.zip

Composer installs into this path: plugins/my-hello-dolly/my-hello-dolly/

but should be: plugins/my-hello-dolly/

Am I missing something?

At the moment the version regex is overly simplistic with regex (|((?:\d+\.*){1,3})|) matching sequence of 1 to 3 version–like parts (digit(s) with a dot).

It needs to be more robust, but I do not want to force specific convention and renaming files on people. I want it to take wide (but reasonable) range of possibilities. See #4

I would like to collect example names from the wild for starters and iterate on regex from there.

If you provide or consume WP extensions in archives, please post example file names in this thread.

Collected examples

• backupbuddy-4.1.2.2.zip
• contact-form-7.4.1.zip
• facetwp-1.8.6.zip
• ga-ecommerce-3.0.2.zip
• google-analytics-premium-1.1.8.zip
• gravityforms_1.8.22.zip
• gravityformsmailchimp_3.2.zip
• mailchimp-for-wp-pro-2.5.5.zip
• nextgen-facebook.7.7.5.1.zip
• ninja-forms-mailchimp-v1.3.2.zip
• p3-profiler.1.5.3.6.zip
• searchwp-2.4.9.zip
• searchwp-term-highlight-1.8.7.zip
• sitepress-multilingual-cms.3.1.8.4.zip
• wp-retina-2x.2.4.0.zip
• wp-lightbox-2.zip
• wpml-translation-management.1.9.9.zip

No version (poke authors?)

• advanced-custom-fields-pro.zip
• wpseo.zip

Hello, again I've updated by composer belt-update then I have an error  In RemoteFilesystem.php line 398:     The "https://[public url redacted]/packages.json" file could not be downloa   ded (HTTP/1.1 404 Not Found)   And no packages.json on public folder. :-/

Hello, I updated to latest verison of release belt and have now an error on upgrade: DownloadinDownloading (failed)  In RemoteFilesystem.php line 515:     The "/js_composer/js_composer.5.5.5.zip" file could not be downloaded: fail   ed to open stream: No such file or directory   I have this zip file on my Release/wordpress-plugin directory. Do you have any idea of what's happened ?

I'm not able to pass the .htaccess. Without authentification it's working, but when uncommenting the users part in the config/config.php I can't reach the page with the boilerplate snippets anymore.

Any idea what I'm doing wrong?

'users'                    => [
        // User login.
        'foousername' => [
            // Provide password hash for HTTP authentication. See bin/encodePassword.php helper.
            'hash'     => '$2y$13$dz7N7JVEyMiDdmbLPqw0he9obf2/poDPLT02BRPHGlPm0UuLZ8kZ6', // test

            // Array of allowed package path matches.
            //'allow'    => ['advanced-custom-fields-pro'],

            // Array of disallowed package path matches.
            //'disallow' => [],
        ],
    ],

Symfony had just announced that Silex (you know, the bit this whole project is made on top of) is deprecated in favor of Symfony 4. :sob:

My knee jerk is that I didn't want to use Symfony before (that's why I use Silex) and don't want to use it now. Not because I dislike Symfony, but because it's enterprise framework that has way too much going on for my needs. I get that they say v4 is easier, but it still another thing to learn.

I will need to take a look at v4 and their suggestions for migration process (which are not yet written).

Regardless that will discard Pimple container with completely wrecking how services and configuration are currently handled. I much prefer Pimple to more "magical" containers and making sense of Symfony container specifically went zero well for me in the past.

So the possibilities I roughly see at the moment:

1. Full on Symfony 4 move.
2. Move to a different Silex–type framework (oh hai, Lumen, guess who is overdue to play with Laravel components!)
3. Move to a different framework that allows to keep Pimple container or use it via container PSR compat layer.

Similar to what has been done on WPackagist https://github.com/outlandishideas/wpackagist/pull/420

https://github.com/composer/installers/releases/tag/v2.0.0

At the moment every user has access to every package in the repository. As usage scenarios get more complicated it makes sense that more granular permissions can be needed.

My first thought on logic was whitelist with scenarios that are friendly to filesystem–centric mechanics:

• all of a type wordpress-plugin/*
• all of a vendor vendor-name/*
• all versions of a package package-name*
• arbitrary combination of the above

However I imagine there would be scenarios that this doesn't fit conveniently. Say user A needs 99/100 packages and user B needs 1/100. Whitelist is convenient to configure for latter, but not former.

From the implementation point of view I'd love if I could get this done just by throwing filters on Finder instance. However if it gets any elaborate I would likely need to introduce intermediary collection of releases for it.

Another point of consideration is anonymous access. Currently enabling any users disables public access completely. With more granular permissions it would make sense that anonymous user could be also granted access to specific packages.

Overall I'll note that my priority for authentication remains the same — keep it as clear and simple as possible. In my opinion anything elaborate would be realm of custom in–house solutions, probably with hard separation by multiple release dirs dynamically.

I spent over half an hour trying to work out why I was getting a 502 error when accessing the root folder after forcing https. Adding DirectoryIndex index.php solves it.

Is there a reason to define a platform with a specific PHP version in composer.json?

This removes the checks for the PHP version used by the environnement. If there's an error, the error will happend during runtime instead of being show during the installation of the packages.