IBX-12046: Removed Symfony and template deprecations triggered by admin-ui

[ViniTou]

🎫 Issue	IBX-12046

Related PRs:

• IBX-12606: Regenerated the deprecation baseline against current 6.0 dependencies #2113 — merged; this PR is rebased onto 6.0.
• IBX-12046: Configured property-info and Doctrine ORM explicitly in the test kernel test-core#58 — configures twig_component in the test kernel.

Description:

A Symfony 7.x deprecation that admin-ui causes in every kernel loading it, and which therefore sits in the integration baselines of 10–11 consumer repositories:

• Ibexa\AdminUi\Form\Type\Search\DateIntervalType: ~ defines a service for a class that does not exist (the real type is Date\DateIntervalType, which is what SearchType/TrashSearchType use), triggering "Service id … looks like a FQCN but no corresponding class or interface exists". The definition is dead and was removed.

admin-ui's own phpunit.integration.baseline.xml (the integration gate added in #2100) loses exactly the Search\DateIntervalType entry; nothing added (PHP 8.3 + 8.4, SQLite/MySQL/PostgreSQL give identical baselines). The unit phpunit.baseline.xml is unchanged (no kernel boots there). Cross-checked in scheduler with this branch installed: its regenerated integration baseline loses the DateIntervalType entry, nothing added.

The twig_component defaults (anonymous_template_directory, defaults) come from the symfony/ux-twig-component Flex recipe in projects; test kernels get them from ibexa/test-core#58 instead, so their two baseline entries stay here until that merges.

Also fixed the three template deprecations the integration gate (#2100) reports from TranslationTest — their messages carry the absolute template path, so #2100 baselines them with the CI checkout path; this PR removes those 3 entries again:

• Moved the Twig use and macro tags to the template root (Twig 3.28). form_fields.html.twig: the use inside content_type_meta_field_definition_enabled_row duplicated the root-level use of the same template and was dropped. modal_add_custom_url.html.twig: the info_text macro moved to a new content/tab/url/macros.html.twig (same pattern as dashboard/macros.html.twig, content_type/macros.html.twig), imported inside the embed — neither import _self inside an embed (refers to the embedded template) nor a root-level import (not visible in the embed's scope) works.
• Rendered the edit header info bar extras with ibexa_twig_component_group instead of the deprecated ibexa_render_component_group. The two read different registries: fieldtype-richtext-rte registers its presence list in content-form-edit-header-info-bar-extras with the ibexa.twig.component tag, which the old function never read, so it was not rendered.

For QA:

No functional change. Verified locally with a fresh composer update on PHP 8.3 and 8.4: test-unit and the gated test-integration exit 0 (8.4 also against PostgreSQL 10), PHPStan, deptrac and php-cs-fixer clean.

Documentation:

N/A

[Steveb-p]

Isn't this set up by Symfony recipe? If so, then we should just add it onto the test setup instead of prepending it.

[ViniTou]

Actually, I wanted to move it to our twig compoments, but i guess we can override it at recipe level as well, will check.

but it will prolly pop up on integration tests, so its needs to be added somewhere there as well.

[ViniTou]

As this is just to clean up our baseline from integration tests deprecations I had moved it into ibexa/test-core@d8e42da
on project level lets leave it to customers or original recipes. (I even think it is already there)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud