Making WordPress.org


Ignore:
Timestamp:
06/03/2019 02:36:46 PM (5 years ago)
Author:
vedjain
Message:

WC: Refactor participant notifier to fix design flaw. See 703. See desc.

We currently assume that a profile will be associated with only single WordCamp, and handle adding and removing badges (speaker/organizer) with this assumption.
However, this assumption is incorrect and causes badge disappearing bug, as described in 703.

This patch refactors the participant-notifier class such that:

  1. Whenever a badge is added, an entry is made in to usermeta table, with meta key as wc_{post_type}_{blog_id}_{post_id]. This has following benefits:
    1. Usermeta table is shared across all WordCamp, so this can act as a central place to record whenever a badge is added for a user.
    2. Since meta key columns is indexed, a count query can be done on wc_{post_type}_% with user_id = {user_id} clause.

Because of how MySQL stores indexes, prefix queries are also as performant as full text queries. This gives us ability to find out in how many WordCamp a user is registered as a speaker/organizer using a single performant query.
We can use the results of this query to decide if we want to remove a badge or not.

  1. In block editor, as per https://github.com/WordPress/gutenberg/issues/12897, POST data will not be there when publishing a draft post. This patch adds a workaround by checking if we need to add/remove badge even if both previous and next status are publish.
  2. Uses a meta data to prevent duplicate activity log request. This is necessary because of workaround described in above patch.

Fixes 703

File:
1 edited

Legend:

