Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#1,199 3 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@girishpanchal30 ya está trabajando en esto.

Desde el 29/10/2026.

  • #1209 de @girishpanchal30 — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
74/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
mysql, php, wordpress
Área
database

Línea de trabajo

Empieza en inc/media_rename/attachment_db_renamer.php: sql_handle_column() (alrededor de L249-280) construye WHERE ID, mientras que php_handle_column() (L364-375) ya construye la cláusula where a partir de $primary_keys. Pasa $primary_keys a través de la función, incrementa $count solo cuando $wpdb->update() tenga éxito y compara la lista de omisión con los nombres de tabla con prefijo. Se considera terminado cuando renombrar una imagen reescribe wp_comments.comment_content y wp_term_taxonomy.description sin errores Unknown column 'ID' en debug.log.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
PHP
Estrellas
74
Forks
14
Merge medio
1 d 21 h
PR fusionados (30 d)
30

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Codeinwp/optimole-wp

Todos los issues de Codeinwp/optimole-wp

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.