Unable to upload a profile photo — EX0 / HTTP 500

[maximus]

Hi,

I can no longer change my profile photo on this forum. It worked previously, but saving a new avatar now fails.

Steps to reproduce:
1. Open my profile and choose Profile Photo.
2. Upload a valid JPEG image.
3. Continue/save the form.

What happens:
- The temporary upload completes successfully.
- The final save sometimes reports “This field is required”.
- With a fresh upload and a single normal form submission, the server responds with HTTP 500 and error code EX0.
- The profile photo remains unchanged.

I tested this in both Chrome and Firefox, using the original image and a clean 150×150 JPEG well below the size limit. I also tested a single native form submission without the AJAX pre-validation, with the same HTTP 500 result. This suggests the failure happens during server-side profile-photo finalization rather than during the upload itself.

Could an administrator please check the Invision System Logs and the profile-photo storage/finalization configuration, including the S3 storage mapping if applicable?

Profile: https://processwire.com/talk/profile/102307-maximus/

Thanks!

[maximus]

Additional technical details for reproducibility and AI-assisted diagnosis

Environment

• Authenticated member profile: ID 102307.
• Reproduced in current Chrome and Firefox on macOS.
• The uploader UI advertises a maximum image size of 150×150 and a maximum file size of approximately 0.49 MB.
• Clean test asset: baseline JPEG, RGB, exactly 150×150 pixels, 6,919 bytes, with metadata removed.

Observed request sequence

1. The asynchronous temporary-upload request succeeds with HTTP 200.
2. Its JSON response contains a numeric temporary file ID, a server-issued key, and an S3-backed image URL.
3. Fetching that temporary image URL succeeds with HTTP 200, so the bytes reach temporary storage correctly.
4. The final request is POST /talk/profile/102307-maximus/photo/.
5. The expected form values are present (values and security tokens omitted here):

profile_photo_submitted=1
pp_photo_type=custom
member_photo_upload=<server-issued temporary key>
member_photo_upload_existing[<client file ID>]=<numeric temporary file ID>
member_photo_upload_keep[<client file ID>]=1
plupload=<server-issued uploader token>

6. Using the normal modal workflow can produce “This field is required”.
7. To rule out an AJAX validation/double-submit problem, I performed a fresh upload and invoked a single native HTML form submission with HTMLFormElement.prototype.submit.call(form). This sent exactly one final POST without the AJAX pre-validation. The response was still HTTP 500 / EX0.
8. After reloading the public profile, the avatar remains the generated green “M”, confirming that no member-photo update was committed.

Likely failure boundary

The evidence points to server-side finalization after the temporary object has already been accepted. Candidate stages include:

• copying/moving the temporary S3 object into permanent profile-photo storage;
• creating the final resized/cropped derivative;
• updating the member profile-photo record;
• storage mapping, object permissions, endpoint, or bucket/prefix configuration;
• cleanup of the temporary upload after finalization.

Suggested administrator checks

• Correlate the failing POST and member ID 102307 with the Invision System Logs, PHP error log, and web-server log, and capture the underlying exception/stack trace hidden by EX0.
• Verify the configured storage location for profile photos, not only temporary uploads.
• If S3 is used, verify that the application can read, copy/write, and delete objects in both the temporary and permanent prefixes and that any required visibility/ACL behavior still matches the current bucket policy.
• Verify that the image-processing backend can decode and write this small baseline JPEG.
• Reproduce with another existing member and with an administrator account to distinguish account-record corruption from a global storage/finalization fault.
• Review any Invision upgrade, storage-location migration, credential, endpoint, bucket-policy, or PHP/image-library change made around the time profile-photo uploads stopped working.

Important scope note: this is the Invision Community forum software used by processwire.com, not ProcessWire core or a ProcessWire image field.

I can provide exact timestamps for another controlled attempt if an administrator is ready to correlate it with the logs.

[maximus]

Controlled reproduction log — PW-AVATAR-20261010-01

This is a fresh, timestamped run for server-log correlation. All cookies, CSRF values, uploader tokens, temporary keys, numeric temporary object IDs, and signed storage URLs are intentionally redacted.

Time basis

• Client timezone: America/New_York (EDT, UTC−04:00).
• Run started: 2026-10-10 18:04:06 EDT / 2026-10-10T22:04:06Z.
• Temporary upload displayed Done: 2026-10-10 18:04:49 EDT / 2026-10-10T22:04:49Z.
• HTTP 500 / EX0 observed: 2026-10-10 18:05:10 EDT / 2026-10-10T22:05:10Z.

Client and account

• Authenticated forum member: maximus, member ID 102307.
• Client: macOS, current Chrome session. The same failure was also reproduced separately in Firefox.
• Profile-photo form: GET /talk/profile/102307-maximus/photo/.
• Advertised limits: 150×150 pixels and approximately 0.49 MB.

Exact test asset

Filename: avatar-150.jpg
Format: JPEG / JFIF 1.02, baseline, 8-bit, 3 components
Dimensions: 150 × 150 pixels
File size: 6,919 bytes
SHA-256: 1892561d9c384af91fb974fd1e573434e13421b08bc8e572beff565c53ba6c47

The image was freshly transcoded from the requested avatar; original EXIF/ICC metadata was not retained.

Fresh reproduction sequence

1. Loaded the profile-photo page while authenticated.
2. Selected the test JPEG. The uploader completed and the UI changed from Uploading... to 7 kb · Done at 22:04:49 UTC.
3. In previously captured runs, this temporary-upload stage returned HTTP 200 JSON containing a numeric temporary ID, a server-issued key, and an S3-backed temporary image URL; a direct GET of that temporary URL returned HTTP 200.
4. Verified that the form contained the expected profile-photo and temporary-upload fields. No values were manually changed.
5. To exclude modal AJAX pre-validation or a double-submit race, I did not press Continue. I issued exactly one native HTML form submission:

const form = document.querySelector('input[name="member_photo_upload"]').form;
HTMLFormElement.prototype.submit.call(form);

Sanitized final form structure

profile_photo_submitted=1
pp_photo_type=custom
member_photo_upload=<redacted server-issued temporary key>
member_photo_upload_existing[<client file ID>]=<redacted numeric temporary ID>
member_photo_upload_keep[<client file ID>]=1
plupload=<redacted server-issued uploader token>

Observed final response

POST https://processwire.com/talk/profile/102307-maximus/photo/
HTTP status: 500 Internal Server Error
Browser console: Failed to load resource: the server responded with a status of 500
Rendered page: “Sorry, there is a problem. Something went wrong. Please try again.”
Invision error code: EX0

The public profile was reloaded immediately afterwards. The avatar was still the generated green “M”, so no profile-photo update was committed.

What this rules out

• The file is below both advertised limits and is a small baseline JPEG.
• The failure is not caused by Firefox/Chrome-specific UI behavior.
• The failure is not limited to the original high-resolution source image.
• The failure is not caused solely by the modal's AJAX validation or an accidental double submit.
• The bytes reach temporary storage; the failing boundary is after temporary upload and during finalization.
• There is no safe member-level REST fallback: the Invision member-edit API requires administrative credentials and exposes no ordinary self-service avatar upload endpoint. The forum also shows no URL-import, Gravatar, or linked social-avatar option.

Most useful server-side correlation points

• Search Invision System Logs, PHP-FPM/PHP logs, and the web-server error log for member ID 102307 and the final POST between 22:04:49Z and 22:05:10Z, especially around 22:05:10Z.
• Capture the underlying exception class, message, and stack trace hidden by EX0.
• Inspect profile-photo finalization: temporary-object lookup, copy/move into permanent storage, resize/crop derivative generation, member-record update, and temporary-object cleanup.
• If S3 is configured, verify the profile-photo storage mapping separately from temporary-upload storage, including read, copy/write, delete, region/endpoint, bucket policy, ACL/visibility behavior, and permanent prefix permissions.
• Compare one administrator account and one other existing member to distinguish member-record corruption from a global storage/finalization fault.

Conclusion: the controlled run consistently reaches temporary-upload completion and then fails on the single final profile-photo POST with HTTP 500 / EX0. Client-side JavaScript cannot repair the hidden server exception; the next actionable artifact is the matching server-side stack trace for the timestamp above.