Title: Bug: Undefined array key
Last modified: October 4, 2026

---

# Bug: Undefined array key

 *  [Divemaster](https://wordpress.org/support/users/mszaitsev/)
 * (@mszaitsev)
 * [6 days, 9 hours ago](https://wordpress.org/support/topic/bug-undefined-array-key/)
 * Bug: `Undefined array key` in `Media_Item_Query::attachment_urls_to_ids()` with
   case-insensitive `_wp_attached_file` collisionsEnvironment
    - Smush: 4.3.4
    - WordPress: 7.1.2
    - WooCommerce: 11.1.2
    - PHP: 8.4
    - Database `wp_postmeta.meta_value` collation: `utf8mb4_unicode_ci`
 * Problem
 * `Smush\Core\Media\Media_Item_Query::attachment_urls_to_ids()` can produce PHP`
   Undefined array key` warnings when two WordPress attachments have `_wp_attached_file`
   values that differ only by letter case.
 * For example, assume the database contains two valid attachment records:
 *     ```wp-block-code
       2024/11/Picture123.jpg
       2024/11/picture123.jpg
       ```
   
 * Both attachments may be valid, with separate attachment IDs, metadata and physical
   files.
 * If Smush attempts to resolve:
 *     ```wp-block-code
       https://example.com/wp-content/uploads/2024/11/picture123.jpg
       ```
   
 * `attachment_urls_to_ids()` creates a PHP lookup array using the relative URL 
   as a key:
 *     ```wp-block-code
       $relative_key_absolute_value[ $relative_url ] = $absolute_url;
       ```
   
 * Therefore the array contains:
 *     ```wp-block-code
       2024/11/picture123.jpg
       ```
   
 * but not:
 *     ```wp-block-code
       2024/11/Picture123.jpg
       ```
   
 * Later, Smush queries `wp_postmeta` using:
 *     ```wp-block-code
       $sql = "SELECT post_id, meta_value
               FROM $wpdb->postmeta
               WHERE meta_key = '_wp_attached_file'
               AND meta_value IN ({$in})";
       ```
   
 * On a standard case-insensitive WordPress database collation such as `utf8mb4_unicode_ci`,
   the comparison is case-insensitive.
 * Consequently, a query for:
 *     ```wp-block-code
       2024/11/picture123.jpg
       ```
   
 * can return both records:
 *     ```wp-block-code
       2024/11/Picture123.jpg
       2024/11/picture123.jpg
       ```
   
 * Smush then assumes every `meta_value` returned by SQL exists as an exact PHP 
   array key:
 *     ```wp-block-code
       foreach ( $results as $result ) {
           $meta_value            = $result['meta_value'];
           $original_absolute_url = $relative_key_absolute_value[ $meta_value ];
   
           $ids[ $original_absolute_url ] = $result['post_id'];
       }
       ```
   
 * PHP array keys are case-sensitive, unlike the SQL comparison above.
 * Therefore, when `$meta_value` is:
 *     ```wp-block-code
       2024/11/Picture123.jpg
       ```
   
 * but the array contains only:
 *     ```wp-block-code
       2024/11/picture123.jpg
       ```
   
 * PHP generates:
 *     ```wp-block-code
       PHP Warning: Undefined array key "2024/11/Picture123.jpg"
       ```
   
 * Reproduction
 * Create two image attachments whose `_wp_attached_file` values differ only by 
   case:
 *     ```wp-block-code
       2024/11/Picture123.jpg
       2024/11/picture123.jpg
       ```
   
 * Verify that the database column uses a case-insensitive collation such as:
 *     ```wp-block-code
       utf8mb4_unicode_ci
       ```
   
 * Then execute the equivalent lookup:
 *     ```wp-block-code
       SELECT post_id, meta_value
       FROM wp_postmeta
       WHERE meta_key = '_wp_attached_file'
       AND meta_value IN ('2024/11/picture123.jpg');
       ```
   
 * Both attachment rows can be returned.
 * The same behavior can be demonstrated through WordPress `$wpdb`: the returned`
   meta_value` may not be byte-for-byte identical to the string supplied in the `
   IN()` clause.
 * When this happens during `Media_Item_Query::attachment_urls_to_ids()`, the subsequent
   PHP array lookup generates the warning.Expected behavior
 * `attachment_urls_to_ids()` should not assume that every `meta_value` returned
   by a case-insensitive SQL comparison is an exact key in `$relative_key_absolute_value`.
 * Attachment URL resolution should preserve exact filename/path matching, including
   case.Actual behavior
 * A case-insensitive SQL match can return additional attachment rows whose `_wp_attached_file`
   differs only by case.
 * Those values are subsequently used as case-sensitive PHP array keys without checking
   that the key exists, resulting in `Undefined array key` warnings and potentially
   ambiguous attachment URL-to-ID resolution.Scope
 * This does not require corrupt WordPress attachment metadata or missing files.
 * The issue is reproducible with two otherwise valid attachments whose filenames
   differ only by case.
 * It is also not specific to non-ASCII filenames. For example:
 *     ```wp-block-code
       Picture123.jpg
       picture123.jpg
       ```
   
 * is sufficient to reproduce the underlying SQL/PHP comparison mismatch.Possible
   fix
 * The SQL lookup should ideally use exact/binary matching so that its matching 
   semantics agree with the PHP lookup.
 * Alternatively, at minimum, the result should be validated before accessing the
   lookup array:
 *     ```wp-block-code
       $meta_value = $result['meta_value'];
   
       if ( ! isset( $relative_key_absolute_value[ $meta_value ] ) ) {
           continue;
       }
   
       $original_absolute_url = $relative_key_absolute_value[ $meta_value ];
       ```
   
 * However, simply suppressing the warning would not completely address the underlying
   ambiguity. An exact/case-sensitive attachment-path lookup would appear to be 
   the more robust solution.Additional note
 * This code path can be reached during normal frontend page processing through `
   Attachment_Url_Cache_Controller`, which collects image URLs from page elements
   and calls:
 *     ```wp-block-code
       $this->media_item_query->attachment_urls_to_ids( $this->bulk_image_urls );
       ```
   
 * Therefore the warning can occur during ordinary frontend requests without manually
   running Bulk Smush or another media optimization operation.

Viewing 1 replies (of 1 total)

 *  Plugin Support [Amin – WPMU DEV Support](https://wordpress.org/support/users/wpmudev-support2/)
 * (@wpmudev-support2)
 * [6 days ago](https://wordpress.org/support/topic/bug-undefined-array-key/#post-19036170)
 * Hello [@mszaitsev](https://wordpress.org/support/users/mszaitsev/)
 * Hope you’re doing well today.
 * Thank you for sharing the detailed information about the issue. Our development
   team, already aware of this issue and is working on improving it, this shouldn’t
   cause critical errors but some warnings will be generated.
 * I’m afraid I can’t give any ETAs for the fix but it should be fixed in future
   updates.
 * Best Regards
    Amin

Viewing 1 replies (of 1 total)

You must be [logged in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Fbug-undefined-array-key%2F%3Foutput_format%3Dmd&locale=en_US)
to reply to this topic.

 * ![](https://ps.w.org/wp-smushit/assets/icon-256x256.gif?rev=3447113)
 * [Smush – Image Optimization, Compression, Lazy Load, WebP & CDN](https://wordpress.org/plugins/wp-smushit/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/wp-smushit/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/wp-smushit/)
 * [Active Topics](https://wordpress.org/support/plugin/wp-smushit/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/wp-smushit/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/wp-smushit/reviews/)

 * 1 reply
 * 2 participants
 * Last reply from: [Amin – WPMU DEV Support](https://wordpress.org/support/users/wpmudev-support2/)
 * Last activity: [6 days ago](https://wordpress.org/support/topic/bug-undefined-array-key/#post-19036170)
 * Status: not resolved