Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Renaming an image leaves the old URL in comments and term descriptions, with "Unknown column 'ID'" database errors

Aperta Adatta ai principianti
  • Qualcosa non va?
#1,199 3 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@girishpanchal30 ci sta già lavorando.

Dal 29/10/2026.

  • #1195 di @pirate-bot — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
74/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
mysql, php, wordpress
Ambito
database

Direzione di ricerca

Inizia da inc/media_rename/attachment_db_renamer.php: sql_handle_column() (intorno a L249-280) costruisce WHERE ID, mentre php_handle_column() (L364-375) costruisce già la clausola where da $primary_keys. Fai passare $primary_keys attraverso la funzione, incrementa $count solo quando $wpdb->update() ha successo e confronta la lista di esclusione con i nomi delle tabelle con prefisso. Il lavoro è completo quando rinominare un'immagine riscrive wp_comments.comment_content e wp_term_taxonomy.description senza errori Unknown column 'ID' in debug.log.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug
Description

When you rename an image with "Rename attached file", Optimole searches the database for the old URL and rewrites it. For columns with no serialized data it uses sql_handle_column(), which always runs the update as WHERE ID = <value>. Of the core single-site tables, only wp_posts and wp_users have an ID column. On the others the UPDATE fails with Unknown column 'ID' in 'where clause' and the row keeps the old URL. The old file has already been moved, so those images break.

Tables this affects on a normal site:

  • wp_comments (comment_content, comment_author_url), key comment_ID
  • wp_term_taxonomy.description (category, tag and product category descriptions), key term_taxonomy_id. $skip_tables lists term_taxonomy, but it is compared with prefixed names, so it never matches.
  • wp_termmeta, wp_commentmeta, wp_links, when none of that column's rows are serialized

On any real site, wp_postmeta, wp_options and wp_usermeta contain serialized rows (attachment metadata, roles, capabilities), so their value columns go to php_handle_column() instead and never reach this UPDATE.

replace() also counts these failed updates as replacements, because ++$count runs even when $wpdb->update() returns false.

Expected: every reference to the old file is rewritten, using each table's own primary key, and no database errors are logged.

Step-by-step reproduction instructions
  1. On a test site with Optimole 4.2.17 active (no Optimole account is needed for rename), add define( 'WP_DEBUG', true ); and define( 'WP_DEBUG_LOG', true ); to wp-config.php.
  2. Import an image and get its URL:
    ID=$(wp media import photo.jpg --porcelain); URL=$(wp eval "echo wp_get_original_image_url($ID);")
  3. Add three references to it:
    • wp post create --post_status=publish --post_title=Control --post_content="<img src=\"$URL\">"
    • wp term create category Gallery --description="<img src=\"$URL\">"
    • wp comment create --comment_post_ID=1 --comment_content="<img src=\"$URL\">"
  4. In wp-admin, go to Media > Library (list view), hover the image and click "Replace or Rename". Type renamed in "Rename attached file" and click Rename.
  5. Check the three references:
    • wp post list --title=Control --field=post_content shows renamed.jpg (correct).
    • wp term get category gallery --by=slug --field=description still shows photo.jpg.
    • wp comment list --fields=comment_ID,comment_content still shows photo.jpg.
  6. wp-content/debug.log has one error for each failed table, for example:
    WordPress database error Unknown column 'ID' in 'where clause' for query UPDATE `wp_comments` SET `comment_content` = '<img src=\"http://example.test/wp-content/uploads/2026/10/renamed.jpg\">...' WHERE `ID` = '7'

I have not run steps 1 to 6 on a live site. I ran the 4.2.17 Optml_Attachment_Db_Renamer class against WordPress core table definitions on MySQL 9.6. A minimal $wpdb built the UPDATE the same way wpdb::update() does. Output:

replace() returned: 4
WordPress database error Unknown column 'ID' in 'where clause' for query UPDATE `wp_comments` ... WHERE `ID` = '7'
WordPress database error Unknown column 'ID' in 'where clause' for query UPDATE `wp_term_taxonomy` ... WHERE `ID` = '3'
WordPress database error Unknown column 'ID' in 'where clause' for query UPDATE `wp_termmeta` ... WHERE `ID` = '1'
wp_posts.post_content          renamed
wp_comments.comment_content    STILL OLD URL
wp_term_taxonomy.description   STILL OLD URL
wp_termmeta.meta_value         STILL OLD URL
Screenshots, screen recording, code snippet or Help Scout ticket

Columns with no serialized rows are sent to sql_handle_column(), and the table's primary keys are not passed in, https://github.com/Codeinwp/optimole-wp/blob/v4.2.17/inc/media_rename/attachment_db_renamer.php#L177-L183

The ID is the value of the first field whose name contains "id" (comment_ID, term_taxonomy_id, meta_id...), but the WHERE column is always ID, https://github.com/Codeinwp/optimole-wp/blob/v4.2.17/inc/media_rename/attachment_db_renamer.php#L249-L280

$id_field = $row->ID ?? $row->id ?? null;
// ...falls back to the first field containing "id"
$wpdb->update(
	$table,
	[ $column => $new_content ],
	[ 'ID' => $id_field ]
);
++$count;

php_handle_column() already builds the WHERE clause from $primary_keys, https://github.com/Codeinwp/optimole-wp/blob/v4.2.17/inc/media_rename/attachment_db_renamer.php#L364-L375. Passing $primary_keys to sql_handle_column() and doing the same there would likely fix it. Only counting rows where update() succeeds would fix the count.

The skip list never matches because wpdb::tables() returns prefixed names, https://github.com/Codeinwp/optimole-wp/blob/v4.2.17/inc/media_rename/attachment_db_renamer.php#L20 and https://github.com/Codeinwp/optimole-wp/blob/v4.2.17/inc/media_rename/attachment_db_renamer.php#L67-L70 (core: https://github.com/WordPress/WordPress/blob/7.1.3/wp-includes/class-wpdb.php#L1159-L1166).

Core keys: comment_ID https://github.com/WordPress/WordPress/blob/7.1.3/wp-admin/includes/schema.php#L101-L117, term_taxonomy_id https://github.com/WordPress/WordPress/blob/7.1.3/wp-admin/includes/schema.php#L74-L81, meta_id https://github.com/WordPress/WordPress/blob/7.1.3/wp-admin/includes/schema.php#L56-L61. wpdb::update() writes the $where keys into the query as given, https://github.com/WordPress/WordPress/blob/7.1.3/wp-includes/class-wpdb.php#L2706-L2722, and logs the failure with error_log(), https://github.com/WordPress/WordPress/blob/7.1.3/wp-includes/class-wpdb.php#L1815-L1823.

Environment info
  • Optimole 4.2.17. This code is the same on master today and has not changed since 4.0.0.
  • WordPress 6.2 to 7.1 (the core table keys are the same in all of them), any MySQL or MariaDB version
  • PHP 7.4 and later
Is the issue you are reporting a regression

No. The same [ 'ID' => $id_field ] update was already in 4.0.0, when rename was added (#903).

Found while writing the WordPress compatibility checks for Optimole.

Lingua principale
PHP
Stelle
74
Fork
14
Merge medio
1g 23h
PR unite (30g)
31

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Codeinwp/optimole-wp

Tutte le issue di Codeinwp/optimole-wp

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.