GRANT USAGE vs ALL

GRANT USAGE lets a MySQL user connect to the server. GRANT ALL gives that user every privilege on the objects you name, which is far more power than most apps need. For WordPress on shared hosting, you want a middle path: create the user, grant only the privileges the site needs on one schema, verify with SHOW GRANTS, then put those credentials in wp-config.php.

Create the user, grant privileges, then verify

1. Create the user in cPanel → MySQL Databases, with host localhost unless you truly need remote access.
2. Attach that user to one database and grant SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, and INDEX. Do not GRANT ALL ON *.*.
3. Run SHOW GRANTS FOR the user WordPress will use. Look for FILE, GRANT OPTION, SUPER, or a leftover % host.
4. Only then copy the password into wp-config.php and remove any root or shared account the app used during setup.

A string like GRANT ALL ON *.* TO wp@'%' IDENTIFIED BY 'password' stacks several mistakes at once: ALL privileges, every schema, any host, and a password that will leak. USAGE alone is also wrong, because the app can connect and then fail every query. You want schema-scoped rights in the middle.

What WordPress needs on install and later

The installer creates tables, so CREATE and ALTER are required at setup. Some people REVOKE those after install. Then a plugin update that adds a table fails, and you get a ticket that WordPress cannot write. Leave CREATE, ALTER, INDEX, and DROP on that one schema. You are not making the app safer by forcing every schema change through root; you are making updates fail. Keep SUPER, FILE, PROCESS, and GRANT OPTION off.

Users you create in cPanel MySQL Databases already look like this. The usual mess is a user someone made in the mysql client during a migration, with ALL PRIVILEGES and a host of %. SHOW GRANTS is how you find it. Rotate the password in the same sitting so old wp-config.php copies stop working.

Cleaning up extra access

REVOKE is the inverse of GRANT, and it is how you remove a contractor login without dropping the app user. Think of USAGE last in the mental model: if they cannot connect, nothing else matters, but an app user who can only connect is a broken site. local_infile is a separate door; even ALL does not require it. See local_infile, probably off.