Make ancestorClass option consistency to underscore by shakaran · Pull Request #351 · KnpLabs/KnpMenu

shakaran · 2021-08-31T09:38:55Z

Applied renaming over the repo with:

grep -ril ancestorClass | xargs sed -i 's@ancestorClass@ancestor_class@g'

garak

We can't just change an option like this.
We need to keep BC: add new option, deprecate old option. Then we can remove old option in the next major version.

shakaran · 2021-08-31T12:34:25Z

We can't just change an option like this.
We need to keep BC: add new option, deprecate old option. Then we can remove old option in the next major version.

I just add deprecation contracts as symfony way and allow the support for both options during the transition for avoid BC. Let me know if it suitable for you now

src/Knp/Menu/Renderer/ListRenderer.php

doc/examples/01_apply_active_class_to_whole_tree.md

src/Knp/Menu/Renderer/ListRenderer.php

stof · 2021-08-31T12:53:06Z

src/Knp/Menu/Resources/views/knp_menu.html.twig

        {%- set classes = classes|merge([options.currentClass]) %}
    {%- elseif matcher.isAncestor(item, options.matchingDepth) %}
-        {%- set classes = classes|merge([options.ancestorClass]) %}
+        {# ancestorClass will be deprecated in future, use ancestor_class #}


this does not report the deprecation AFAICT.

Done in 24fa9c2

composer.json

garak · 2021-08-31T15:12:10Z

.github/workflows/build.yaml

                  php-version: ${{ matrix.php }}
            - run: |
-                  sed -ri 's/"symfony\/(.+)": "(.+)"/"symfony\/\1": "'${{ matrix.symfony }}'"/' composer.json;
+                  sed -ri '/symfony\/deprecation-contracts/!s/"symfony\/(.+)\symfony\/deprecation-contracts/;": "(.+)"/"symfony\/\1": "'${{ matrix.symfony }}'"/' composer.json;


we need a space between ! and s

you added it before the wrong s...

Wow, this was giving me a headache. Thanks for the charm.

Ready to merge?

shakaran · 2021-09-14T10:51:50Z

Please, let me know if there are something more needed to get this merged. I would like sent the next PR with the other options

shakaran · 2021-10-12T19:36:51Z

One month later, I still didn't receive feedback about why the PR is not merged or if I need to change something.

garak · 2021-10-13T06:35:13Z

One month later, I still didn't receive feedback about why the PR is not merged or if I need to change something.

I'm sorry to see your expectations about time disappointed. Unfortunately, there's no guarantee about that, since everyone is working in their free time.

shakaran · 2021-11-24T15:02:58Z

Please @stof there are any chance that this will be approved soon? I would like integrate the changes in other of my projects

It should be quick to check for you. Thanks for your time.

shakaran · 2022-01-26T12:53:23Z

Should I fork this project and create a parallel project since maintainers doesn't have time to attend issues or resolve the pull request?

I know that everybody is working in his free time here.

But if main maintainers don't have time, the open source community dies, and the workaround is assign new people that wants to contribute, or in my side I only have the option to fork (which I don't like to do it, but if more time without response or progress I will have to initiate)

stof · 2022-01-26T14:35:35Z

The issue I have with accepting this PR is that I'm totally unsure about the effectiveness of the BC layer. There are 2 places impacted by this renaming:

passing the option to knp_menu_render: this BC layer is easy
using the option in the template: this one is hard, because we need to account for projects using custom templates (either migrated or not migrated yet), and for custom templates that then extend our default template

And I'm even less sure about the effectiveness of the deprecation warnings for that second case.

This means that this PR is risky, without much benefit (the existing name still works fine), while I only have limited free time dedicated to this project, and the same seems to be true for @garak

…estor_class deprecation

shakaran · 2022-01-26T17:20:35Z

First, thanks @stof for your time and quick response today.

The issue I have with accepting this PR is that I'm totally unsure about the effectiveness of the BC layer. There are 2 places impacted by this renaming:

passing the option to knp_menu_render: this BC layer is easy

I try to catch the deprecation in twig render here 4abbba4

The test is not fully working, I don't know exactly how to mock the deprecation, so I need a bit of help with that lines. Peer review and suggestions are appreciated.

using the option in the template: this one is hard, because we need to account for projects using custom templates (either migrated or not migrated yet), and for custom templates that then extend our default template

I am not sure of this case, could you provide a example of project in that situation, so I can see the problem?

And I'm even less sure about the effectiveness of the deprecation warnings for that second case.

In theory, if this is released under a new version, they can use old version without BC until we can figure out how to address the problem.

This means that this PR is risky, without much benefit (the existing name still works fine), while I only have limited free time dedicated to this project, and the same seems to be true for @garak

