Unable to successfully crop member profile photo (avatar)

[emaralive]

Note

This discussion is experimental such that it tests the notification within Slack for discussions from this repository (bp-documentation) and a way for me to externalize my notes, such that others can eyeball this and make comment, if they inclined to do so. This may lead to an issue submitted to create documentation for the Avatar process and lead to a Trac ticket such that this anomaly can be fixed.

The inability to successfully crop an image to be used as a profile photo via the front end (change profile photo) or the back end (extended profile) occurs when the Modern Image Formats plugin is installed, activated and configured to convert uploaded images to the WordPress media library as the AVIF image output format.

This was made apparent by the Any hope for BuddyPress to support AVIF file type soon? support forum topic. There may be other through lines such as the I cannot crop the profile photo support forum topic and Trac ticket 9208.

PHP AVIF support for the GD extension appears to be v8.1+ (see PHP 8.1: GD: AVIF image support). However, the Modern Image Formats plugin allows for selection of AVIF with v8.0.30 (maybe this is through the imagick extension - note this is unconfirmed and speculation). When AVIF is configured via the aforementioned plugin any attempt to upload and crop an image results with the following user defined message:

There was a problem cropping your profile photo.

With PHP v8.0.30 error warnings are generated, e.g,:

Mar 12, 21:19:04
Warning: Trying to access array offset on value of type bool in /wp-content/plugins/buddypress/bp-core/classes/class-bp-attachment-avatar.php on line 311
 
Mar 12, 21:14:05
Warning: Trying to access array offset on value of type bool in /wp-content/plugins/buddypress/bp-core/bp-core-avatars.php on line 1202
 
Mar 12, 21:14:05
Warning: Trying to access array offset on value of type bool in /wp-content/plugins/buddypress/bp-core/bp-core-avatars.php on line 1201

With PHP v8.0.30 & 8.1.31 there are other observable symptoms, see the following screenshot:

Upon further review, PHP v8.1.31 produces a user-defined error message of:

The aspect ratio of the image you selected is too great compared to the profile photo one. For best results, upload a picture having an aspect ratio closer to 1.00.

The following screenshot illustrates the aforementioned user-defined error message:

With PHP v8.2.27, v8.3.17 & v8.4.4 the cropping page appears to be normal, see the following screenshot:

Furthermore, it appears the image that is used for an avatar (original image) has the file extension of avif with the aforementioned plugin installed, activated and configured for AVIF. For example, the original is disc.png and in the avatar upload folder the image is disc-450x450.avif, meaning without the plugin, uploading disc.png would result in disc-450x450.png within the avatar upload folder.

Tip

The AVIF mime type is, currently, not an allowed mime type for BuddyPress.

As an example to the tip:

bp_core_get_allowed_avatar_mimes()
=> array(6) {
 ["jpg"]=>
 string(10) "image/jpeg"
 ["jpeg"]=>
 string(10) "image/jpeg"
 ["jpe"]=>
 string(10) "image/jpeg"
 ["gif"]=>
 string(9) "image/gif"
 ["png"]=>
 string(9) "image/png"
 ["webp"]=>
 string(10) "image/webp"
}

The environment used to investigate can be viewed by expanding the details for "Environment"

Environment

