weierophinney
Repos
384
Followers
2359
Following
4

Standards either proposed or approved by the Framework Interop Group

12356
2378

Official Zend Framework repository

5582
2588

Tools for manipulating CHANGELOG.md files in Keep A Changelog format, including tagging and releasing.

171
20

PSR HTTP Message implementations

330
42

PSR-15 Middleware Microframework

276
45

PSR-7 middleware foundation for building and dispatching middleware pipelines

43
8

Events

[RFC]: Allow better constraint handling for PHP

@dereuromark Another way of putting this is: we cannot say that the component runs on a new minor or major version of PHP without first proving it passes tests. Having our constraints more strict ensures that we deliberately bump the constraints for new PHP versions via a patch in order to verify that tests pass in our CI.

This actually protects you the consumer.

In the past, when we had more liberal constraints, consumers would install the library in a new PHP version, run into issues, and open tickets to report them. This meant we were reactively fixing them, and as fast as possible, as we were now breaking a deployed application; it also meant we often didn't see all the potential issues immediately, leading to a scattershot of bugfix releases.

With the approach we've adopted, if you can install the library on a given PHP version, you can be assured it has actually been tested on that version, and that you should not run into compatibility issues.

Created at 18 hours ago
issue comment
Add a command to print the application's routing table

So, how should the code load the routes so that it can get access to the information?

Since commands are typically run in the project root, you can generally assume that you can load the routes file using require 'config/routes.php';. This file, and the config/pipeline.php file, returns an anonymous function, which accepts three arguments:

  • A Mezzio\Application instance
  • A Mezzio\MiddlewareFactory instance
  • The PSR-11 container instance

Once that function has been called, the Mezzio\Router\RouteCollector instance should be fully populated, and you can loop over its getRoutes() method to introspect the various Mezzio\Router\Route instances.

Your command will need to either accept all three of the above objects to its constructor, or you could have it accept just the container, and then pull the other two from the container when you are ready to create the routing table.

As a minimal example:

class RoutingTableCommand extends Commands
{
    public function __construct(private ContainerInterface $container)
    {
        parent::__construct();
    }

    protected function configure(): void
    {
         // setup command information here, such as options or arguments
    }

    protected function execute(InputInterface $input, OutputInterface $outptu): int
    {
        // create routing table
        (require 'config/routes.php')(
            $this->container->get('Mezzio\Application'),
            $this->container->get('Mezzio\MiddlewareFactory'),
            $this->container
        );

        $routes = $container->get('Mezzio\Router\RouteCollector');

        // iterate over the routes
        foreach ($routes->getRoutes() as $route) {
        }

        return 0;
    }
}
Created at 1 week ago
issue comment
Drop PHP 7.4 and add support for `psr/link` v2

Supporting both would mean a new BC break release once we drop v1 (due to added signatures)

So, the PSR evolution by-law suggests doing a new minor that targets 1.1, and which adds only a return typehint, as that's technically a non-BC break; however, the by-law misses that any class extending the implementation would experience a BC break unless they add the return typehint, as they'd be widening the return type.

And, of course, as soon as you also add support for the new major of a PSR, you MUST jumpt to a new major in your implementation, due to the signature change, even if you support both versions (and we could support both 1.1 and 2.0 at that point).

So, :+1: from me to bump to new major, and I think we can do ^1.1 || ^2.0 when we do (but verify!).

Created at 1 week ago

Automated deployment: Mon Sep 26 11:00:58 UTC 2022 master

Created at 1 week ago

Automated deployment: Thu Sep 22 06:11:57 UTC 2022 master

Created at 1 week ago

Automated deployment: Sat Sep 17 12:09:53 UTC 2022 1.4.0

Created at 2 weeks ago
weierophinney delete branch meetings/sep-2022
Created at 3 weeks ago

fix: attribute agenda items to Gary Lockett

Signed-off-by: Matthew Weier O'Phinney matthew@weierophinney.net

Created at 3 weeks ago
Better default branch rules

Feature Request

| Q | A |------------ | ------ | New Feature | yes | RFC | no | BC Break | yes, but in a good way

Summary

When a branch targetting a new major exists, no releases have been made for that new major, and a release against current major is created, the action will set the default branch to the new major branch on completion. This causes maintenance issues, as:

  • New bugfixes and features coming in are created against the new major branch.
  • Renovate creates patches against the new major branch.

As the new major is often a long-lived branch while longer refactoring is performed, these mean that the maintainer and/or contributor have to retarget pull requests, and, worse, a new minor branch for the existing major needs to be manually created and pushed before doing so.

The expected behavior:

  • When a release is created,
    • The next release branch should always be calculated as a new minor.
  • If the calculated new branch version is higher than the default branch version
    • Then set the new branch version as the default branch.
    • Else, do not reset the default branch.

(Discussed during the September 2022 TSC meeting.)

Created at 3 weeks ago
2022-09-12 TSC meeting minutes
  • Provides minutes for the 2022-09-12 TSC meeting
  • Resets the agenda for the 2022-10-03 TSC meeting
