| @@ -169,9 +169,25 @@ | ||
| 169 | 169 | if (!static::hasIndex($indexName)) { |
| 170 | 170 | return; |
| 171 | 171 | } |
| 172 | 172 | |
| 173 | - Schema::dropIndex(static::$tableName, $indexName); | |
| 173 | + // Drop the index with a single direct ALTER rather than routing through | |
| 174 | + // Schema::dropIndex(), which calls WP core drop_index(). That core helper | |
| 175 | + // fires 25 speculative "DROP INDEX {name}_0".."_24" queries to clean up | |
| 176 | + // stray dbDelta-created duplicates; none of those variants exist for our | |
| 177 | + // explicitly-named indexes, so each one errors as "Can't DROP ..., check | |
| 178 | + // that column/key exists" and floods migration/test output with noise. | |
| 179 | + // hasIndex() above already confirmed the real index is present, so one | |
| 180 | + // ALTER is sufficient. The %i placeholder mirrors hasIndex() and keeps | |
| 181 | + // this safe on both MySQL and the WP SQLite integration. | |
| 182 | + $wpdb = Schema::db(); | |
| 183 | + $tableName = static::getTableName(); | |
| 184 | + // phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery, WordPress.DB.DirectDatabaseQuery.NoCaching, WordPress.DB.PreparedSQL.NotPrepared | |
| 185 | + $wpdb->query($wpdb->prepare( | |
| 186 | + "ALTER TABLE %i DROP INDEX %i", | |
| 187 | + $tableName, | |
| 188 | + $indexName | |
| 189 | + )); | |
| 174 | 190 | } |
| 175 | 191 | |
| 176 | 192 | public static function getTableName(bool $withPrefix = true): string |
| 177 | 193 | { |
