Best Regards,

I have cleared all the WPForo caches and my hosting says that WPForo is excluded from all caches. 

I am using WPForo v3.1.1 and I would appreciate any suggestions to cure this issue for half a dozen of my 2,500 forum users.

Thanks

After inspecting the raw headers of a forum notification email received at a Gmail address, it's clear the issue is that List-Unsubscribe and List-Unsubscribe-Post headers are absent from these emails entirely.

For context, our other email sources are fully compliant. ActiveCampaign marketing emails include both headers and pass all Gmail authentication checks (DKIM, SPF, DMARC).

The wpForo notification emails do include a per-user unsubscribe link in the message body in this format:

https://example.com/community/?wpfaction=unsbscrb&key=<unique_per_user_key>

This unsubscribe link works correctly and unsubscribes the user immediately (no confirmation step), which is exactly the behavior required by RFC 8058 for one-click unsubscribe compliance.

What's missing is surfacing that URL in the email headers so that Gmail can display its native unsubscribe button. Per Gmail and Yahoo's bulk sender requirements (enforced since February 2024), subscription messages must include:

List-Unsubscribe: <https://example.com/community/?wpfaction=unsbscrb&key=unique_key>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Since the per-user key is generated dynamically per email, a static header isn't an option — the header needs to be injected at send time with the correct URL for that recipient.

A few questions for the wpForo team and community:

1. Is there a built-in mechanism in wpForo (current or planned) to add List-Unsubscribe headers to notification emails?
2. If not, is there a recommended hook or filter to intercept the outgoing email and inject the header with the correct per-user unsubscribe URL?
3. Has anyone else addressed this, and if so, what approach did you take?

We're aware of the phpmailer_init and wp_mail filter hooks as a potential DIY path, but would prefer a solution that's implemented or suggested by wpForo to avoid fragility from future plugin updates. I'm happy to share full raw headers or additional detail if helpful.

I have hidden my forum/categories from guests. However, the statistics bar is still visible.

The only way I can hide it is to hide it from all usergroups. But I would just like it to be hidden from guests only. 

Is there a way to do this at all?

Many thanks in advance. :)

I've already enabled caching and optimized my database, but the performance improvement has been minimal. Has anyone faced a similar issue with wpForo? I'd appreciate any suggestions on settings, plugins, or server optimizations that could help improve forum speed.

• Ultimate forum links are set to /user/
• wpForo links are set to /member/

The widget updates all of the buttons to point to /user/ except for the "favored" button. That button directs to the wpForo profile page. There isn't a place to change the link or add/remove buttons.

I cleared cache and flushed Permalinks.

What is the best solution for this, or where can it be edited in the code, function, etc?

Slightly off-topic, the same thing happens with messages. Better Messages support isn't offered by wpForo, but it is integrated with UM on the UM profile page. Understandably, there is only a message button when the wpForo private message plugin is active, but it doesn't know to point to the UM messages tab. Also understandable, but it would be better if there was a way to easily edit button links or add custom buttons. Especially since the wpForo notifications function doesn't really integrate well with anything else outside of wpForo.

I have a question regarding attachment permissions in wpForo.

As an Administrator, I can see the "Delete" button for uploaded attachments in the post editor/media manager and I can remove files before or after posting.

However, regular forum users can upload files and insert them into posts, but they do not see any option to delete their own uploaded attachments.

Is there a setting, user group permission, or forum access permission that allows users to delete their own attachments/files?

If so, could you please tell me where this option can be enabled?

I am using WordPress with wpForo and would like users to be able to manage and remove their own uploaded files without requiring administrator intervention.

Thank you for your help.

Summary

In wpforo_do_hook_user_register(), the $wpfreg array is intersected with a four-key allowlist (user_login, user_email, user_pass1, user_pass2) before Members::update() is called. This silently strips any other fields posted via wpfreg[] — including first_name, last_name, and user_url, all of which are listed as save targets in Members::update_user_fields() at lines 948–957. The downstream save block then sees those keys as missing and skips the corresponding update_user_meta() calls. The registration completes successfully and the user is created, but with empty first_name and last_name in wp_usermeta.

This appears to be a security hardening (the inline comment mentions blocking attackers from pivoting userid via wpfreg[]) but the allowlist is overly restrictive — the userid is already forced on the next line, so widening the allowlist to include the standard WP user fields wpForo Core itself already saves doesn't reopen any attack surface.

Reproduction

1. Install wpForo Core 3.1.1 + wpForo User Custom Fields (any recent version).
2. Configure the registration form to include first_name and last_name (default UCF setup does this).
3. Register a new user via the forum's /sign-up/ page, filling in First Name = FirstTest and Last Name = LastTest.
4. Check the new user's meta: wp user meta list <id> | grep -E 'first_name|last_name'.

Expected: first_name = FirstTest, last_name = LastTest.
Actual: both empty.

Root cause

At includes/hooks.php ~line 2210:

$data = array_intersect_key( $wpfreg, array_flip(  ) );

The intersection drops first_name and last_name (and user_url) before WPF()->member->update() is called at line 2234, so Members::update_user_fields() never sees them.

Verified fix

Adding the three standard WP user fields back to the allowlist resolves the issue and re-saves them correctly via the existing update_user_meta() calls in update_user_fields():

$data = array_intersect_key( $wpfreg, array_flip(  ) );

The $data = (int) $userid; line immediately below this still forces the trusted userid, so the security goal of the original change is preserved — the allowlist just needs to permit the additional standard WP user fields that Members::update_user_fields() already handles.

Logged evidence

Instrumented Members::create() and Members::update_user_fields() with error_log() calls, registered a user, then captured the $_POST, $data at entry to create(), $user_fields after the wpfreg split, and $data at the save gate. The trace shows first_name / last_name present in $_POST and in the post-split $user_fields, then absent from $data by the time it reaches the save block — confirming the allowlist intersection as the strip point. Re-running the same test after adding the three keys to the allowlist resulted in both fields landing in wp_usermeta as expected.

Notes

• The strip is silent — no error, notice, or admin alert. The registration appears successful from every visible angle.
• Sites using wpForo User Custom Fields to add other custom fields on the registration form aren't affected by those fields being lost, because UCF custom fields arrive under $_POST rather than $_POST and are handled separately. The strip only affects the standard WP user fields that arrive under wpfreg[].