XF 1.5 Restore a deleted node

ScarletCox

Active member
Licensed customer
All right. We've had the obligatory accident.

I've found this SQL to restore deleted threads.

Code:
UPDATE xf_thread SET node_id = 38 WHERE node_id = 118

What would I need to fiddle with to recover deleted nodes?

My missing nodes are IDs 186, 187 and 188. Their new parent needs to be 477.

Many thanks!

ETA: The problem being, of course, that these three nodes contained a lot of threads :D
 
If the nodes were deleted via the UI in the ACP, the threads within them will also have been deleted.

You would need to restore from a recent backup to recover them.
 
Hm. Is it possible to restore just those nodes without replacing my entire database with the backup version? Can I load the backup into a fresh database, run a query to extract those nodes and everything in them, then export the query results and import them into the correct database?
 
I suppose a more straight forward answer would be, yes, it will work. However, it's obviously a more careful process than doing a straight forward restore.

Namely, because if you do it wrong, it may end up wiping out your entire database anyway.

For example, a lot of MySQL dumps will often do a "USE database; DROP table;" before inserting the new data. That, of course, would delete the table before trying to add the data back from the dump.

So, in other words, be careful... And definitely take a backup beforehand, and be prepared to fully restore back to that backup in the event anything goes wrong.

Finally, there is probably more to it than you might imagine. As well as the nodes in the xf_node table, there is also the forums in the xf_forum table. There's the threads in the xf_thread table, and then there's the posts in the xf_post table. If all that has been deleted, unfortunately all of the attachments attached to posts in those forums will be deleted too. So that's the xf_attachment and xf_attachment_data table (and all the files which were on the file system for those attachments have probably been cleaned up by now). There's also all of the liked content, but that's probably of somewhat lesser importance.

There of course may be other tables and cached data which are lost, too, which may require rebuilds.

So, that's where the theoretically comes in.

All in all, it may be safer to just go back to the last back up completely, but it of course means losing anything since.

Either way it's not a decision to be made lightly...
 
Yeah, I figured it would be a tricksy little hobbitses. I dislike databases enough as-is :D

Out of interest, I don't suppose the old way of creating new nodes then searching for the old node numbers on the xf_thread table and just assigning the new node numbers would work? Does 1.5 actually purge the records of the deleted threads these days?
 
It may be worth checking, but if the nodes were removed using the Admin CP, we do permanently delete all of the content, so that will include the threads and posts and anything associated with them. It's been like that since 1.2 or 1.3.
 
Just editing nodes and deleted a node because of the (mis)placement of the Delete button at top-right of the edit screen. How IN THE WORLD could ANYONE think it's a good idea to put that Delete button in that spot. Just like that, 10 yr old node gone forever! (n)
 
It requires confirmation to delete a node.

It isn't possible to delete it with a single click of that button.
Understood. Leave it to me to do just that and no doubt many others over the years. That Delete button is logically where a Confirm button would be. I just lost some very valuable resources.
 
I just want to suggest considering making a "soft-delete" version of deletion for nodes, maybe like a recycling bin that holds onto nodes for 30 days.

The scariest part of the admin panel to me is that a node, and every single thread within it, can be completely deleted with two clicks. Sure, backups are there for restoring, but it's a big process to restore and the restoration might still mean losing posts that were made after the backup point. And I could imagine a possible situation where the wrong node gets deleted mistakenly, even with the confirmation dialog, and it's not noticed until much later.

I understand if this isn't feasible. But in case it is, I just wanted to say that it seems like it's too easy to lose a huge amount of data, and I would welcome a feature that makes that risk less likely.

Edit: Also, a related suggestion would be to email every super-admin when a node is deleted, in the same way emails are sent out when an API key is generated. Considering the potential for significant data loss, I think it makes sense that all admins are quickly informed, just in case it was a mistake, so the restoration can happen quickly.
 
Last edited:
Back
Top Bottom