dqj

Thanks!

Ah, I figured it out. I was missing the last two arguments to the add_filter(). One looks like priority and the other I’m not sure. I’ll have to do some more reading on WordPress filters.

Thank you. I figured it out. When I copied the code from the article it worked, whereas the file content did not. In any case, I have it up and running.

Cheers,
-dqj

Actually, for just the WordPress core, I think it might be simply this:

/** ALTER TABLE wp_posts ADD CONSTRAINT FOREIGN KEY (post_parent) REFERENCES wp_posts(ID) ON DELETE CASCADE; **/
ALTER TABLE wp_posts ADD CONSTRAINT FOREIGN KEY (post_author) REFERENCES wp_users(ID) ON DELETE CASCADE;
ALTER TABLE wp_postmeta ADD CONSTRAINT FOREIGN KEY (post_id) REFERENCES wp_posts(ID) ON DELETE CASCADE;
ALTER TABLE wp_usermeta ADD CONSTRAINT FOREIGN KEY (user_id) REFERENCES wp_users(ID) ON DELETE CASCADE;
ALTER TABLE wp_term_taxonomy ADD CONSTRAINT FOREIGN KEY (term_id) REFERENCES wp_terms(term_id) ON DELETE CASCADE;
ALTER TABLE wp_term_relationships ADD CONSTRAINT FOREIGN KEY (term_taxonomy_id) REFERENCES wp_term_taxonomy(term_taxonomy_id) ON DELETE CASCADE;

The first one is commented out because post_parent column is marked as NOT NULL, with a DEFAULT of 0, rather than null. I’m not sure if any code depends on that zero value.

I’m using dozens of plugins, including BuddyPress. Maybe it can become a WordPress “good practice” to include an option for adding integrity constraints to your plugin, an option when you install, if InnoDB is currently being used?

Thanks very much for your informative response! It sort of answers another question I’ve had, too, which is why WordPress was so tightly tied to one particular database implementation.

If I can create a script that upgrades the database with constraints, I’ll post it somewhere in case there is interest. I guess I’d probably use “on cascade delete” qualifications also, to make sure that deletes aren’t broken in software that assumes no keys.

Cheers.