Project

General

Profile

Actions

Bug #21708

closed

Reclaim Testing: 404 on "Account Settings > Edit Profile" page

Added by Raymond Hoh about 1 month ago. Updated 23 days ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
BuddyPress (misc)
Target version:
Start date:
2025-01-07
Due date:
% Done:

0%

Estimated time:
Deployment actions:

Description

While going through some Reclaim testing, I've found that the "Account Settings > Edit Profile" page located at -- /members/me/profile/edit/group/1/ -- is throwing a 404. BuddyPress settings look correct and I tried refreshing the "Settings > Permalinks" page, but this didn't fix things.

I also wanted to see if Extended Profiles were working in the WP admin dashboard and there is a somewhat, related error. To replicate, go to the "WP Admin > Users > Your Profile > Extended Profile" page, there is a fatal error under the "College" profile field:

Fatal error: Uncaught Error: __clone method called on non-object
in /wp-content/plugins/bp-custom.php on line 2572

Call stack:

cac_college_field_children()
wp-includes/class-wp-hook.php:324
WP_Hook::apply_filters()
wp-includes/plugin.php:205
apply_filters()
wp-content/plugins/buddypress/bp-xprofile/classes/class-bp-xprofile-field.php:637
BP_XProfile_Field::get_children()
wp-content/plugins/buddypress/bp-xprofile/classes/class-bp-xprofile-field-type-checkbox.php:106
BP_XProfile_Field_Type_Checkbox::edit_field_options_html()
wp-content/plugins/buddypress/bp-xprofile/bp-xprofile-template.php:857
bp_get_the_profile_field_options()
wp-content/plugins/buddypress/bp-xprofile/bp-xprofile-template.php:809
bp_the_profile_field_options()
wp-content/plugins/buddypress/bp-xprofile/classes/class-bp-xprofile-field-type-checkbox.php:84
BP_XProfile_Field_Type_Checkbox::edit_field_html()
wp-content/plugins/buddypress/bp-xprofile/classes/class-bp-xprofile-user-admin.php:313
BP_XProfile_User_Admin::user_admin_profile_metaboxes()
wp-admin/includes/template.php:1456
do_meta_boxes()
wp-content/plugins/buddypress/bp-members/classes/class-bp-members-admin.php:1250
BP_Members_Admin::user_admin()
wp-includes/class-wp-hook.php:324

Boone, hopefully that is enough to debug the issue.

Actions #1

Updated by Boone Gorges about 1 month ago

Thanks for the report. I see the same thing and I'll spend some time debugging.

Actions #2

Updated by Boone Gorges about 1 month ago

Regarding the 404 issue, several of the BP tables were corrupt. Eg:

> describe wp_bp_xprofile_fields;
ERROR 1030 (HY000): Got error 194 "Tablespace is missing for a table" from storage engine InnoDB

As such, BP wasn't finding group 1, which resulted in the 404.

I checked all BP tables and found four problematic ones: messages_messages, profile_fields, profile_groups, profile_wire. I manually repaired them by dropping, recreating, and repopulating them from the snapshot files.

I don't know the underlying cause of this issue, but I wrote a tool that crawls through and identifies bad tables, then fixes them in the same manner:

#!/bin/bash

# Ensure the database name, schema directory, and data directory are provided
if [[ $# -lt 3 ]]; then
  echo "Usage: $0 <database_name> <schema_dir> <data_dir>" 
  exit 1
fi

DB_NAME="$1" 
SCHEMA_DIR="$2" 
DATA_DIR="$3" 

echo "Checking for bad tables in the database: $DB_NAME" 

# Fetch all tables from the database
tables=$(mysql --defaults-file=~/.my.cnf -D "$DB_NAME" -e "SHOW TABLES;" | awk '{ print $1 }' | grep -v "^Tables_in_")

# Loop through each table and check its status
for table in $tables; do
  result=$(mysql --defaults-file=~/.my.cnf -D "$DB_NAME" -e "CHECK TABLE \`$table\`;" 2>/dev/null | grep -E "Warning|Error|Corrupt")

  if [[ -n $result ]]; then
    echo "Issues found in table: $table" 
    echo "$result" 
    echo

    # Extract the prefix (up to the last `_`)
    prefix=$(echo "$table" | grep -oE '^[^_]+_[^_]+')
    echo "Identified prefix: $prefix" 

    # Build file paths for schema and data
    SCHEMA_FILE="$SCHEMA_DIR/${prefix}_schema.sql" 
    DATA_FILE="$DATA_DIR/${prefix}_data.sql" 

    if [[ -f "$SCHEMA_FILE" && -f "$DATA_FILE" ]]; then
      echo "Repairing all tables for prefix: $prefix" 

      # Drop and recreate all tables for the prefix
      mysql --defaults-file=~/.my.cnf -D "$DB_NAME" < "$SCHEMA_FILE" 
      if [[ $? -ne 0 ]]; then
        echo "Error applying schema for prefix: $prefix" 
        exit 1
      fi  

      # Reimport data for all tables in the prefix
      mysql --defaults-file=~/.my.cnf -D "$DB_NAME" < "$DATA_FILE" 
      if [[ $? -ne 0 ]]; then
        echo "Error applying data for prefix: $prefix" 
        exit 1
      fi  

      echo "Successfully repaired all tables for prefix: $prefix" 

      # Exit after the first repair for testing
#      echo "Stopping script for testing purposes. First repaired prefix: $prefix" 
#      exit 0                                                                                              
    else
      echo "Missing schema or data file for prefix: $prefix" 
      echo "Expected files:" 
      echo "  Schema: $SCHEMA_FILE" 
      echo "  Data: $DATA_FILE" 
      exit 1
    fi  
  fi  
done

echo "Table checks completed." 

It's running right now and finding a handful of bad blog prefixes. There doesn't seem to be a lot of rhyme or reason to it. But I'll just have to add this to my checklist for after migration.

Actions #3

Updated by Boone Gorges about 1 month ago

Looks like this is also the cause for the wp-admin issue that you found.

I wanted also to flag that this might be a new issue since yesterday's mysql outage. It could be that some tablespaces got corrupted by the sync process, or by the daemon crash, or something like that. As such, I'm hopeful that it was a one-off problem.

Actions #4

Updated by Boone Gorges 23 days ago

  • Status changed from New to Resolved
Actions

Also available in: Atom PDF