PHP Warning: Undefined array key “height” / “width” caused in file media.php

Thank you for your reply moderator, but it’s not really helpful; let me explain…

The default WordPress mantra of “deactivating all plugins”, and then “reactivate the plugins one by one until you find the one causing the problem” is not helpful in this case; in this case it’s a PHP 8+ compatibility issue.

There are so many, so very many plugins for WordPress from all sorts of people around the world. Not all plugin developers have the necessary experience to develop their plugin for to operate correctly within a WordPress installation. And neither is it easy for plugin developers, because such software like WordPress or WooCommerce is being updated on a continual basis, and changes are applied to it.

People who run WordPress installations just can not spend so much time with error-catching of other people’s plugins. They may find themselves in a situation where such PHP warnings are logged in WordPress’ php_errorlog file, which then as a consequence is bloated in size in the course of time to who knows how many Megabytes, which then has a detrimental effect on the performance of a WordPress installation. Many such people will not know that the php_errorlog file is being loaded with every page-load –be it for them as administrator, or for their visitors– and they may find themselves in a situation where they are contacted by their hosting-provider about using up too much of server resources on the shared hosting-plan which they have. In such a situation they may not even be able to deactivate the php_errorlog file logging of WordPress, or change the PHP E_WARNING-level set up for the logging.

For inexperienced people it’s just such a difficult task to find out about the real cause of such a problem.

Now on the other hand –if you agree with my point– adding a little bit of PHP code from your side –for PHP 8+ compatibility sake– to check whether these array-keys have any value set before trying to access it, you could circumvent the deficiency of an unknown number of plugins worldwide which do not operate correctly within the WordPress instillation, and, as a secondary effect, benefit so many people around the world by avoiding these minor PHP issues being recorded as warnings or errors.

It’s so much less effort if you agreed to fix this in your code, than to expect that an unknown number of people worldwide –possibly many thousands– who are affected by this, spend their time and effort to find the cause for this unknown and indirect –you call it “secondary“– problem.

I reported this here on your forum, because, given the circumstances, it’s a common-sense approach if you fixed this in your code, and thereby helped so many other people who may also be affected by this.

This is a PHP 8+ compatibility issue, as you know. Such warnings were just not recorded by PHP in previous time, but now they are being recorded, and there can be many such warnings on a WordPress installation; these being triggered with every page-load !

I mention this for your consideration.

You can close this topic if you have nothing new to add to your initial reply.

Sincerely,
Gevorg

• This reply was modified 2 weeks, 1 day ago by Gevorg.

The WordPress installation where this (still) occurs has already been updated to WordPress 7.0. The code-sections I posted here in this topic are from WordPress version 7.0.

Due to other tasks I may not have the time to test this thoroughly by deactivating all, and then re-activating the plugins one after the other in order to see which one is causing this.

But to give your developers useful hints –if you choose to forward this to them– here is a list of active plugins on this particular WordPress installation, which are involved in manipulating or managing image files:

Enable Media Replace – version 4.1.9
https://en-au.ww.wp.xz.cn/plugins/enable-media-replace/

Media File Renamer: Rename for better SEO (AI-Powered) (Pro) – version 6.2.5
https://meowapps.com/

ShortPixel Image Optimizer – Optimize Images, Convert WebP & AVIF – version 2.4.9
https://en-au.ww.wp.xz.cn/plugins/shortpixel-image-optimiser/

WP Media folder – version 6.2.3
https://www.joomunited.com/wordpress-products/wp-media-folder

—

It’s not about what those code-sections cited here contain that would cause these warnings to be triggered –as you write– it’s about what they do not contain !

For example, if this:
if ( ! $src_matched && str_contains( $image_src, $dirname . $image['file'] ) ) {
$src_matched = true;
$is_src = true;
}

…would look like this:
if ( isset($image['file']) && ( ! $src_matched && str_contains( $image_src, $dirname . $image['file'] ) ) ) {
$src_matched = true;
$is_src = true;
}

…then such troublesome plugins would be deprived of their opportunity to trigger such PHP warnings. If you could implement such fixes in your own code, then you would preemptively solve very many such minor PHP issues in one strike.

You are welcome to forward this recommendation to your developers, or add it to already existing and active tickets.

Sincerely,
Gevorg

The title of this forum is called Fixing WordPress, and therefore I opened the topic concerning this issue; it is according to the purpose of this forum.

My remark “your developers“ is related to WordPress, not you moderator. But self-centered people just pick the wrong interpretation of the meaning.

Although this has already occupied quite some time to explain it here, I will try another attempt to clarify the matter for you: it is a logical problem, not a syntax problem.

WordPress is a good software, and it has gained much popularity because of how it has been developed. For simplicity sake, there are two different types of software that can be developed:

(1) One is software which is and remains under the control of the developer(s).

(2) The other is software which allows unknown third-parties to add extensions (plugins) to it, which consequently change how the software operates, and such software is no longer under control of its original developer(s).

WordPress is software from category (2).

Your developers (not you personally moderator) are experienced and talented programmers. And they have aimed at developing WordPress in an efficient way, according to the latest standards of PHP; and this is what all developers should aim to do.

However, they developed WordPress as if it is a category (1) software, they did not take into consideration that WordPress is a category (2) software.

It is impossible to know or preempt how these innumerable plugins worldwide may change the functioning of WordPress. And neither is it meaningful to expect that the manifold plugin developers worldwide are at the same level, or have the same insights as the WordPress developers.

Therefore it would be prudent if the WordPress developers realized and treated WordPress as a category (2) software, and as a consequence would implement precautionary measures –like the example I mentioned here in this topic– to mitigate potential inefficiencies of other people’s plugins.

You can neither correct other people’s plugin code, nor foresee what other blunders they may introduce in the future. But what you could do is to make your category (2) software compatible with PHP 8+ requirements.

If WordPress was a category (1) software, and there would be an instance where an array-key is being addressed which has no value set, then the developers can examine the code and simply prevent the addressing of that array-key when it has no value. And they can do this because as a category (1) software the entire functioning of the software is under their own control. And therefore they can streamline the programming, avoid unnecessary extras, and produce an efficient PHP code.

But with a category (2) software it does not work this way. So with WordPress –which is category (2)– you have a situation where innumerable outside developers have the opportunity to modify the functioning of this software, and not all are capable to integrate their plugin and its functioning correctly into WordPress. As a consequence modern PHP versions are triggered for error handling, and in the course of time this can have a detrimental effect on the performance of a WordPress installation.

The concept I am trying to describe here would improve WordPress’ performance by preemptively preventing such minor PHP issues, like warnings about array-keys without value, from occurring. And as a consequence this would positively affect many thousands –maybe millions– of WordPress installations worldwide.

This is what I am trying to explain here, and I think I have explained it clearly.

I will most likely not open a new ticket for this on WordPress Trac, neither participate in existing discussions. I will be satisfied if you (moderator) could draw the attention of relevant people, who are involved in developing WordPress, to take a look at this topic, and make their own considerations. It is about the concept of how they develop WordPress, it surely is not about a lack of programming skills. It’s about foreseeing and preemptively mitigating problems which other developers –who integrate their plugins into this category (2) software called WordPress– might cause. It’s not about how good WordPress on its own functions.

As I wrote before, I hope this can help to improve WordPress, on this forum which is called Fixing WordPress.

Sincerely,
Gevorg

• This reply was modified 1 week, 6 days ago by Gevorg.
• This reply was modified 1 week, 6 days ago by Gevorg.