I just stumbled on this issue, but the cause was pretty dumb on my side: I was upgrading Rector (0.12) to newer versions (0.14-0.15) without upgrading the config to the new RectorConfig format. That forced the "unprefixing" issue.

Hope this will help someone stuck on the same error.

docs: Highlight sudo (#10367)

Fix PHP x spacing

$home -> $COMPOSER_HOME (#10363)

the $home variable referenced in the conifguration docs for data- and cache-dir is a reference to an internal PHP variable that contains the composer home directory.

as on the documentation page it is not visible where that variable comes from (the document uses only shell/environment variables otherwise) these two places are hard to read/understand.

the exact meaning of $home (lowercase) is the composer-home (or just home) global configuration setting (composer home is for all user-wide composer invocations, to store data in the filesystem namespace of the user executing composer).

that meaning is better documented with the $COMPOSER_HOME environment variable (which when it does not exists the default value is well documented in [03-cli.md#composer-home].

replace $home with $COMPOSER_HOME.

additionally small typo fix on "rollback" which is "roll back".

discussion: #10363 [03-cli.md#composer-home]: doc/03-cli.md#composer-home

Fix minor spelling & grammar issues in docs (#10370)

Fix display of conflicts when a rule has the conflicter out of order, fixes #10355

Fix phpstan

Switch the default version in path repo packages to dev-main and add a dev-master alias for BC, fixes #10360 (#10372)

Add --no-scripts to all commands and disable plugins/scripts when running self-update (#10371)

• Add --no-scripts as global parameter available to all commands, and handle it by default when creating a Composer instance from Command::getComposer

• Disable scripts/plugins for self-update command, fixes #10351

Disable files autoloading for scripts to avoid untrusted code execution at runtime (#10373)

Add test verifying only plugin deps are autoloaded (#10374)

Update changelog

Fix autoloader compatibility with older releases of laminas/laminas-zendframework-bridge, refs #10349

Use web URLs for Gitlab support metadata (#10377)

Update baseline

Release 2.2.0

Reverting release version changes

Fix plugin autoloading including files autoload rules from the root package, fixes #10382 (#10386)

Fix issue parsing php files with unterminated comments found inside backticks, fixes #10385

Update changelog

Release 2.2.1

#702 was opened as a duplicate of this one. There seems to be still request for this change.

Environment

When running Symfony Messenger in background, the Sentry HubInterface is a great way of marking up the hub with breadcrumbs to provide additional debugging context around the userland code. This works especially well when using the Symfony Messenger middleware, and checking the envelope for certain stamps.

The problem is, background jobs typically run for more than one event (contrary to http requests), and thereby by default state is shared across events: https://symfony.com/doc/current/messenger.html#stateless-worker

The ResetInterface was introduced to support in that, so the container can collect services that need to be resetted after events are handled.

Steps to Reproduce

1. add middleware or handler that adds breadcrumb to the HubInterface
2. run messenger in background
3. consume messages that lead to exceptions
4. second Sentry issue report will contain the breadcrumbs of the previous event

Expected Result

One breadcrumb should be added per event.

Actual Result

As many breadcrumbs are added as events that were processed by the worker, as state is shared and not resetted by the container. So, the first issue event in Sentry has one breadcrumb, the second issue event has two (read: unintentionally includes the first breadcrumb).

I searched a bit, and I found this comment: https://github.com/getsentry/sentry-symfony/issues/672#issuecomment-1311465922

Even, this issue is a duplicate of #672. I'm closing this and cross-referencing it, please refer to that one.

IIRC this was intentionally left like that, and the breadcrumb limit would truncate too much data if needed. If you want a different behavior, you can probably use scopes? And push/pop them when needed.

I'm requested a review here from the whole CC since our mailing list seems to be malfunctioning: https://twitter.com/phpfig/status/1634109600424132609

I think we'll need to wait for feedback from all of them due to this problem.

Fix title level

Apply changes to avoid accepting donations; clarify wording using RFC 2119

Ehi @ciaranmcnulty, how do you want to proceed? We have 3 PRs in a row, in a deadlock due to circular dependency_

• this one
• https://github.com/phpspec/prophecy/pull/585
• https://github.com/phpspec/prophecy-phpunit/pull/45

As I said in https://github.com/phpspec/phpspec/pull/1443#issuecomment-1445498910, your proposal of an "allow failure" job is not possible. Would you be ok with a job that forcibly required PHPUnit 10 and fails on all 3 repos, and subsequent PRs to fix those failures?

Add Paraunit 2.0.0 release announcement

Upgrade theme and Hugo binary

Fix post order with Paraunit 0.12/0.12.1

Fix menu active status

publish: Fix menu active status

generated from commit cbb503122d33c0cc85190888435a6509e2f47833

I just upgraded from Hugo 0.80 to 0.111.1, and pulled this theme (from b1d3ae0 to e9bce51) and I noticed, on the deployed site, that the menu__item--active class was gone in multiple pages.

This means that the menu element is no longer highlighted when that's the current page.

This is the offending piece of code: https://github.com/Vimux/Mainroad/blob/e9bce51b09d8a48fd66808f6d5382074c9584c30/layouts/partials/menu.html#L7-L18

It didn't change due to my pull, so I don't know why it stopped working.

Yes I did, but it appears that I misunderstood it.

I've now fixed it by adding the pageRef attribute to each menu entry. Sorry for the misunderstanding.

Hugo 0.86.0 сhangelog?

https://github.com/gohugoio/hugo/releases/tag/v0.86.0

I noticed that the Hugo docs report some changes about it in 0.86: https://gohugo.io/functions/hasmenucurrent/ Also, the example in the docs seems coherent with that we do here: https://gohugo.io/templates/menu-templates/

I just upgraded from Hugo 0.80 to 0.111.1, and pulled this theme (from b1d3ae0 to e9bce51) and I noticed, on the deployed site, that the menu__item--active class was gone in multiple pages.

This means that the menu element is no longer highlighted when that's the current page.

This is the offending piece of code: https://github.com/Vimux/Mainroad/blob/e9bce51b09d8a48fd66808f6d5382074c9584c30/layouts/partials/menu.html#L7-L18

It didn't change due to my pull, so I don't know why it stopped working.

publish: Upgrade theme and Hugo binary

generated from commit ea5a4a0aec57d9686739f120af3196277e7370e1

publish: Add Paraunit 2.0.0 release announcement

generated from commit 9a6e63dddfc74f87f52f83e9ece949f2748c15d3

publish: Add 2.0.0 release news

generated from commit ad46736ed1f1b7650422ef65b5db1066856ad75c

Release 2.0.0

PHPStan was previously capped at 1.9.x in b0d92a32b9fc2052db6cb6f58bac915c9eeacfde due to phpstan/phpstan#8983, which is now resolved in PHPStan 1.10.4. This PR requires that version, but to complete we need that the same is done inside Rector.