Theme compatibility and problem with 'get_adjacent_post()' function

[GDragoN]

Some themes (including many default Twenty* themes) show adjacent links to all posts, and in theme compatibility mode that breaks because function get_adjacent_post() expects post to have valid post_date. But, In theme compatibility mode, bbPress uses 'bbp_theme_compat_reset_post()' function and it sets post_date to 0.

Why is that done at all, when we can set post_date to proper post_date for the single topic, reply or forum we are generating compatibility post? Is there any concrete reason for why the post_date has to be 0 in theme compatibility mode or was it just some random decision not to set it?

I have attached the patch that adds date to theme compatibility reset for single topic, forum and reply.

[GDragoN]

Also, few months ago I have noticed some other issues (not just get_adjacent_post()) related to compatibility mode and the missing post_date.

[johnjamesjacoby]

Related to #3337.

I think it makes sense to correctly format datetime column values rather than have them simply be false. We could probably get away with 0000-00-00 00:00:00 because WordPress forced zero dates to be allowed in MySQL, but I do suspect this is going to go away someday, so perhaps Unix Epoch makes more sense, or maybe some other value.

[GDragoN]

Yeah, we can have '0000-00-00 00:00:00' instead of 0, but I think we should use the real dates when available (as my patch does) because there were some cases in the past that I noticed as a problem related to some other plugins.

[johnjamesjacoby]

Related: ​#WP46210.

See: ​https://bbpress.org/forums/topic/incorrect-datetime-value-0-error-when-viewing-new-forum/#post-211756

[johnjamesjacoby]

I think the issue with using "real dates" is that in some instances, like User Profile pages, there isn't a datetime value to guess from.

The only other potential regression I can imagine but cannot find happening, is anyplace something like:

empty( $post->post_date )

...might be used.

Thank you @GDragoN for the patch. I think I'm going to go a slightly different route. Would love if you'd be willing and able to check it out sometime soonish.

[GDragoN]

Yeah, this would be good. The filter can be used to return real date instead of the 0 date/time, because I think I remember some cases when such date/time also causes issues, I tried that at one point. Maybe the current date/time instead of zero by default would be better. But, this is a good solution.

[johnjamesjacoby]

In 7099:

Theme Compatibility: Avoid compatibility issues between MySQL versions.

This commit introduces a new function - bbp_get_empty_datetime() - which returns a valid, filterable, "empty" MySQL formatted datetime value.

This new function is used inside the theme compatibility API to ensure that global WP_Post datetime values are not "0" to better support MySQL 8 and higher, which is dropping support for NO_ZERO_DATES.

Props GDragoN.

In trunk, for 2.7.0.

See #3354.

[johnjamesjacoby]

In 7100:

Theme Compatibility: Avoid compatibility issues between MySQL versions.

This commit introduces a new function - bbp_get_empty_datetime() - which returns a valid, filterable, "empty" MySQL formatted datetime value.

This new function is used inside the theme compatibility API to ensure that global WP_Post datetime values are not "0" to better support MySQL 8 and higher, which is dropping support for NO_ZERO_DATES.

Props GDragoN.

In branches/2.6, for 2.6.6.

Fixes #3354.