I did a line-by-line review of the code changes for the mod. It was written for phpBB version 3.0.7 and Ted is running 3.0.11 here, so only a very minor update difference. It duplicates existing code lines (biggest change being in the 'set_priority' case statement) and changes some text strings to provide an admin entry box for the priority level. The only 'unsafe' element to the mod is the UPDATE statement to modify the database, but that is hard-coded to only update the new 'topic_priority' field and has been properly cast to prevent injection hacks, so I consider it to be 100% as safe as the core phpBB code.William12 wrote:What evidence do you have of that?"The 'other mod' is 100% stable (at least as much as the core code is stable)."
This is such a minor mod that it does not require ongoing support (the version of phpBB hasn't changed significantly since the mod was written). It is what it is. Yes, if Ted upgrades to phpBB version 4 at some future date, it will need to be reviewed before re-adding the mod, but that's a long way off yet (and it is such a minor mod that updating it to match future core changes would also be a minor task).William12 wrote:It is simply a contribution by a community member and it is explicitly Not supported
Agreed in general, but in this specific case the change is the introduction of one field in one table. Ted already has the systems backed up, and I'd expect the person making changes to take backups anyway if they're trusted to have this level of access to the system.William12 wrote:Having done a ton of production system DB work, the biggest red flag to me is any changes in DB Schema. That takes a very high bar to me. Schema changes are a big deal, now and in the future, and should never be done lightly.
Totally agree with that.William12 wrote:Especially if you can find a solution that does not require it, I would look there first.
Your suggestion of a mod that just changes the date of the topic is interesting (assuming Ted isn't interested in retaining the original date) - but, unless you have found a better solution (I'm possibly wrongly assuming you are thinking along the lines of using the last_modified date as an 'order' mechanism by manually setting dates to force the display order of topics), the main problem I forsee is that it would have to be re-applied every time someone posts to the topic, and be re-applied to a specified sub-set of topics rather than all. This requires an admin interface to choose which ones should be updated and a re-write of the post storage code to force the date changes - which introduces additional unnecessary overhead every time a post is created. The overhead is minor, but it is added to every new post created which makes it less than minor. At least Topic Cement causes no additional overhead.
There's rather a lot of scaremongering here for no reason. Topic Cement introduces one new field which only contains data relating to itself. This field can be ignored or deleted at an point (no difficulty in 'rewinding') without any detriment to the existing system, and certainly doesn't need a 'ton of import/export work'.William12 wrote:For example, if you have to rewind a schema change back to default schema because of some issue six months down the road, then good luck rewinding it and migrating data back to old schema. Ton of import/export work and testing
I don't personally need the explanations, but I'm assuming you are doing what I am doing, which is talking to the wider readership rather than just between us 'developers'.William12 wrote:I could say take my word for it, but don't have time to explain all the reasons and learning's over the years right now.
Have you the time to put it on your phpBB test site so Ted can see it in action?William12 wrote:This is not all or nothing. Trying the change and testing it is the lowest risk option at this point with what we know. If it does not deliver what is needed, he always has the option to go with another Mod.