Is this intentional?
If you have an unread PM notification in place, and you are opening a PM (any PM, no matter read / unread, no matter the notification is for that PM or not) your unread PM notification is not displayed. Visit any place, your PM notification is back.
Yep, it's intentional. This came up recently in a (lengthy!) discussion on one of my PRs on GitHub (
#3926). The issue is that the header, including PM notifications, is generated right at the start of processing, in global.php, whereas PM processing occurs later, and might make changes that affect that PM notification. As what I understand to be a bit of a quick-n-dirty "solution" to this problem, PM notifications are simply disabled for the private.php page - see towards the end of
line #846 of global.php:
if(isset($mybb->user['pmnotice']) && $mybb->user['pmnotice'] == 2 && $mybb->user['pms_unread'] > 0 && $mybb->settings['enablepms'] != 0 && $mybb->usergroup['canusepms'] != 0 && $mybb->usergroup['canview'] != 0 && ($current_page != "private.php" || $mybb->get_input('action') != "read"))
To explain the issue more clearly via an example: at the start of processing, in global.php, there might be an unread message, for which a PM notification message is generated in the header - but if the currently-loading page is a view of that message, then by the end of processing, the notification is no longer valid because the message has been read, and the header - in particular, its PM notification - is no longer valid.
Inspired by the discussion in my PR, a new issue (#3939) was created to discuss this sort of problem:
A function to (re)generate the header (/footer). TL;DR: this issue will be dealt with in 1.9.
Yes, it is a tricky way to "solve" a tricky issue. Hopefully it will get fixed properly in the future.
@laird, I made a thread / issue regarding this too (can't find now, probably closed), where I highlighted the mod notice for unapproved posts remains after approval and takes one more refresh to go away. This is pretty much related to what you have highlighted.
In my opinion, there is no need to (RE) generate header, the notifications need to be processed at the end in final page parse, where breadcrumb (<navigation>) and archive processed. Its very easy to implement in current MyBB version as well, but I didn't try to do that because of possible breakage of existing plugins only.
The issue I have mentioned here is not the same, its not about wiping the notification coz it returns back. The notice is just suppressed in a particular action (read) of private.php. As you said, if it is the view action, system should evaluate the PM notice is about the PM user is reading currently or not and act accordingly.
@effone, yep, there are two related issues here, one of which is a quick-n-dirty "solution" to the other.
Issue A: In certain situations, such as when reading an until-then-unread PM, or approving an until-then-unapproved post, notices in the header are shown "one last time" when they ought not to be, and only disappear on the subsequent page refresh. This is the issue you raise in
#3559, to which Ben has helpfully linked.
Issue B:
Because of - as a quick-n-dirty "solution" to - issue A above, PM notifications in the header are simply disabled so that they
never show when accessing the private messaging system (again, as I wrote, this occurs towards the end of
line #846 of global.php). This is the issue you are raising in this thread. So, yes, this issue B is intended behaviour in response to issue A. I believe that this issue B would be "resolved" by commenting out the condition
$current_page != "private.php" || in that line 846 of global.php which I've referenced. Anybody who wants to confirm that this issue B is a deliberate choice can do that for themselves.
And I agree with you: processing notifications (and the header) at the end of a request rather than at the beginning would be a simple way to solve issue A and avert the "need" for issue B, although as you point out, this might break plugins (which was a concern for @yuliu too in the discussion in my PR #3926).