PHP 8.4 deprecations from AC Pro during frontend-facing admin-ajax requests
Hello there!
Please let me report the following bug:
Plugin: Admin Columns Pro
Plugin slug: admin-columns-pro
Affected version observed: 7.0.11
Environment observed: WordPress 6.9.1, WooCommerce 10.5.3, PHP 8.4.18
Summary
On PHP 8.4, Admin Columns Pro emits repeated deprecations from its bundled php-di vendor tree.
The important part is the request context:
– this was not only seen in wp-admin page loads
– it was also observed during frontend-facing AJAX traffic hitting wp-admin/admin-ajax.php
– in the observed store, those requests were part of multilingual WooCommerce checkout flows
This suggests that the plugin is being initialized broadly enough to affect frontend-adjacent AJAX requests where its functionality is not needed.
Why this matters
In the observed production log, Admin Columns Pro accounted for 260272 entries, making it one of the largest operational noise sources in the stack.
That has two concrete effects:
1. debug.log becomes harder to use for real incident analysis.
2. PHP 8.4 compatibility issues from a backend-oriented plugin leak into high-churn frontend-adjacent request paths.
Reproduction
1. Run WordPress on PHP 8.4.
2. Enable WP_DEBUG and WP_DEBUG_LOG.
3. Use Admin Columns Pro 7.0.11.
4. Trigger frontend flows that perform AJAX requests through wp-admin/admin-ajax.php.
5. Inspect debug.log.
In the observed production environment, fresh log bursts correlated with multilingual checkout-related requests around:
– POST /wp-admin/admin-ajax.php
– POST /?wc-ajax=update_order_review
– POST /wp-content/plugins/translatepress-multilingual/includes/trp-ajax.php
Actual result
PHP logs repeated deprecations from the bundled php-di code, for example:
AC\Vendor\DI\Container::__construct(): Implicitly marking parameter $proxyFactory as nullable is deprecated
AC\Vendor\DI\Definition\ObjectDefinition::__construct(): Implicitly marking parameter $className as nullable is deprecated
AC\Vendor\DI\Definition\Resolver\ParameterResolver::resolveParameters(): Implicitly marking parameter $definition as nullable is deprecatedExpected result
Admin Columns Pro should be PHP 8.4 clean, and ideally should not fully initialize in frontend-facing AJAX contexts where its functionality is not required.
Affected code paths observed
Examples from:
admin-columns/vendor/php-di/php-di/src/functions.php
admin-columns/vendor/php-di/php-di/src/Container.php
admin-columns/vendor/php-di/php-di/src/Definition/ObjectDefinition.php
admin-columns/vendor/php-di/php-di/src/Definition/Resolver/ParameterResolver.phpTechnical notes
– No plugin-specific scheduled cron hooks were found for Admin Columns Pro, so this does not currently look like a cron-only issue.
– The strongest correlation was with frontend-adjacent AJAX traffic, not with normal wp-admin use alone.
– This points either to:
– a bundled dependency compatibility gap for PHP 8.4
– or overly broad plugin bootstrap in requests that do not need Admin Columns functionality
Suggested direction
Two improvements would likely resolve the operational issue:
1. Update or patch the bundled php-di dependency for PHP 8.4 compatibility.
2. Revisit bootstrap conditions so the plugin does not initialize unnecessarily on unrelated frontend AJAX requests.
Notes
– This was observed on a real production WooCommerce site with multilingual checkout traffic.
– No claim is made that Admin Columns Pro directly breaks checkout behavior; the current issue is repeated PHP 8.4 deprecation noise and unnecessary execution scope.
Hi Saskia, thanks for your message. This is related to the issue reported here. We can not fix this until we set the minimum requirement to PHP 8.
Hello Tobias,
Thanks for your message. I fixed it on my end in the meantime.
One question: what is keeping you from elevating to min php 8? WordPress’s official recommended min php version is 8.3., isn’t it?
Thanks
Saskia
WordPress itself currently still supports PHP 7.2.24 as the minimum. Because of that most major plugins (including ours) tend to keep compatibility with slightly older versions too. At the moment, many widely used plugins (such as WooCommerce, ACF, Yoast SEO) still target PHP 7.4 as their minimum. The main reason is that a portion of WordPress sites are still running on these older PHP versions (for us it is around 5-10%) and raising the minimum would mean those users can no longer update the plugin.
We are currently looking into an alternative solution, where we might fork the DI dependency and fix the deprecated warnings ourselves. We will place an update on the forums when we have news on this.
Hej Tobias,
thanks for the clarification.
I think there may be a small mismatch between the release policy and the technical limitation here.
The PHP 8.4 deprecations we are seeing come from the bundled php-di code, for example signatures like:
– MutableDefinitionSource $definitionSource = null
– ProxyFactory $proxyFactory = null
– string $className = null
– MethodInjection $definition = null
These can be fixed with explicit nullable types, e.g. ?MutableDefinitionSource, ?ProxyFactory, ?string, ?MethodInjection.
As far as I can see, the bundled php-di package in your plugin already requires PHP >= 7.4, so this specific compatibility fix would still be backward compatible with your current supported range. In other words, this looks technically fixable before raising the minimum requirement to PHP 8.
So I understand if you prefer to handle it only in a future major release, but it does not seem to be blocked by PHP language compatibility itself.
Also, in our case these deprecations are not limited to wp-admin usage. We are seeing them during frontend-adjacent admin-ajax / checkout-related request flows as well, which makes the operational impact more noticeable on PHP 8.4.
If helpful, I can also provide a reduced list of the affected signatures from the bundled php-di classes.
Best,
Saskia
We already know how this issue could be resolved in the code, but unfortunately we cannot apply the fix ourselves. This is because we are not the maintainers of the PHP-DI repository. We include it as a dependency in our plugin and scope it to our AC namespace to prevent conflicts, but the issue originates from that package itself.
We are looking into forking this repository and make their PHP 7.4 release compatible with PHP 8.x. That is an option we are considering at the moment as more and more of our users are moving towards PHP 8.4.
Die PHP 8.4 Deprecations sind bereits in PHP-DI 7.0.7+ gefixt (PR #889). Diese Versionen laufen weiterhin mit PHP 7.4+.
Aktuell vendort ACP 7.0.11 noch PHP-DI 6.4.0. Ein Dependency-Update würde das Problem lösen, ohne dass das PHP-Minimum angehoben werden müsste.
Grüße
Saskia
We include this dependency through composer. In their 7.0.7 release, their own composer.json specifies PHP 8.0 as the minimum required version. If this version is actually compatible with PHP 7.4, then it should at least be reflected in their own composer requirements, which currently is not the case.
I looked into PHP-DI v7.0.7, but I don’t see how this version would be compatible with PHP 7.4. For example, they use union types, which were introduced in PHP 8.0 and will cause a fatal parse error on PHP 7.4.
I am not sure where you saw that the minimum requirement is PHP 7.4, but that information appears to be incorrect. Unfortunately, this means we cannot use this version.
Hi Tobias,
thanks for the clarification on 7.0.7. You’re right about the PHP 8.0 requirement there. (tomatoes on my eyes, sorry)
I backported the signature fixes to the vendored 6.4.0 for my client’s deployment. Works for me, sharing in case it’s useful: https://cloud.wp-studio.dev/s/wPcXmXjZDGjMwjJ
No further action needed from your side.
Best
Saskia
Thanks for supplying the patch and helping us with this. I like the patch approach. I have added it to our build process so it will be applied automatically before the PHP-DI dependency is bundled into our release. With this fix in the PHP-DI code we should have resolved all PHP 8.4 deprecation notices.
This means the next release (v7.0.12) should be free from these warnings. We will run some additional tests, but it looks promising.
Awesome, thank you!
Have a great day!
You must be logged in to reply to this topic.