Reported posts are not creating threads at all.

[conqsoft]

It's strange that you and Paul_M are having issues, and he's the one that wrote that hack, so I'm pretty sure he had it installed also.

[Mark.B]

It's strange that you and Paul_M are having issues, and he's the one that wrote that hack, so I'm pretty sure he had it installed also.

Different Paul M.

The author of the hack is Paul M. the poster with the problem with it is Paul_M.

[InfidelMatt]

I don't think it has to do with that old hack. It was one of the most installed, yet we seem to be the only two with the issue.

I just don't see how the same report.php and same default template would write properly on my test board but not my live board. Are there any other components to writing the report thread I'm not aware of?



Matt

[Steve Machol]

It stands to reason that if it works in a fresh install and not in your current vB, then something changed in the vB to cause this. If you have reuploaded all the original files and disabled your plugins, then the only other logical explanation is a dataqbase change is causing this problem. I suggest comparing the db tables and field to the fresh install it see if you can find out what changed.

Also I'd be very surprised if that hack made no changes to the database.

[Paul_M]

It wasn't me who wrote the hack, it was the "other" Paul M (gets confusing), I'm MINI2 on vbulletin.org.

I'll check my database and see if it's different, I hadn't considered that. Because, as you say, with all plugins and hooks disabled and fresh vBulletin files it should work, but it doesn't.

[Mark.B]

I have this problem too actually.

This hack definitely contains no database changes, it is just an XML file which I have checked.

I cannot see anything that would cause this. Disabling plugins and restoring default files should fix it, but it doesn't.

The thread is created but no corresponding post is created, so if you click on it you get an invalid thread error.

[Colin F]

It also uses the post datamanager, so possibly something is conflicting there.

[Mark.B]

Thanks Colin.

Troubleshooting that is a bit beyond me, so I have posted in the hack thread on vbulletin.org pointing out this issue, hopefully someone will pop along in due course and suggest something.

In the meantime, for those stuck without a report-to-thread system, simply reinstall the old hack, it works fine on 3.6. In the infraction and reporting options, set the reporting forum to nothing, but ENABLE emails or else the report buttons won't show up.

Infraction reports are unaffected by any of this.

Not ideal but a suitable workaround.

[InfidelMatt]

I've checked my database and the big difference I can see is that the new field reportthreadid on the post table is NULL on the upgraded boards whereas it is unsigned, not null, default 0 on the fresh installed boards. Because I run a large board I had to add the fields using SSH instead of the script, but I doubt this is the cause of the problems. I am currently changing the field to not null default 0 unsigned and will let you know how it goes.

Matt

[InfidelMatt]

It also uses the post datamanager, so possibly something is conflicting there.

But there wouldn't be any conflicts if the product was completely uninstalled, would there (I uninstalled mine before upgrading as I had no more use for it)?

Matt

[conqsoft]

Mine is an upgraded board and it works fine for me though.

[InfidelMatt]

I fixed it!

That was the issue: reportthreadid needs to be unsigned, not null, default 0 instead of NULL.

Matt

[Steve Machol]

Nice investigative work.

[Mark.B]

Excellent Matt thanks. This fix worked for me too.

I am, however, intrigued to know how this happened.

I can't see how this can be a result of Paul's reported post hack since it doesn't go near the database.

Is the upgrade script missing something out? Or did MY upgrade script miss something out due to following those instructions for altering the post table in SSH?

[InfidelMatt]

Excellent Matt thanks. This fix worked for me too.

I am, however, intrigued to know how this happened.

I can't see how this can be a result of Paul's reported post hack since it doesn't go near the database.

Is the upgrade script missing something out? Or did MY upgrade script miss something out due to following those instructions for altering the post table in SSH?

If you used the raw queries as presented by Andreas, it loaded field defaults which were somehow different than the defaults loaded in the official upgrade script.

I wouldn't be surprised if more 'big boards' that processed the queries directly have this same issue in the days to come.

Matt