phpBB 3.2 Discussion

[code reader]

I don't think there is going to be any other Soft Delete mod...unless it is a really simple one. It is quite difficult to make a soft delete mod for phpBB3 and keep everything working correctly.

actually, i am almost sure there is a way to do it which is much simpler (and, imo, make more sense) than the way you describe, which is adding a new "deleted" field to the posts table.
what i mean is to latch onto the "approved" field, and extend its meaning.
since all the queries that are used to display posts to users already use this field, it should be not-so-difficult to extend its possible values from "approved"/"wait approval" to "approved"/"wait approval"/"soft-deleted".
this way, the total number of required changes should be dramatically reduced, and (almost) all the changes required are actually ones that deal directly with the soft delete feature, saving you dozens of changes that are needed just to prevent the display of a soft-deleted-post when you implement it by adding a new field.

[Prince of area51]

Good Gosh code reader, that is a brilliant idea!

[EXreaction]

I don't think there is going to be any other Soft Delete mod...unless it is a really simple one. It is quite difficult to make a soft delete mod for phpBB3 and keep everything working correctly.

actually, i am almost sure there is a way to do it which is much simpler (and, imo, make more sense) than the way you describe, which is adding a new "deleted" field to the posts table.
what i mean is to latch onto the "approved" field, and extend its meaning.
since all the queries that are used to display posts to users already use this field, it should be not-so-difficult to extend its possible values from "approved"/"wait approval" to "approved"/"wait approval"/"soft-deleted".
this way, the total number of required changes should be dramatically reduced, and (almost) all the changes required are actually ones that deal directly with the soft delete feature, saving you dozens of changes that are needed just to prevent the display of a soft-deleted-post when you implement it by adding a new field.

Actually, that could work pretty well, but now that the mod is working I do not want to mess with it again, at least right now.

[A_Jelly_Doughnut]

EXReaction: Like I said on phpBB Weekly Saturday (in response to your question), it is probably better for a MOD to add an additional column. code reader is right -- modifying the post_approved column would result in fewer code changes, but _could_ cause problems down the road (i.e. upgrading)

[statm1]

To bad the podcast was lost.. I was really looking forward to listening to it. As I wasnt around to listen to it live.. But, I know mistakes happen.

[EXreaction]

Sorry, I don't know what you said on phpBB Weekly for #47. I missed the live broadcast and it still has not been released for listening/downloading:
http://www.talkshoe.com/talkshoe/web/ta ... 418&cmd=tc



EDIT: Oh, the podcast was lost? That sucks.

[statm1]

Yep look here EXreaction: http://startrekguide.com/community/view ... 954d768ca8

[code reader]

EXReaction: Like I said on phpBB Weekly Saturday (in response to your question), it is probably better for a MOD to add an additional column. code reader is right -- modifying the post_approved column would result in fewer code changes, but _could_ cause problems down the road (i.e. upgrading)

the thing is this: if you add a column, it pretty much guarantee that this mod will not work with any other mod that queries the posts table. otoh, if you extend the definition of the post_approve, you pretty much guarantee that it will work fine with any other mod, because any mod that wants to query and use the posts table *needs* to look at the post_approve flag.
if you think about the meaning of these two states (unapproved post and soft-deleted post), you'll realize that they are almost (but not quite...) identical: they both denote a post which reside in the db, but should not be displayed or counted. once you realize this, it is almost obvious that using this flag is the only logical way to implement soft delete, or any other feature that controls the "displayability" of a post without removing it from the db.

my original point, though, was that i didn't think an alternative "soft delete" mod was as unlikely as extreaction seems to think.

[naderman]

Heh actually we thought about adding soft delete as a feature to 3.0 during one of the first betas using that approved field. However that still was too much of a change then. I think the current idea for implementing it in 3.2 is actually still to extend the meaning of that field.

[EXreaction]

I think if it were to be integrated into phpBB3 it should use a separate field. You can do it like I have mine where 0 means it is not deleted, otherwise it is the user_id of whoever deleted it (so you would not need a separate field to record who deleted it). Also a deleted time and deleted reason field would be nice.

If you guys cleaned up the functions for copying/merging/etc for topics/posts it would be much better IMHO. The way it is now, you have it setting up an array with the topic data you want to copy over, which works fine for an unedited schema, but not otherwise. If you changed that to just use the entire row and empty or reset the fields you need to change it would handle all of that automatically.