• WordPress: 6.7.2
• Is this site using HTTPS?: no
• PHP: 8.0.30, 8.1.31, 8.2.27, 8.3.17, 8.4.4
• Server: Apache/2.4.62 (AlmaLinux)
• Database: mysqli (Server: 10.5.27-MariaDB
• Browser: 134.0.6998.35 (Official Build) Fedora Project (64-bit)
• OS: Linux (AlmaLinux 9.5 (Teal Serval))
• Theme: Twenty Eleven
• Active editor: WP_Image_Editor_Imagick
• ImageMagick version number: 1809
• ImageMagick version string: ImageMagick 7.1.1-45 Q16-HDRI x86_64 22722
• Imagick version: 3.7.0
• MU Plugins:
  • Health Check Troubleshooting Mode 1.9.2
• Plugins:
  • bbPress 2.6.12
  • BP Classic 1.4.0
  • BuddyPress 14.3.3
  • Health Check & Troubleshooting 1.7.1
  • JSON Basic Authentication 0.1
  • Modern Image Formats 2.5.0
  • Test Reports 1.2.0
  • User Switching 1.9.1
• BuddyPress:
  • Active components - All
  • URL Parser - Legacy Parser
  • Active template pack - BP Nouveau
  • Community Members: Profile Photo Uploads - Yes

Observations - Two things can be true at the same time

The missing bounding box for cropping appears to be related to the original size of the uploaded image, e.g. images larger than 450 x 450 cause the bounding box issue due the triggering of a resize process, this appears to only apply to PHP versions - 8.0.30 & 8.1.31. For the indicated PHP versions, when an image that is less than or equal to 450 x 450 the bounding box appears and the image can be cropped, as normal.

The threshold for when to resize an uploaded image appears to be based on the BP_AVATAR_ORIGINAL_MAX_WIDTH constant which has a default value of 450 (in pixels). The following Cases provide some level of detail as to what is occurring.

Cases

Case 1

• PHP: 8.1.31
• original file - DSC5565._1_c_450.jpg - 450 x 450 (in pixels)
• file after upload: DSC5565._1_c_450.jpg - 450 x 450 (in pixels)
• crop bounding box: yes
• successful crop: yes
• extension and mime type of avatars: avif (thumb & full)

Case 2

• PHP: 8.1.31
• original file - disc.png - 600 x 600 (in pixels)
• file after upload: disc-450x450.avif - 450 x 450 (in pixels)
• crop bounding box: no
• successful crop: no
• extension and mime type of avatars: n/a

Case 3

• PHP: 8.2.27
• original file - disc.png - 600 x 600 (in pixels)
• file after upload: disc-450x450.avif - 450 x 450 (in pixels)
• crop bounding box: yes
• successful crop: no
• extension and mime type of avatars: n/a

Array of supported image types when there is a failed crop attempt for the mime type of image/avif

$supported_image_types = array_fill_keys( bp_attachments_get_allowed_types( 'image' ), 1 )
=> array(6) {
  ["jpg"]=>
  int(1)
  ["jpeg"]=>
  int(1)
  ["jpe"]=>
  int(1)
  ["gif"]=>
  int(1)
  ["png"]=>
  int(1)
  ["webp"]=>
  int(1)
}

Array of supported image types when there is a successful crop for the mime type of image/avif

$supported_image_types = array_fill_keys( bp_attachments_get_allowed_types( 'image' ), 1 )
=> array(7) {
  ["jpg"]=>
  int(1)
  ["jpeg"]=>
  int(1)
  ["jpe"]=>
  int(1)
  ["gif"]=>
  int(1)
  ["png"]=>
  int(1)
  ["webp"]=>
  int(1)
  ["avif"]=>
  int(1)
}

Given: $file = '/wp-content/uploads/avatars/1/disc-450x450.avif'

PHP 8.0.30

var_dump(getimagesize($file));
bool(false)

PHP 8.1.31

var_dump(getimagesize($file));
array(5) {
  [0]=>
  int(0)
  [1]=>
  int(0)
  [2]=>
  int(19)
  [3]=>
  string(20) "width="0" height="0""
  ["mime"]=>
  string(10) "image/avif"
}

PHP 8.2.27, 8.3.17 & 8.4.4

var_dump(getimagesize($file));
array(7) {
  [0]=>
  int(450)
  [1]=>
  int(450)
  [2]=>
  int(19)
  [3]=>
  string(24) "width="450" height="450""
  ["bits"]=>
  int(8)
  ["channels"]=>
  int(4)
  ["mime"]=>
  string(10) "image/avif"
}

wp_getimagesize() function

wp_getimagesize( $file )
=> array(5) {
  [0]=>
  int(450)
  [1]=>
  int(450)
  [2]=>
  int(19)
  [3]=>
  string(24) "width="450" height="450""
  ["mime"]=>
  string(10) "image/avif"
}

What was not previously mentioned

Neither complainant mentioned they had issues with Group profile photos (avatar). Fortunately, this situation also applies to the Group profile photo (avatar), therefore the solution will solve for both, i.e., for Members and for Groups.

Furthermore during the group creation process the step for cropping an image does not remain at that step after a failed crop attempt nor indicates that there was a failure e.g.:

There was a problem cropping your profile photo.

Meaning, the process just moves on to the next step. However, if an attempt is made after the group has been created (Manage > Photo) then the indicated user-defined message presents itself.

Special note to self

WordPress utilizes the wp_image_editor_supports() function (Tests whether there is an editor that supports a given mime type of methods) to determine, e.g., does the server support a given mime type. This appears to be independent of the PHP version and may take into account of the imagick extension capability - this is pure speculation at this point.

The point is that I'm observing behavior on a different server that allows for PHP version 7.4.33 to crop the image/avif mime type. There are differences in Environment, e.g.:

Environment 2

• WordPress: 6.7.2
• Is this site using HTTPS?: yes
• PHP: 7.4.33
• Server: Apache/2.4.58 (Debian)
• Database: mysqli (Server: 11.4.5-MariaDB-1
• Browser: 134.0.6998.35 (Official Build) Fedora Project (64-bit)
• OS: Linux (5.10.102.1-microsoft-standard-WSL2 x86_64) - Kali)
• Theme: Twenty Eleven
• Active editor: WP_Image_Editor_Imagick
• ImageMagick version number: 1691
• ImageMagick version string: ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25
• Imagick version: 3.7.0
• MU Plugins:
  • Health Check Troubleshooting Mode 1.7.2
• Plugins:
  • BuddyPress 14.3.3
  • BP Attachments 1.2.0
  • BP Beta Tester 1.3.0
  • BP Messaging Control 1.8.0
  • BP Search Block 1.1.0
  • Modern Image Formats 2.5.1
  • Test Reports 1.2.0
  • User Switching 1.9.1
• BuddyPress:
  • Active components - All
  • URL Parser - Legacy Parser
  • Active template pack - BP Nouveau
  • Community Members: Profile Photo Uploads - Yes

The difference may be in the build for imagick extension, e.g., includes avif support for a given PHP version, albeit, imagick versions could be the same or there is some unknown factors that dictate the difference. That stated, as long as the wp_image_editor_supports() is used to determine if the image/avif mime type is supported then, all should work out, accordingly.

The bp_attachments_get_allowed_types() function could be modified or the bp_attachments_get_allowed_types could be hooked with a callback to include a conditional such as, see https://github.com/buddypress/buddypress/blob/14.3.3/src/bp-core/bp-core-attachments.php#L163-L222):

if ( wp_image_editor_supports( array( 'mime_type' => 'image/avif' ) ) ) {
	$ext[] = 'avif';
}

The above resolves the cropping issue for the image/avif mime type. To resolve the crop bounding box issue is to replace the getimagesize() function with the wp_getimagesize() function, see https://github.com/buddypress/buddypress/blob/14.3.3/src/bp-core/bp-core-avatars.php#L1187, e.g.:

From:

$uploaded_image = @getimagesize( $bp->avatar_admin->image->file );

To:

$uploaded_image = wp_getimagesize( $bp->avatar_admin->image->file );

Additionally, this change eliminates 2 PHP error warnings associated with v8.0.30 & v7.4.33 (bp-core-avatars.php lines 1201 & 1202) .

Furthermore, to resolve the 3rd PHP error warning associated with v8.0.30 & v7.4.33 (class-bp-attachment-avatar.php line 311) is to replace the getimagesize() function with the wp_getimagesize() function, see https://github.com/buddypress/buddypress/blob/14.3.3/src/bp-core/classes/class-bp-attachment-avatar.php#L310, e.g.:

From:

$data = @getimagesize( $absolute_path );

To:

$data = wp_getimagesize( $absolute_path );

The next area to look at is the REST API since the getImagesize() function is used by V1, see https://github.com/buddypress/BP-REST/blob/0.8/includes/bp-attachments/classes/trait-attachments.php#L315 and for V2, see https://github.com/buddypress/buddypress/blob/master/src/bp-core/classes/trait-attachments.php#L316:

$image          = getimagesize( $image_file );

One other note to make, if there is an unsuccessful crop attempt or is an image is uploaded and the user leaves the upload tab, the image that was uploaded (original) remains. The original image is only removed after a successful crop, therefore there should be a cleanup/tidy up check/routine to make sure that there are not residual original images remaining.

Other image mime types allowed by WordPress

BuddyPress is not keeping up with WordPress in regards to allowed mime types for images and as it stands the full complement as of WP 6.7.2 is:

mimes
=> array(12) {
  [0]=>
  string(10) "image/jpeg"
  [1]=>
  string(9) "image/gif"
  [2]=>
  string(9) "image/png"
  [3]=>
  string(9) "image/bmp"
  [4]=>
  string(10) "image/tiff"
  [5]=>
  string(10) "image/webp"
  [6]=>
  string(10) "image/avif"
  [7]=>
  string(12) "image/x-icon"
  [8]=>
  string(10) "image/heic"
  [9]=>
  string(10) "image/heif"
  [10]=>
  string(19) "image/heic-sequence"
  [11]=>
  string(19) "image/heif-sequence"
}

Perhaps, the heic and heif mime types should be considered as allowable for BuddyPress. Additionally, for WP 6.7+ there is automatic conversion of hiec images to jpeg.