[wp-trac] [WordPress Trac] #40364: Improve site creation in multisite

[WordPress Trac]

#40364: Improve site creation in multisite
-------------------------------------------------+------------------------
 Reporter:  jeremyfelt                           |       Owner:  flixos90
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  5.0
Component:  Networks and Sites                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  ms-roadmap has-patch has-unit-tests  |     Focuses:  multisite
-------------------------------------------------+------------------------

Comment (by spacedmonkey):

 > Technically, it doesn't make sense for this to be a filter since objects
 (i.e. `$validity`) are passed by reference in PHP. If though, the general
 opinion is that this should be a filter for how WordPress developers are
 used to do it, I'm not entirely opposed to changing it. I'd like to have a
 third opinion here.

 I am telling you, that as a developer, I was confused seeing it was action
 and not a filter. Even if you can change a value in action, it being an
 action not a filter sends a message that maybe you shouldn't change it. I
 don't see why it should be an action, it is not an action, it a variable
 that is designed to be change, that is a filter in my mind.

 > That `wp_insert_post()` and `wp_update_post()` behave like this is very
 unexpected as it is not explicit at all. Because these here are new APIs
 for which we try to make things better, I vote for not doing this solely
 for the sake of compatibility with those two functions (especially since
 not all WordPress object CRUD functions behave like the latter either).

 So both  `wp_insert_post()` and  `wp_insert_user()` do this. Honestly it
 is a pattern that I don't love. As I said before, it set the `blog_id` on
 `wp_insert_site`, it should error out otherwise, it might have unexpected
 consequences.

 Looking again at the patch `wp_validate_site_data` should have some
 validation for `registered` and `last_updated` to make sure they are in
 the right date format. The following code can be found in `wp_insert_post`
 and something similar can be used.

 {{{#!php
         // Validate the date.
         $mm         = substr( $post_date, 5, 2 );
         $jj         = substr( $post_date, 8, 2 );
         $aa         = substr( $post_date, 0, 4 );
         $valid_date = wp_checkdate( $mm, $jj, $aa, $post_date );
         if ( ! $valid_date ) {
                 if ( $wp_error ) {
                         return new WP_Error( 'invalid_date', __( 'Invalid
 date.' ) );
                 } else {
                         return 0;
                 }
         }

 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/40364#comment:52>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform