I can't find it acknowledged or discussed in
https://www.phpbb.com/support/docs/en/3 ... -reparser/ or
https://area51.phpbb.com/docs/dev/3.2.x ... t-reparser, and if there is an existing topic discussion of this, my search didn't expose it. So if its already written somewhere, hopefully not something too obvious that I'm overlooking.
After encountering the bbcode.php failures on my updated 3.2.2 board, I've now manually ran "bin/phpbbcli.php reparser:reparse --ansi" and reparsed all the various locations of BBCode use successfully on my upgraded 3.2.2 board. From a BBCode perspective, everything is fine now.
Now that I've done that, do I need to "disable" the cron job created during upgrade that is "also" reparsing my messages? i.e. The reparse processing that occurs 100 messages at a time whenever a visitor hits the site, after 3600 seconds have elapsed since the cron was last allowed to hijack the connection process. (As described in
viewtopic.php?f=556&t=2410541&p=1467084 ... #p14670841.)
Or does manually running the reparse from CLI already update or disable something that ensures this cron task will never run again? Clearly the CLI reparse already did the actual reparse
work; but that doesn't mean the cron task isn't also still trying to do the same work, until the cron task knows he too has visited all 45000+ messages that the CLI already reparsed.
The reason I ask is that I'm still seeing a periodic 3 to 5 second delay when I first access the new 3.2.2 board. (When the 3.0.14 board runs on this same host, no such delay is apparent.) Once I've observed the delay, I don't see the delay again until "I'm done and come back some time later." I've tested turning off the "Check IP against DNS Blackhole List" but that didn't get rid of the delay, and I'm already using an unmodified proSilver theme when seeing this delay.
Once the reparse issue was pointed out to me, then it made sense that perhaps this "periodic delay" is the cron process still going through my messages 100 at a time each time someone connects, once every 3600 seconds. Simply running the CLI reparse hasn't stopped the delay; but I'm wondering if that's because I explicitly need to disable the reparse cron task from thinking it's responsible to continue walking the messages?
Thanks. -Trench