The problem is in the multisite

I want to say I faced the same issue and fixed the same way.

There are 2 issues with the plugin today:

• You can’t activate it at network level
• You can’t activate it by code using activate_plugin()

—

Issue 1 – You can’t activate it at network level

The bug is in how the plugin installs its DB tables during network activation. It uses a singleton activator that captures the first site’s $wpdb->prefix and then reuses it while switching blogs, so the tables for site 2 are never created. Activating per-site runs in a fresh request with the correct $wpdb->prefix, so site 2’s tables get created and likes start working.

Key points in the code:

• Network activation loops through sites and switches blogs, but calls a singleton activator each time:

public static function activate( $network_wide ) {
  if ( function_exists( 'is_multisite' ) && is_multisite() ) {
    if ( $network_wide  ) {
      // Get all blog ids
      $blog_ids = self::get_blog_ids();
      foreach ( $blog_ids as $blog_id ) {
        switch_to_blog( $blog_id );
        self::single_activate();
      }
      restore_current_blog();
    } else {
      self::single_activate();
    }
  } else {
    self::single_activate();
  }
}

• The per-site activation entry point calls the singleton activator:

private static function single_activate() {
  // Init activator class
  if( ! class_exists('wp_ulike_activator') ){
    require_once WP_ULIKE_INC_DIR . '/classes/class-wp-ulike-activator.php';
  }
  wp_ulike_activator::get_instance()->activate();

  // Fire action
  do_action( 'wp_ulike_activated', get_current_blog_id() );
}

• The activator caches $wpdb->prefix and table names at construction time (first site), then reuses them for all subsequent sites in the same request:

public function __construct(){
  global $wpdb;
  $this->database = $wpdb;
  $this->tables   = array(
    'posts'      => $this->database->prefix . "ulike",
    'comments'   => $this->database->prefix . "ulike_comments",
    'activities' => $this->database->prefix . "ulike_activities",
    'forums'     => $this->database->prefix . "ulike_forums",
    'meta'       => $this->database->prefix . "ulike_meta"
  );
}

• It’s a singleton, so it’s instantiated once and reused across the blog loop:

public static function get_instance() {
  // If the single instance hasn't been set, set it now.
  if ( null == self::$instance ) {
    self::$instance = new self;
  }
  return self::$instance;
}

Why per-site activation fixes it:

• Each activation runs in a separate request, so the activator singleton is constructed with the correct $wpdb->prefix for that site, and the tables are created properly.

Fix: The activator should not cache $prefix across switched blogs (don’t use a request-scoped singleton here, or rebuild $this->tables after switch_to_blog).

—

Issue 2 – You can’t activate it by code using activate_plugin()

activate_plugin() is the same activation path as clicking activate in wp-admin. So I guess the issue was related to the schema state (pure guess).

What actually bites in wp-ulike:

• The insert includes a fingerprint column:

$table = $this->wpdb->prefix . $this->typeSettings->getTableName();
$data  = array(
    $this->typeSettings->getColumnName() => $item_id,
    'date_time'                          => current_time( 'mysql', true ),
    'ip'                                 => $this->maybeAnonymiseIp( $this->currentIP ),
    'user_id'                            => $this->currentUser,
    'fingerprint'                        => $this->currentFingerPrint,
    'status'                             => $this->currentStatus
);
$row = $this->wpdb->insert( $table, $data, $format );

• But the initial table creates don’t have that fingerprint column; it’s added by a later “upgrade”:

// Add 'fingerprint' column to posts table
$this->database->query( "
    ALTER TABLE $posts
    ADD COLUMN fingerprint VARCHAR(64) DEFAULT NULL AFTER user_id;
" );
// … same for comments/activities/forums …
update_option( 'wp_ulike_dbVersion', '2.4' );

• That upgrade only runs in admin:

public function plugins_loaded(){
    // Upgrade database
    if ( self::is_admin_backend() ) {
        $this->maybe_upgrade_database();
    }
}

I didn’t test this again to be able to write down a step by step how to reproduce the issue, but I can confirm the plugin activation by code didn’t work as the manual/UI plugin activation.

—

So I do agree there is an issue with the plugin activation, how you activate it. Right now, you must manually activate it individually.