V14.0.0 - Quick background: Notifications UI was spinning slow on load. Found cron spamming this fatal every minute:

PHP Fatal error: Uncaught Error: Call to a member function send() on bool 

in modules/boonex/notifications/classes/BxNtfsModule.php:702

Stack trace:

#0 /modules/boonex/notifications/classes/BxNtfsCronQueue.php(39): BxNtfsModule->sendNotificationPush()

#1 /periodic/cron.php(121): BxNtfsCronQueue->processing()

Root cause confirmed (line 702 in  sendNotificationPush()):

// PROBLEM: Static call assumes getObjectInstance() always returns object

return BxDolPush::getObjectInstance()->send($iProfile, array(...));

BxDolPush::getObjectInstance() returns false (push not configured), but code calls ->send() anyway.

Live server — haven't applied any fixes yet. Need confirmation before touching.

$sSubject = !empty($aSettings['subject']) ? $aSettings['subject'] : _t('_bx_ntfs_push_new_event_subject', getParam('site_title'));

// Defensive check added:

$oPush = BxDolPush::getObjectInstance();

if (!$oPush) {

  return false; // Skip push gracefully when disabled/unconfigured

}

return $oPush->send($iProfile, array( // Now safe

  'contents' => array('en' => $aContent['message']),

  'headings' => array('en' => $sSubject),

  'url' => $aContent['url'],

  'icon' => $aContent['icon']

), true);

-------

Site impact: Load dropped 5+ → 1.2, notifications load instantly, no more hidden cron CPU spam.

Questions for UNA team/community:

  1. Do the v14 patches (showing in App Store > Updates) include this exact fix? Safe to apply with custom mods ( , reactions, etc.)?
  2. Proper way to fully disable push notifications so this code path never triggers? (Studio setting? DB flag?)
  3. Anyone seen this after optimizations or v14 patch mismatches? Vaguely remember thread mentioning notifications.

Server: VPS, UNA v14, PHP 8.2, heavy traffic (timeline/reactions spam in logs).

Appreciate any insights before applying patches

Regards Chris

php
  • View
    134
  • More