Created at 3 weeks ago
weierophinney create branch meetings/sep-2022
Created at 3 weeks ago

Add proposal for laminas-mvc-view

Signed-off-by: George Steel george@net-glue.co.uk

Merge pull request #125 from gsteel/propose-packages-to-decouple-view-from-mvc

Add proposal for laminas-mvc-view

Created at 3 weeks ago
Modify multiple slash in URI path detection

The approach to only normalize on getPath() makes sense to me, except in one scenario: an instance where there is no scheme or authority defined. In that case, the string representation contains only the path, which in this case would have multiple leading slashes, leading to the vulnerability.

HOWEVER, that said, the PSR-7 spec does account for this in the docblock of the request __toString() method:

  • If the path is starting with more than one "/" and no authority is present, the starting slashes MUST be reduced to one.

Regarding this:

What's not covered is how you return the path for an URI object whose string representation is https://example.com///wrong-website.tld

The URI is considered valid per RFC-3986, but currently triggers the CVE noted in the patch description when emitting only the path without normalizing the leading slashes. That's what we're trying to avoid here. If we go the route you are suggesting, getPath() would return /wrong-website.tld, while __toString() would return it verbatim. The full URI string representation is fine; it's only when emitting only the path that the CVE is triggered, and that includes using it in Location headers, or when using origin-form for creating an HTTP request (where the path + query string is used).

As such, I'd be willing to update this patch as follows:

  • Validate that getPath() normalizes the path to reduce multiple leading slashes to one.
  • Validate that __toString() normalizes the path to reduce multiple leading slashes to one IF AND ONLY IF no authority is present in the instance; otherwise, the any leading slashes would be emitted as-is.
  • Validate that RequestInterface::getRequestTarget(), when emitting origin-form, normalizes the path to reduce multiple leading slashes to one. (This should always be the case if the implementation uses getPath(), but it's good to validate.)

If everyone agrees to this, I'll make the changes for the final review.

Created at 3 weeks ago

docs: 2.12.1 readiness

docs: bumps changelog version to 2.12.2

Created at 1 month ago
weierophinney create tag 2.12.1
Created at 1 month ago
delete branch
weierophinney delete branch hotfix/github-api-token
Created at 1 month ago

fix: ensure release targets work

Discovered when releasing 2.12.0: In 3.4 of knplabs/github-api, the Client::AUTH_* constants were deprecated in favor of AuthMethod::* constants; in later versions in the 3.x release, the original constants were removed (a BC break).

This patch updates to use the AuthMethod constants, and pins to 3.4 and later to ensure they work.

Merge pull request #111 from phly/hotfix/github-api-token

Ensure release target commands work

Created at 1 month ago
pull request closed
Ensure release target commands work

Discovered when releasing 2.12.0: In 3.4 of knplabs/github-api, the Client::AUTH_* constants were deprecated in favor of AuthMethod::* constants; in later versions in the 3.x release, the original constants were removed (a BC break).

This patch updates to use the AuthMethod constants, and pins to 3.4 and later to ensure they work.

Created at 1 month ago
pull request opened
Ensure release target commands work

Discovered when releasing 2.12.0: In 3.4 of knplabs/github-api, the Client::AUTH_* constants were deprecated in favor of AuthMethod::* constants; in later versions in the 3.x release, the original constants were removed (a BC break).

This patch updates to use the AuthMethod constants, and pins to 3.4 and later to ensure they work.

Created at 1 month ago
create branch
weierophinney create branch hotfix/github-api-token
Created at 1 month ago
weierophinney create tag 2.12.0
Created at 1 month ago

docs: 2.12.0 readiness

docs: bumps version to 2.12.1

Created at 1 month ago
delete branch
weierophinney delete branch dependabot/composer/guzzlehttp/guzzle-7.5.0
Created at 1 month ago

build(deps): bump guzzlehttp/guzzle from 7.2.0 to 7.5.0

Bumps guzzlehttp/guzzle from 7.2.0 to 7.5.0.


updated-dependencies:

  • dependency-name: guzzlehttp/guzzle dependency-type: indirect ...

Signed-off-by: dependabot[bot] support@github.com

qa: apply automated phpcs fixes

Removes @license and @copyright annotations

fix: bump guzzle7 adapter to 1.0

Ensures we get a guzzle psr7 2.4 version, resolving conflict introduced by dependabot.

Merge branch '2.12.x' into dependabot/composer/guzzlehttp/guzzle-7.5.0

refactor: use composer-runtime-api for purposes of reporting version

  • Adds dependency on composer-runtime-api v2
  • Removes dependency on ocramius/package-versions

fix: fixes test assumptions

Prophesize returns null if no rules have been setup for a method. This works fine in many cases, but if the return value is not nullable, this will raise a type error in PHP 8 and above. As such, we need to specifically define such rules when the return value is non-nullable.

Merge pull request #110 from phly/dependabot/composer/guzzlehttp/guzzle-7.5.0

build(deps): bump guzzlehttp/guzzle from 7.2.0 to 7.5.0

Created at 1 month ago