Make it easier to customize the install process

[Denis-de-Bernardy]

It's currently possible to override a couple of functions in a wp-content/install.php file, namely:

• wp_install() - top level install function
• wp_install_defaults() - Installs default post, page, links, cat, etc.
• wp_new_blog_notification() - Sends the new blog email.
• wp_upgrade() - Top level upgrade function.

However, they severely lack plugin hooks, which would allow developers to simply hack in there accordingly without needing to keep install functions in sync with core when they want to tweak them.

I'd like to suggest adding hooks named after those functions at the end of each of them.

[DrewAPicture]

+1 for adding these hooks.

[Denis-de-Bernardy]

Adding this back link for reference, since the question originating from there:

​http://wordpress.stackexchange.com/a/120539/1208

[nacin]

Would definitely like more hooks here.

[Denis-de-Bernardy]

Replying to nacin:

Would definitely like more hooks here.

Will a patch make it into the next WP version if supplied, or does it need a crazy amount of discussion before getting checked in?

[nacin]

Replying to Denis-de-Bernardy:

Will a patch make it into the next WP version if supplied, or does it need a crazy amount of discussion before getting checked in?

The original suggestion seem straightforward enough to me:

I'd like to suggest adding hooks named after those functions at the end of each of them.

I wouldn't be surprised if there are additional opportunities for well-placed actions or filters, but one per function would certainly be a good start. Would be happy to check in a patch this week.

[Denis-de-Bernardy]

Replying to nacin:

I wouldn't be surprised if there are additional opportunities for well-placed actions or filters, but one per function would certainly be a good start. Would be happy to check in a patch this week.

I stuck to two hooks, seeing that those two would have been more than enough for use-cases that I've run into over the years:

• one at the very end of wp_install, that passes user_id
• another at the very end of wp_upgrade, that passes the new and old database version

The second patch should be svn-compatible (generated using git diff --noprefix).

[DrewAPicture]

We'll need docs for these hooks, wherever they land per the ​Inline Docs standards.

[nacin]

This looks great. Some little things:

• These are actual doc blocks, they need /**
• 3.9.0 versus 3.9

Also, you put the wp_upgrade hook in upgrade_all(), not wp_upgrade(). Intentional? Looks like wp_upgrade() is indeed the right place for it, as your comment above suggested.

[nacin]

Pass $user instead of $user_id since we have it.

[Denis-de-Bernardy]

Replying to nacin:

This looks great. Some little things:

• These are actual doc blocks, they need /**
• 3.9.0 versus 3.9

Looks like you did that in your amended patch.

Also, you put the wp_upgrade hook in upgrade_all(), not wp_upgrade(). Intentional? Looks like wp_upgrade() is indeed the right place for it, as your comment above suggested.

It was in the wrong function, ya. *tired*… I see you fixed that too.

[nacin]

Replying to Denis-de-Bernardy:

It was in the wrong function, ya. *tired*… I see you fixed that too.

All good, just wanted to double-check!

[nacin]

In 27045:

Add wp_install and wp_upgrade hooks to the respective functions.

props Denis-de-Bernardy.
fixes #25762.

[Denis-de-Bernardy]

The wp_install hook never gets called in a multisite environment. Placing it in wp_install_defaults was in fact correct.

[Denis-de-Bernardy]

fix space vs tab

[Denis-de-Bernardy]

add wp_install_defaults hook, and switch to user_id for wp_install for consistency

[Denis-de-Bernardy]

Marked #11210 as related.

[Denis-de-Bernardy]

Fix #11210 as well

[Denis-de-Bernardy]

Same as the previous one, s/4space/tab/

[Denis-de-Bernardy]

Per IRC discussions

[nacin]

I'm closing this as fixed based on the [27045]. I think the additional proposals are significantly less straightforward and need a new ticket.