Replies (12)

    • These updates are sitting in the AppStore under Updates: The server runs on V14.0.0. and I believe that any updates in the AppStore relates to patches for that version running currently for the server. It's a very busy site and one would rather approach with caution ...image_transcoder.php?o=sys_images_editor&h=3036&dpx=1&t=1773913742

      • Hello @Chris Andre Buys !

        First of all, there is no the Notifications app in the module's list which you shown. I guess your error relates to the situation when the Notifications part has been exported to the non-Profiles area. Could you remember such modifications please?

        • Hey @LeonidS

          This is going to sound funny... was my thoughts too.. but thought I could have missed something.

          What you are saying relates to custom work and if so, means that even if I run the updates in AppStore it won't make a difference unless the custom work gets update..

          Please confirm if I followed you correctly.. and thanks for prompt response Leon.

          • The above reply from me can be dismissed, for I now better understand why you refer to it as custom work @LeonidS

            I run a complete analysis and found that it has nothing to do with custom work, also an old issue, but only started to show when volumes escalated from 18 March 2026, when the server really picked up on traffic(more site visitors) 

            Logs indicate a few vital clues: The bx_ntfs_* tables are missing, and vanilla cron.php(hardcoded) runs BxNtfsCronQueue regardless, which is why we never really picked it up until the server got spiked hard by site users/visitors plus FPM Max_children(PHP).

            I have an idea but wanted to know from you first since it is a /boonex/notifications issue.

            (In simple english: Let's say the "Groups" module is problematic right. If I deactivate/uninstall and than delete it, so will all related users data be deleted. But there are times when we can save the "Groups" modules in other ways provided we are able etc.

            Now "Groups" holds on to some data that has business values whereas Notifications that can only be installed during the initial core installation , has no uninstall/reinstall so to speak and that the data in our case no data risks include, seemingly making not that difficult to fix the missing table.

            As for the hardcoded cron that is not checking the module status and simply run regardless, has contributed to the persistent and escalated growth in PFM max_childrens. (But to add, looking from our audit report in studio, is our periodic cronsjobs that run on intervals, up to date as planned and configured, so don't think we've not setup any cronjobs)

            • Well, the good app removes all connected data (yes, in the sys_cron_jobs table too). And if somethings isn't good there with the scheduled tasks run you will be notified about PHP errors (you may check the error_logs too). Do you know the certain reason why all bx_ntfs_* tables have been removed? If the reason is only in the removed fields - then you may try to restore tables.

              • @Leonids thanks for your response man... much appreciated...

                To answer your question: I do not know the exact reason the bx_ntfs_* tables were removed. No deliberate uninstall of the Notifications module was performed on our end. The most likely candidate based on our timeline is a third-party module update applied around March 2025 — that is the only significant change we can trace that aligns with when the issue would have started silently, before traffic volumes escalated and exposed it on 18 March 2026.

                What we know for certain:

                • bx_ntfs_* tables: completely absent (SHOW TABLES LIKE 'bx_ntfs%' returns nothing)

                • sys_cron_jobs: no ntfs entries

                • modules/boonex/notifications/install/sql/: empty — no schema files present

                • Module files: intact and current (Jun 2025)

                • periodic/cron.php line 121: hardcoded call runs regardless of module/table state

                Since the removal appears to be table-only with no data at risk, we are ready to proceed with a manual restore.

                Could you please advise:

                1. The correct source for the bx_ntfs_* table definitions in v14 (since install/sql/ is empty)? GitHub branch, core SQL file, or patch?

                2. Whether the sys_cron_jobs entries for notifications also need to be manually reinserted, and if so the correct values?

                3. Whether the AppStore updates currently showing are safe to apply on our v14 site — or should schema restore come first?

                We have a full snapshot ready and the cron comment fix staged but not yet applied to production. Standing by for your guidance before touching anything.

                Regards Chris

                • From this page https://unacms.com/download-product/notifications you may take the 14.0.8 version. The code for the Cron Jobs looks like

                  INSERT INTO `sys_cron_jobs` (`name`, `time`, `class`, `file`, `service_call`) VALUES
('bx_notifications_queue', '* * * * *', 'BxNtfsCronQueue', 'modules/boonex/notifications/classes/BxNtfsCronQueue.php', ''),
('bx_notifications_notify', '* * * * *', 'BxNtfsCronNotify', 'modules/boonex/notifications/classes/BxNtfsCronNotify.php', ''),
('bx_notifications_clean', '0 0 * * *', 'BxNtfsCronClean', 'modules/boonex/notifications/classes/BxNtfsCronClean.php', '');

                  • @LeonidS Brilliant!!!... Now take the rest of the week off lol... Thanks Bud 😉

                    • @LeonidS Just noticed that the download is for version 15.0.2 and wonder since our server is still running version 14.0.0. Got to make sure though... please confirm this for me.

                      • I thought it might be on github under 14.0.0 tag but no luck..

                        image_transcoder.php?o=sys_images_editor&h=3038&dpx=1&t=1774266510image_transcoder.php?o=sys_images_editor&h=3039&dpx=1&t=1774266546

                        • @LeonidS Wait... just wait there...

                          I ran log checks and guess what?

                          Clear status: Site stable, fatal 702 GONE naturally. No action needed yet.

                          Proof from logs:

                          image_transcoder.php?o=sys_images_editor&h=3043&dpx=1&t=1774268004

                          Cron running clean (every minute, no errors logged).​

                          Why fixed itself:

                          • Tables deleted properly (LeonidS correct).
                          • Cron queue empty → no spam.
                          • Load normalized (warnings < warnings).

                          Manual cron test still fatal (hardcoded), but auto cron silent = site good

                          image_transcoder.php?o=sys_images_editor&h=3042&dpx=1&t=1774267912

                          Could you be right, because I had no idea when you said it. Gosh... that's new to me, but I like it.

                          • @LeonidS and community — closing update + what followed

                            Just want to close this thread properly as it turned into quite the learning experience and may help others on v14.

                            Quick recap of what happened:

                            The fatal 702 error resolved naturally exactly as LeonidS predicted — once the bx_ntfs_ tables were cleanly removed, the cron queue had nothing to process and the spam stopped on its own. Load normalised, notifications loaded instantly, no manual patching needed. Leon was right from the start. 😄

                            What we didn't expect:

                            The cron cleanup also wiped our var/sessions/ directory as collateral. This logged every single user out simultaneously. When they all logged back in at once, it exposed a completely separate pre-existing database issue — all Premium membership records in sys_acl_levels_members had an empty State field instead of State = 'active'. UNA silently ignores these records and falls back to Standard level, so every user suddenly showed Standard instead of Premium.

                            What I fixed:

                            • Recreated var/sessions with correct permissions → logins restored
                            • Fixed State = '' on all 1037 Premium membership records → State = 'active'
                            • Cleaned up expired Premium rows that were overriding valid ones
                            • Fixed profile ID mismatches where sys_accounts.profile_id pointed to a profile with no ACL row

                            Tip for other v14 admins:

                            If users suddenly show the wrong membership level after any module uninstall or cron cleanup, check sys_acl_levels_members. State first — an empty string silently breaks ACL lookups without throwing any errors. Easy to miss, painful when it hits at scale.

                            Thanks again @LeonidS for the fast and accurate diagnosis on the notifications side. Brilliant support as always. 🙏

                            Login or Join to comment.