Thank you for letting us know. This topic has already been forwarded to our development team, and they will definitely take this into consideration.

For example, there may be an HTML tag that was opened but not properly closed, or a bracket/HTML character may be missing (such as < or >). This malformed HTML is causing the issue.

Please check the content of the affected topic/post for any broken or incomplete HTML markup.

Original as exported by AIOWPM

After wpforo modified tables

https://wpforo.com/community/how-to-and-troubleshooting-2/25971/

After seeing the same problem and being unable to restore wpforo to a new server, I have communicated with Servmask.

This appears to be a wpforo problem, not a all in one wp migration plugin problem. 

Wpforo is changing the original database tables.  They are all stored and imported correctly by AIOWPM.

Wpforo developers please resolve issue. It is imperative that the forums can be backed up and migrated correctly.

The solution:

• On the new server I deleted all the wpforo database tables
• I re-ran the AIOWPM import - all tables then appeared correctly in the db.
• This proves AIOWPM correctly stored and imports the database.
• The forum still wasnt working at this point.
• In Wordpress>wpforo>Tools>Database Tables, errors were indicated
• Ran the repair option here and everything started working OK

Based on what you've described and the similar issues others have reported, it sounds like you're dealing with malformed HTML that's breaking the page structure. Your colleague's assessment is likely correct—this typically happens when HTML code gets corrupted or improperly formatted in a post, which then cascades and breaks the rendering of subsequent content on the page. The fact that you can't click on reply, quote, or report links suggests the HTML structure itself is damaged, preventing the DOM from rendering those interactive elements properly.

Here's a step-by-step approach to diagnose and fix the issue:

1. Identify the problematic post: Look through your thread and find where the formatting breaks. Usually it's right after a post that contains copied content from external sources or unusual formatting.
2. Access your database: Connect to your forum's database using phpMyAdmin or your preferred database management tool.
3. Locate the post content: Find the specific post record that's causing the issue. Search for posts around the time the formatting broke.
4. Inspect the HTML: Look at the raw post content in the database. Check for unclosed tags, mismatched quotes, or embedded HTML that wasn't properly escaped.
5. Clean the content: Remove or fix the problematic HTML code directly in the database. Common culprits include unescaped `<` and `>` characters, unclosed `
   `, ``, or `

   ` tags.

6. Test the fix: Refresh your forum and verify that the post now displays correctly and all interactive elements (reply, quote, report buttons) are functional again.

As a preventative measure, you might want to implement stricter HTML sanitization in your forum software to prevent users from pasting malformed code. Can you tell me—when you look at the post content in the database, do you see any obvious unclosed HTML tags or unusual character encoding issues?

Version: 3.1.4

https://www.directupload.eu/file/d/9367/ojouwii8_png.htm

Unfortunately, I can't send a live link because the forum isn't visible to everyone...

I updated a production site to 3.1.4 on 24 July and the bug returned immediately. I've since compared the released packages from wordpress.org directly: includes/hooks.php is byte-identical across 3.1.1, 3.1.2, 3.1.3 and 3.1.4 - diff returns no output at all. wpforo_do_hook_user_register() still reads:

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

Searching the entire 3.1.1 -> 3.1.4 diff for first_name or last_name returns no matches anywhere in the plugin, so nothing in this code path has changed. I suspect the change simply didn't make it into the release.

To restate the mechanism: first_name, last_name and user_url are default profile fields with isDefault => 1, so Forms.php:1063 gives them varname 'wpfreg' and Forms.php:1121 renders them as name="wpfreg". The allowlist above then strips them from $_POST before Members::update() runs, so Members::update_user_fields() (Members.php:952) never receives them and no update_user_meta() call happens. The saver is fine - the data is discarded upstream of it.

For completeness, in case this was closed against one of these: neither of the two changelog entries that look related actually touches this path.

• 3.1.2 "Fixed: Issue with User Custom Fields addon, the missing fields data" - that's the $_POST branch. UCF-managed fields have isDefault falsy, so Forms.php:1063 gives them varname 'data' - a different branch of the same function. The UCF addon contains no reference to first_name or last_name at all.
• 3.1.3/3.1.4 "Security: Fixed mass assignment bypass in profile and registration forms" - that's the custom_points / status / is_email_confirmed unsets added to Members.php. Also unrelated to the name fields.

On the fix itself: I understand why the allowlist was added and I'm not suggesting reverting it. But first_name, last_name and user_url are not privileged fields, and the userid pivot is already neutralised on the very next line by $data = (int) $userid;. Adding these three back restores the documented behaviour without weakening that hardening:

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

Better still would be deriving the allowlist from the active registration form's field set rather than hardcoding it, so any enabled default field works and this can't regress again. Failing that, please consider adding a filter to the allowlist so site owners can work around it without editing plugin files - that's the part that has cost us most here.

Worth flagging the impact, because it is completely silent: registration succeeds, the names are lost with no error shown to anyone, and the values are unrecoverable afterwards. On our site 14 members registered in that state before it was spotted - and this is the second time, because the update reinstated the behaviour after we had patched it locally. We've now had to move our fix outside the plugin directory so your updates can't remove it again.

Happy to supply the diffs or any further detail if useful.

Thanks