The idea here when this PR gets accepted, is send more PR with the other names affected and close the issue of options consistency #171

stof · 2022-01-26T18:51:10Z

@shakaran the whole point of using deprecations is to allow to release the change in a minor version (so without BC breaks) and having projects than migrate their code based on the warnings they get.
Just doing a major version to allow us to do BC breaks without a BC layer is not a good option: projects won't know what they need to change to be compatible, which is a bad upgrade path. And this would not even fail when they fail to migrate, but more likely silently ignore their options, which is the worse kind of BC breaks as you might never discover that you are affected, until you do some WTF debugging long after upgrading the package.

The idea here when this PR gets accepted, is send more PR with the other names affected and close the issue of options consistency #171

and fixing this consistency issue is about theoretical purity, not about actually making this package better for its user. The benefit of fixing this is small (it would help people learn the right option name without looking in the doc), but doing so at a high cost would be a no-go.
My comment from 2014 on this issue still holds: fixing this inconsistency would be good if we can provide a full BC layer. Otherwise, the cost on the ecosystem is too high (and the fact that I have limited time to spend on that project means that I definitely don't want to create a situation where upgrade paths provide WTF situations where users would then report issues on the repo to get help that I would not have time to provide)

The test is not fully working, I don't know exactly how to mock the deprecation, so I need a bit of help with that lines.

When using the symfony/phpunit-bridge deprecation reporting for the testsuite (which we do), you need to use the trait of that package to define deprecation expectations instead of relying on the expectDeprecation feature provided by PHPUnit itself.

shakaran · 2022-01-26T20:08:13Z

@shakaran the whole point of using deprecations is to allow to release the change in a minor version (so without BC breaks) and having projects than migrate their code based on the warnings they get. Just doing a major version to allow us to do BC breaks without a BC layer is not a good option: projects won't know what they need to change to be compatible, which is a bad upgrade path. And this would not even fail when they fail to migrate, but more likely silently ignore their options, which is the worse kind of BC breaks as you might never discover that you are affected, until you do some WTF debugging long after upgrading the package.

Ok, minor release then (3.3) as pointed. As far it gets merged and released finally.

The idea here when this PR gets accepted, is send more PR with the other names affected and close the issue of options consistency #171

and fixing this consistency issue is about theoretical purity, not about actually making this package better for its user. The benefit of fixing this is small (it would help people learn the right option name without looking in the doc), but doing so at a high cost would be a no-go. My comment from 2014 on this issue still holds: fixing this inconsistency would be good if we can provide a full BC layer. Otherwise, the cost on the ecosystem is too high (and the fact that I have limited time to spend on that project means that I definitely don't want to create a situation where upgrade paths provide WTF situations where users would then report issues on the repo to get help that I would not have time to provide)

After this PR gets accepted I will provide the other cases and options rewriten with BC layer support of deprecations.

The test is not fully working, I don't know exactly how to mock the deprecation, so I need a bit of help with that lines.

When using the symfony/phpunit-bridge deprecation reporting for the testsuite (which we do), you need to use the trait of that package to define deprecation expectations instead of relying on the expectDeprecation feature provided by PHPUnit itself.

ok, I added, but it seems that for Symfony 4.4 with PHP 7.4 it breaks since no trait available

stof · 2022-01-26T20:13:35Z

@shakaran this is an issue in the way Symfony-specific jobs are configured. The phpunit-bridge should not be affected (it is a special component, that is not replaced by the monorepo package either)

shakaran · 2022-01-27T14:15:23Z

e in the way Symfo

ok, then, it is good to merge, or do you need that I make more changes? Thanks

shakaran · 2022-08-19T09:42:26Z

@stof almost a year for get this merged. Please, could you consider it? Thanks, only remains your approve vote

garak

A rebase is needed

stof · 2025-12-09T09:50:17Z

My comment in #351 (comment) still reflects my opinion on this subject.

And my comment in #351 (comment) describes the hard parts of the Twig BC layer. The second point is still not solved IMO (users can implement their own templates to customize the rendering, in which they could read the options.

shakaran · 2025-12-09T10:42:27Z

I am not sure how to resolve the worflow broken for PHP 8.1 and Symfony 6, it seems a weird dependency hell.

I am not sure if 8.1 should be supported since is EOL.

stof · 2025-12-09T10:47:04Z

Workflow changes should be submitted as a dedicated PR doing only that IMO.

Make ancestorClass option consistency to underscore

ff8864b

shakaran mentioned this pull request Aug 31, 2021

Options inconsistency #171

Open

garak requested changes Aug 31, 2021

View reviewed changes

shakaran added 2 commits August 31, 2021 14:28

Require symfony/deprecation-contracts for trigger warnings

4fc676d

Add deprecation contracts and allow both ways for support BC

df85637

shakaran requested a review from garak August 31, 2021 12:34

garak requested changes Aug 31, 2021

View reviewed changes

src/Knp/Menu/Renderer/ListRenderer.php Outdated Show resolved Hide resolved

doc/examples/01_apply_active_class_to_whole_tree.md Outdated Show resolved Hide resolved

shakaran added 2 commits August 31, 2021 14:44

Fix if spaced as per review suggested

d2b325b

Revert changes in doc for deprecated way as per review suggested

d7a3399

shakaran requested a review from garak August 31, 2021 12:47

garak requested changes Aug 31, 2021

View reviewed changes

src/Knp/Menu/Renderer/ListRenderer.php Outdated Show resolved Hide resolved

stof reviewed Aug 31, 2021

View reviewed changes

shakaran added 5 commits August 31, 2021 15:04

Update version number for deprecation

3aeb687

Improve warning message for twig deprecation as per review suggested

24fa9c2

Merge branch 'master' into ancestor_class_underscore

4103108

Update test for show as legacy deprecation warnings

05e3231

Avoid duplication of configs and show deprecations warnings too

5bf59b9

garak requested changes Aug 31, 2021

View reviewed changes

composer.json Outdated Show resolved Hide resolved

shakaran added 4 commits August 31, 2021 15:53

Update php version in composer

5ae265b

Try to avoid replacements by deprecation contracts in github build

10569aa

Try another sed vudu way

abdeda8

Add exclusion pattern /pattern/!s/pattern/

ae50e57

garak reviewed Aug 31, 2021

View reviewed changes

shakaran and others added 3 commits August 31, 2021 17:22

Update the sed vudu charm

98046aa

Vudu sed require a space

4ef0026

Update build.yaml

d82c70f

shakaran requested review from garak and stof September 1, 2021 10:23

garak approved these changes Sep 1, 2021

View reviewed changes

Add support deprecation for knp_menu_render and knp_menu_get with anc…

4abbba4

…estor_class deprecation

shakaran added 6 commits January 26, 2022 20:47

Use ExpectDeprecationTrait for deprecation message

9c5797c

Add @group Legacy or Legacy in name for allow pass test in CI

78608e3

Mistake preprend at beginning legacy

742aacc

Add as annotation since CI don't recognize

9de5229

Remove message since expects empty message for trait

c42343b

Add empty string message for deprecation instead null

a4bc394

garak requested changes Dec 11, 2024

View reviewed changes

Merge branch 'master' into ancestor_class_underscore

ace85c6

shakaran added 5 commits December 9, 2025 10:52

fix: specify matrix symfony missing in merge

d52c87a

fix: add missing deprecation

d46e0ba

fix: support symfony 6 with php 8.1 for symfony/deprecation-contracts

c779192

fix: specify only concrete version of symfony 6.4

546edcd

feat: allow 3.0 versions

94b8b1b

shakaran mentioned this pull request Dec 9, 2025

feat: update worflow and composer to PHP 8.2 or upper #418

Open

Conversation

shakaran commented Aug 31, 2021

Uh oh!

garak left a comment

Choose a reason for hiding this comment

Uh oh!

shakaran commented Aug 31, 2021

Uh oh!

Uh oh!

Uh oh!

Uh oh!

stof Aug 31, 2021

Choose a reason for hiding this comment

Uh oh!

shakaran Aug 31, 2021

Choose a reason for hiding this comment

Uh oh!

Uh oh!

garak Aug 31, 2021

Choose a reason for hiding this comment

Uh oh!

stof Aug 31, 2021

Choose a reason for hiding this comment

Uh oh!

shakaran Aug 31, 2021

Choose a reason for hiding this comment

Uh oh!

shakaran commented Sep 14, 2021

Uh oh!

shakaran commented Oct 12, 2021

Uh oh!

garak commented Oct 13, 2021

Uh oh!

shakaran commented Nov 24, 2021

Uh oh!

shakaran commented Jan 26, 2022

Uh oh!

stof commented Jan 26, 2022

Uh oh!

shakaran commented Jan 26, 2022

Uh oh!

stof commented Jan 26, 2022

Uh oh!

shakaran commented Jan 26, 2022

Uh oh!

stof commented Jan 26, 2022

Uh oh!

shakaran commented Jan 27, 2022

Uh oh!

shakaran commented Aug 19, 2022

Uh oh!

garak left a comment

Choose a reason for hiding this comment

Uh oh!

stof commented Dec 9, 2025

Uh oh!

shakaran commented Dec 9, 2025

Uh oh!

stof commented Dec 9, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants