woodsbw

I’m aware of that…but, if only the front-end is displayed, then only read access (for example) should be needed for wp_posts…the front-end should never need write access to a post.

From what I can tell, the only thing that the front-end would write to is wp_comments and wp_commentmeta (as well as read access to all the other tables), but I don’t know enough about WP internals to know if there is something else that the public facing side of WordPress needs write access to.

I’m not sure if I was clear enough about my setup, so let me try and clarify a bit. I have two separate WordPress installs, but both connect to the same MySQL database, but with different DB users. Some notes on each install:

Install One:
– Accessible to public Internet.
– Has HTTP access to the /wp-admin folder and /wp-login.php file denied in the Apache config (as well as quite a few other security pieces in place, but none of those are relevant to this problem)
– Cannot (and should not) be used to preform ANY administrative tasks (administrating users, adding/removing posts, moderating comments, etc.)

Install Two:
– Accessible only from my internal network
– /wp-admin and /wp-login.php are fully accessible
– Separate install, but connects to the same DB as “Install One”
– All administrative tasks should be done though this install

I hope that clarifies things a bit. The whole issue I have is that I don’t WANT “Install One” to be able to add users, plugins, etc. All that should be done from “Install Two.”

So, I assume “Install One” should be able to run with read-only access to most DB tables. “Install Two” will be left with full (GRANT ALL) privileges to all DB tables.

I ran that, but then when I ran update, I got this:

Fatal error: Call to undefined function add_action() in C:\Web Sites\testSite\wordpress\wp-includes\update.php on line 72