Skip database views during search-replace

[Copilot]

Database views cannot be directly modified and may trigger ERROR 1449 (definer user doesn't exist) when accessed on a different server. The search-replace command should skip them rather than attempting replacements.

Changes

• View detection — after resolving the table list, makes a second wp_get_table_names() call with views-only: true (using the same scope flags) to identify views in the working set
• Loop skip — views encountered during iteration are skipped; a skipped (view) entry is added to the report unless --report-changed-only is active
• Applies to all modes — skip happens before both the regular replacement path and the export path

Example output

+------------------+--------+------------------+------+
| Table            | Column | Replacements     | Type |
+------------------+--------+------------------+------+
| wp_options       | ...    | 3                | PHP  |
| wp_posts_view    |        | skipped (view)   |      |
+------------------+--------+------------------+------+

• Test — adds a Behat scenario that creates a view and asserts it appears as skipped (view) under both --all-tables-with-prefix and --all-tables

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Problems with Views - "ERROR 1449 ... The user specified as a definer ('xxx'@'xxx') does not exist"</issue_title>
<issue_description>This is a suggest / query / pre-PR question.

I am pulling a db from serverA to serverB and running a search-replace on it. It is failing because the dB contains a view. The view references the serverA MySQL user which doesn't exist on serverB.

(presuming I'm not missing something / haven't messed something up in my setup...)

I don't know of any reason to run a search-replace on a View as they are dynamic by nature. Would a PR to skip them be accepted? Is there any reason Views should be included?

These would work on MySQL/MariaDB (but haven't been extensively tested):

SHOW TABLE STATUS
# WHERE `comment` != 'VIEW'
WHERE `Rows` IS NOT NULL

It would mean modifying wp_get_table_names() in wp-cli/php/utils-wp.php fairly extensively, unless there's an easier way to identify Views.

I think this is going to get more widely applicable if the use of a View in core goes ahead (wasn't there talk of a View for taxonomy data?)

While I'm obviously talking about modifying a function in core wp-cli I thought I'd post this hear first as the most obvious (to me) place that it would affect and use case for the change.
</issue_description>

<agent_instructions>Part 1 was addressed in wp-cli/wp-cli#5128 so now we need to implement the rest in this command</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@schlessera I think it makes sense to be able to skip views for certain commands. However, the default behavior for `wp_get_table_names()` should be to include them, as they are meant to be transparent to the end user.

I suggest the following changes (in 2 separate PRs with corresponding tests for each):

• Add additional flags --base-tables-only and --views-only to wp_get_table_names() (through its second $assoc_args argument). Without these, the default result will return both regular tables and views.

• In the search-replace command, make a second query with --views-only and check this array to skip while looping over the table. The report can then still show all found tables/views but views will show something like skipped view as the reason for not processing. This will avoid user confusion when they see a table in the list but the search-replace does not show it being processed.

Do you think this makes sense?</comment_new>

• Fixes Problems with Views - "ERROR 1449 ... The user specified as a definer ('xxx'@'xxx') does not exist" #109

---

📱 Kick off Copilot coding agent tasks wherever you are with GitHub Mobile, available on iOS and Android.