Unmodified
Added
Removed
  • sites/trunk/wordcamp.org/public_html/wp-content/plugins/wordcamp-participation-notifier/wordcamp-participation-notifier.php

    r8906 r8907  
    113113     * or organizer post changes.
    114114     *
     115     * IMPORTANT NOTE: If a draft post is published via block editor, we will have to add badges and activity here instead of `post_published_or_unpublished` method.
     116     * This is because when post is updated via Block editor, the status change request will not have any POST data, see @link https://github.com/WordPress/gutenberg/issues/12897
     117     *
    115118     * @todo The handler doesn't support removing activity, but maybe do that here if support is added.
    116119     *
     
    118121     */
    119122    protected function published_post_updated( $post ) {
    120         $previous_user_id = $this->get_saved_wporg_user_id( $post );
    121         $new_user_id      = $this->get_new_wporg_user_id( $post );
    122 
    123         // There is no username, or it hasn't changed, so we don't need to do anything here.
    124         if ( $previous_user_id === $new_user_id ) {
    125             return;
    126         }
    127 
    128         // todo change this to use an if/elseif/elseif structure, just to be safe
    129 
    130         // A new username was added, so add the activity and association.
    131         if ( $new_user_id && ! $previous_user_id ) {
    132             $this->remote_post( self::PROFILES_HANDLER_URL, $this->get_post_activity_payload( $post ) );
    133             $this->remote_post( self::PROFILES_HANDLER_URL, $this->get_post_association_payload( $post, 'add' ) );
    134         }
    135 
    136         // The username was removed, so remove the association.
    137         if ( ! $new_user_id && $previous_user_id ) {
    138             $this->remote_post( self::PROFILES_HANDLER_URL, $this->get_post_association_payload( $post, 'remove', $previous_user_id ) );
    139         }
    140 
    141         // The username changed, so remove the association from the previous user and add both the activity and association to the new user.
    142         if ( $new_user_id && $previous_user_id ) {
    143             $this->remote_post( self::PROFILES_HANDLER_URL, $this->get_post_association_payload( $post, 'remove', $previous_user_id ) );
    144             $this->remote_post( self::PROFILES_HANDLER_URL, $this->get_post_activity_payload( $post ) );
    145             $this->remote_post( self::PROFILES_HANDLER_URL, $this->get_post_association_payload( $post, 'add' ) );
     123        $previous_user_id       = $this->get_saved_wporg_user_id( $post );
     124        $new_user_id            = $this->get_new_wporg_user_id( $post );
     125        $published_activity_key = $this->get_published_activity_key( $post );
     126
     127
     128        if ( $previous_user_id ) {
     129            $this->maybe_remove_badge( $post, $previous_user_id );
     130        }
     131
     132        if ( $new_user_id ) {
     133
     134            if ( ! get_user_meta( $new_user_id, $published_activity_key ) ) {
     135                $this->remote_post( self::PROFILES_HANDLER_URL, $this->get_post_activity_payload( $post ) );
     136                update_user_meta( $new_user_id, $published_activity_key, true );
     137            }
     138
     139            $this->add_badge( $post, $new_user_id );
    146140        }
    147141    }
     
    159153    protected function post_published_or_unpublished( $new_status, $old_status, $post ) {
    160154        if ( 'publish' == $new_status ) {
    161             $this->remote_post( self::PROFILES_HANDLER_URL, $this->get_post_activity_payload( $post ) );
    162             $this->remote_post( self::PROFILES_HANDLER_URL, $this->get_post_association_payload( $post, 'add' ) );
     155            $user_id = $this->get_new_wporg_user_id( $post );
     156
     157            if ( ! get_user_meta( $user_id, $this->get_published_activity_key( $post ) ) ) {
     158                $this->remote_post( self::PROFILES_HANDLER_URL, $this->get_post_activity_payload( $post ) );
     159                update_user_meta( $user_id, $this->get_published_activity_key( $post ), true );
     160            }
     161
     162            $this->add_badge( $post, $user_id );
    163163        } elseif( 'publish' == $old_status ) {
    164             // Get the $user_id from post meta instead of $_POST in case it changed during the unpublish update.
    165             // This makes sure that the association is removed from the same user that it was originally added to.
    166 
    167164            $user_id = $this->get_saved_wporg_user_id( $post );
     165            $this->maybe_remove_badge( $post, $user_id );
     166        }
     167    }
     168
     169    /**
     170     * Makes request to Profile URL to add badge to organizer/speaker. Also adds a meta entry which is used by `maybe_remove_badge` function to figure out whether to remove a badge or not.
     171     *
     172     * @param WP_Post $post     Speaker/Organizer Post Object.
     173     * @param int     $user_id  User ID to add badge for.
     174     */
     175    protected function add_badge( $post, $user_id ) {
     176        if ( ! in_array( $post->post_type, [ 'wcb_speaker', 'wcb_organizer' ] ) || ! $user_id ) {
     177            return;
     178        }
     179
     180        $meta_key = $this->get_user_meta_key( $post );
     181
     182        // User already has a badge. Prevent wasteful API call and bail.
     183        if ( get_user_meta( $user_id, $meta_key ) ) {
     184            return;
     185        }
     186
     187        update_user_meta( $user_id ,$meta_key, true );
     188
     189        $this->remote_post( self::PROFILES_HANDLER_URL, $this->get_post_association_payload( $post, 'add', $user_id ) );
     190    }
     191
     192    /**
     193     * Makes a request to remove speaker/organizer badge from a user if the user is removed from all WordCamp where they were speaker/organizer.
     194     *
     195     * @param WP_Post $post     Speaker/Organizer Post Object.
     196     * @param int     $user_id  User ID to remove the badge for.
     197     */
     198    protected function maybe_remove_badge( $post, $user_id ) {
     199        global $wpdb;
     200
     201        if ( ! in_array( $post->post_type, [ 'wcb_speaker', 'wcb_organizer' ] ) ) {
     202            return;
     203        }
     204
     205        $meta_key = $this->get_user_meta_key( $post );
     206
     207        // User does not have a badge anyway. Prevent wasteful API call and bail.
     208        if ( ! $user_id || ! get_user_meta( $user_id, $meta_key ) ) {
     209            return;
     210        }
     211
     212        delete_user_meta( $user_id, $meta_key );
     213
     214        $meta_key_prefix = $this->get_user_meta_key_prefix( $post );
     215
     216        $count = $wpdb->get_var(
     217            $wpdb->prepare(
     218                "SELECT COUNT(*) FROM $wpdb->usermeta
     219                WHERE
     220                    user_id = %d
     221                    AND meta_key like '$meta_key_prefix%';
     222                ",
     223                $user_id
     224            )
     225        );
     226
     227        if ( '0' === $count ) {
    168228            $this->remote_post( self::PROFILES_HANDLER_URL, $this->get_post_association_payload( $post, 'remove', $user_id ) );
    169229        }
     230    }
     231
     232    /**
     233     * Meta key to store user metadata for organizer/speaker association.
     234     *
     235     * We store meta_key in form of wc_{post_type}_{blog_id}_{post_id} because
     236     *
     237     * 1. Since meta_key is indexed, count query on wc_{post_type}% for a specific user_id will be performant. We will use this query to figure out if we want to remove a badge.
     238     *
     239     * 2. Adding separate rows per WordCamp per User per Post allows us to avoid incorrect badge removal in some cases.
     240     * For egs, when an organizer accidentally adds same wporg name to multiple speaker post, and then corrects their mistake by removing it in all but one post.
     241     *
     242     * 3. Because of verbosity, deleting user meta entry will be less error prone.
     243     *
     244     * @param WP_Post $post Sponsor/Organizer post object.
     245     *
     246     * @return string
     247     */
     248    private function get_user_meta_key( $post ) {
     249        return $this->get_user_meta_key_prefix( $post ) . get_current_blog_id() . '_' . $post->ID;
     250    }
     251
     252    /**
     253     * Meta key prefix to store user metadata for organizer/speaker association. This prefix is used in count query to figure if a user should have an organizer/speaker badge.
     254     *
     255     * @param WP_Post $post Sponsor/Organizer post object.
     256     *
     257     * @return string
     258     */
     259    private function get_user_meta_key_prefix( $post ) {
     260        return 'wc_' .  $post->post_type . '_';
     261    }
     262
     263    /**
     264     * Meta key name to store user matadata for whether activity is published or not.
     265     * Used to prevent publishing duplicate activities.
     266     *
     267     * @param WP_Post $post Post object, will be organizer/sponsor/tix_attendee.
     268     *
     269     * @return string
     270     */
     271    private function get_published_activity_key( $post ) {
     272        return 'wc_published_activity_' . get_current_blog_id() . "_$post->ID";
    170273    }
    171274
Note: See TracChangeset for help on using the changeset viewer.