mezzio / mezzio-flash

Flash messages for PSR-7 and PSR-15 applications using mezzio-session

mezzio

Develop PSR-7 middleware applications in minutes!

mezzio builds on laminas-stratigility to provide a minimalist PSR-7 middleware framework for PHP, with the following features:

• Routing. Choose your own router; we support:
  • Aura.Router
  • FastRoute
  • laminas-router
• DI Containers, via PSR-11 Container. Middleware matched via routing is retrieved from the composed container.
• Optionally, templating. We support:
  • Plates
  • Twig
  • Laminas's PhpRenderer

Installation

We provide two ways to install Mezzio, both using Composer: via our skeleton project and installer, or manually.

Using the skeleton + installer

The simplest way to install and get started is using the skeleton project, which includes installer scripts for choosing a router, dependency injection container, and optionally a template renderer and/or error handler. The skeleton also provides configuration for officially supported dependencies.

To use the skeleton, use Composer's create-project command:

composer create-project mezzio/mezzio-skeleton <project dir>

This will prompt you through choosing your dependencies, and then create and install the project in the <project dir> (omitting the <project dir> will create and install in a mezzio-skeleton/ directory).

Manual Composer installation

You can install Mezzio standalone using Composer:

composer require mezzio/mezzio

However, at this point, Mezzio is not usable, as you need to supply minimally:

• a router.
• a dependency injection container.

We currently support and provide the following routing integrations:

• Aura.Router: composer require mezzio/mezzio-aurarouter
• FastRoute: composer require mezzio/mezzio-fastroute
• laminas-router: composer require mezzio/mezzio-laminasrouter

We recommend using a dependency injection container, and typehint against PSR-11 Container. We can recommend the following implementations:

• laminas-servicemanager: composer require laminas/laminas-servicemanager
• Pimple (see docs for more details): composer require laminas/laminas-pimple-config
• Aura.Di (see docs for more details): composer require laminas/laminas-auradi-config

Additionally, you may optionally want to install a template renderer implementation, and/or an error handling integration. These are covered in the documentation.

Documentation

Documentation is in the doc tree, and can be compiled using mkdocs:

mkdocs build

Additionally, public-facing, browseable documentation is available at https://docs.mezzio.dev/mezzio/

mezzio-flash's Issues

Provide method to fetch FlashMessages from Request

Feature Request

Q	A
New Feature	yes
RFC	no
BC Break	no

Summary

In my own middlewares I like to add a static method in the Middleware to fetch the respective instance from the reqeust. This way I don't have to check everytime if the return is null and also don't have to manually assign the type for my IDE. For the FlashMessageMiddleware that would look something like that:

    public static function flashMessages(ServerRequestInterface $request): FlashMessages
    {
        return $request->getAttribute(self::FLASH_ATTRIBUTE);
    }

If the middleware has not been processed in the pipeline, a TypeError is thrown, so I can be sure I'll always get the correct object.
The problem with the current implementation of the FlashMessageMiddleware is, that you can set a custom attributeKey, so that complicates it a little bit (in my middlewares the attribute constants are private, so the only "official" way to fetch the object from the Request is via the static method). That could be mitigated in providing an optional second (deprecated?) parameter for the static method. Why did you event allow setting a custom attribute key?
Would you be open for such a change or should I keep using my own wrapper for this middleware?

flashNow() messages persist beyond the current request

Bug Report

Summary

Messages set with flashNow() persist beyond the current request. I found this surprising and inconvenient, but feel like maybe it's intended. So I'll explore it here and suggest some potential changes.

Current behavior

Messages added via flashNow() are visible immediately, in the request in which they're added, and again in the subsequent request. Note that this does not contradict the documentation, which says:

When you create a flash message, it is available in the next request, but not the current request. If you want access to it in the current request as well, use the flashNow() method instead of flash():

(Emphasis mine)

If this is in fact the expected behavior, I'm somewhat astonished.

How to reproduce

Implement the fairly common pattern of a form submission that redirects on success, but re-renders the form in the response to the POST on error. Use flashNow() in the error branch to display a message in the response (relying on the default $hops = 1) argument value). Resubmit the form so that the submission succeeds, and and the response redirects the user. Note that the error-info set via flashNow() is now displayed a second time.

Expected behavior

I'd expect messages set with flashNow() to be visible exclusively in the current request, at least by default.

A strongly-opinionated change would be to simply remove the call to $this->flash(...) in the flashNow() implementation (and remove the $hops argument from flashNow() as well, I suppose).

A more flexible fix would be to allow flash() to accept a $hops of zero, and change the default for flashNow() to zero $hops.

Unfortunately, both of those options break BC. A BC-preserving fix would be to simply allow zero $hops. Then users of the class could at least get the behavior they'd like out of the implementation.

As it stands now, I had to "write" my own implementation of FlashMessagesInterface that behaves as I'd expect. But that implementation was "copy FlashMessages and remove one line", which feels dirty and makes me sad.

Finally, I'll say that I feel like I'm probably missing some obvious use-case where the current behavior is expected. If someone enlightened me, my consternation might evaporate.

Divide message key further

Currently, the key of the message is probably mainly used for the corresponding category "warning, info, danger, success". However, if you now have two forms in the page, the evaluation of this information and the output is a bit tricky. It would be nice if you can add the corresponding form name in addition to the key.

currently:

$flashMessages->flash('danger', 'You need to supply your email address');

suggestion:

$flashMessages->flash('danger', 'You need to supply your email address', 'form-name'); // OR
$flashMessages->flash('form-name:danger', 'You need to supply your email address');

$flashMessages->getFlashByForm('form-name');

What do you all mean?

---

Originally posted by @mano87 at zendframework/zend-expressive-flash#10

Docs build needs fixing

Psalm integration

Feature Request

Q	A
QA	yes

Summary

As decided during the Technical-Steering-Committee Meeting on August 3rd, 2020, Laminas wants to implement vimeo/psalm in all packages.

Implementing psalm is quite easy.

Required

• Create a psalm.xml in the project root
• Copy and paste the contents from this psalm.xml.dist
• Run $ composer require --dev vimeo/psalm
• Run $ vendor/bin/psalm --set-baseline=psalm-baseline.xml
• Add a composer script static-analysis with the command psalm --shepherd --stats
• Add a new line to script: in .travis.yml: - if [[ $TEST_COVERAGE == 'true' ]]; then composer static-analysis ; fi
• Remove phpstan from the project (phpstan.neon.dist, .travis.yml entry, composer.json require-dev and scripts)

Optional

• Fix as many psalm errors as possible.

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Repository problems

These problems occurred while renovating this repository. View logs.

• WARN: Use matchDepNames instead of matchPackageNames

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• Lock file maintenance

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency phpunit/phpunit to v11

Detected dependencies

composer

composer.json

• php ~8.1.0 || ~8.2.0 || ~8.3.0
• mezzio/mezzio-session ^1.0
• psr/http-server-middleware ^1.0
• laminas/laminas-coding-standard ~2.5.0
• phpunit/phpunit ^10.2.2
• psalm/plugin-phpunit ^0.19.0
• vimeo/psalm ^5.13.1

github-actions

.github/workflows/continuous-integration.yml

.github/workflows/docs-build.yml

.github/workflows/release-on-milestone-closed.yml

---

• Check this box to trigger a request for Renovate to run again on this repository

PHP 8.0 support

Feature Request

Q	A
New Feature	yes

Summary

To be prepared for the december release of PHP 8.0, this repository has some additional TODOs to be tested against the new major version.

In order to make this repository compatible, one has to follow these steps:

• Modify composer.json to provide support for PHP 8.0 by adding the constraint ~8.0.0
• Modify composer.json to drop support for PHP less than 7.3
• Modify composer.json to implement phpunit 9.3 which supports PHP 7.3+
• Modify .travis.yml to ignore platform requirements when installing composer dependencies (simply add --ignore-platform-reqs to COMPOSER_ARGS env variable)
• Modify .travis.yml to add PHP 8.0 to the matrix (NOTE: Do not allow failures as PHP 8.0 has a feature freeze since 2020-08-04!)
• Modify source code in case there are incompatibilities with PHP 8.0