Modernize event system: drop deprecated `cboxpost`, keep `user_chatbox_post_created

[Jimmi08]

Background

The plugin currently triggers two events when a message is posted
(chatbox_menu.php, lines 123–125):

$e_event->trigger('cboxpost', $edata_cb); // deprecated
e107::getEvent()->trigger('user_chatbox_post_created', $edata_cb);

This is a half-finished migration inherited from the upstream chatbox_menu
plugin. The new event name user_chatbox_post_created follows e107's
event naming convention (user_<plugin>_<thing>_<verb_past> for
user-initiated actions, admin_<plugin>_<thing>_<verb_past> for
admin-initiated actions). The trigger site was updated, but e_notify.php
still registers the old cboxpost name as the canonical event, so the new
event was never reachable through the admin Notify UI.

Decision

Single canonical event, drop the deprecated alias.

• Keep: user_chatbox_post_created
• Remove: cboxpost

Why hard break

The README is clear that this fork is a clean break, not a drop-in
replacement ("It is intended for new installs only and shares no markup,
class names, or upgrade path with the original chatbox_menu plugin").
Maintaining cboxpost as a deprecated alias adds noise for no real
benefit: listeners on the original chatbox_menu plugin are bound to that
plugin's namespace, and existing notify configurations from the old plugin
do not carry over.

Changes

chatbox_menu.php

Replace the two trigger() calls with the canonical one:

e107::getEvent()->trigger('user_chatbox_post_created', $edata_cb);

Also drop the global $e_event; declaration earlier in the function — the
modern e107::getEvent() accessor is already used on the next line, so the
older global variable is redundant.

e_notify.php

• Remove the commented-out legacy notify_cboxpost() function block
  (~10 lines of dead code at the top of the file).
• Update the config() registration:

  $config[] = array(
      'name'     => NT_LAN_CB_2,
      'function' => "user_chatbox_post_created",
      'category' => ''
  );

• Rename the handler method cboxpost($data) to
  user_chatbox_post_created($data).
• Update the $this->send('cboxpost', ...) call inside that method to
  $this->send('user_chatbox_post_created', ...).

Database side effect

Existing installs may have a stale cboxpost entry in notify_prefs from
the original chatbox_menu plugin. After this change, that entry becomes
dormant (nothing triggers cboxpost anymore) and is no longer
configurable through the admin UI. The new user_chatbox_post_created
event will register cleanly on next visit to the admin Notify page.

Users can either ignore the dormant cboxpost entry or remove it manually
from notify_prefs. This migration noise affects only sites that
previously had chatbox_menu installed; fresh installs are unaffected.

Out of scope (follow-up issues)

These belong in their own tickets but are worth noting now so the picture
of the plugin's event surface is documented:

• Admin moderation events: chat.php provides moderation controls
  (delete / block / unblock messages) that currently do not trigger any
  events. Following the same convention, these would become
  admin_chatbox_post_deleted, admin_chatbox_post_blocked, and
  admin_chatbox_post_unblocked. Useful for audit logging, statistics, or
  notifying users that their post was moderated.
• Notify message body cleanup: the NT_LAN_CB_* constants and the HTML
  inside the notify message body can be revisited as part of the broader
  markup cleanup pass.

Related

This issue surfaced while testing #N (template system split). A stale
notify_prefs entry referencing the original chatbox_menu_notify class
caused fatal errors on message post. The class lookup error is a separate
e107 core robustness issue (filed upstream: [link to e107inc/e107 issue
once created]) — even after this rename, e107 should not fatal when a
notify handler points at a missing class.

Verification

After the rename:

• Posting a message must not fatal.
• The user_chatbox_post_created event appears in the Notify admin
  configurable list.
• Test event from the Notify admin page fires successfully.
• A handler registered via e_event.php → register('user_chatbox_post_created', ...)
  in another plugin receives the event.

[Jimmi08]

Files changed

• chatbox_menu.php — removed deprecated $e_event->trigger('cboxpost', ...)
  call. The canonical e107::getEvent()->trigger('user_chatbox_post_created', ...)
  call (already present immediately after) is now the only event fired on
  message post. Also removed $e_event from the global declaration on
  line 22 since it has no remaining uses in the file.
• e_notify.php — full cleanup:
  • Removed the commented-out legacy notify_cboxpost() function block
    (~10 lines of dead code at the top of the file, present from the
    upstream chatbox_menu plugin).
  • Removed the // v2.x Standard comment, which no longer contrasts with
    anything after the legacy block was deleted.
  • Renamed the config() registration's 'function' value from
    "cboxpost" to "user_chatbox_post_created".
  • Renamed the handler method cboxpost($data) to
    user_chatbox_post_created($data).
  • Updated the $this->send('cboxpost', ...) call inside the handler to
    $this->send('user_chatbox_post_created', ...).

Behavior

Posting a message now fires a single event (user_chatbox_post_created)
instead of two (the old cboxpost plus the new name). The single event is
the one that was already wired through e_notify.php → config() under a
mismatched name, so this PR completes a half-finished migration inherited
from upstream rather than introducing a new event name.

Migration note for existing installs

Sites that previously had the original chatbox_menu plugin installed may
have a stale cboxpost entry in their notify_prefs row in the
e107_core table. After this change, that entry becomes dormant — nothing
triggers cboxpost anymore — and is no longer configurable through the
admin Notify UI. The new user_chatbox_post_created event registers
cleanly on next visit to Admin → Users → Notify.

The dormant entry is harmless and can be ignored, or removed manually from
the serialized array in notify_prefs. Fresh installs are unaffected.

A separate upstream issue ([link]) covers the broader robustness problem:
e107 should not fatal when a notify_prefs entry references a missing
class. That fix is independent of this PR.

Verification

• Post a message — no fatal, message stored, event fires once.
• Admin → Users → Notify — the user_chatbox_post_created event appears
  in the configurable list with the NT_LAN_CB_2 label.
• Admin → Users → Notify → Test button on the new event — handler runs,
  test notification sends successfully.
• Sidebar widget renders identically in both cb_layer === 1 and
  cb_layer === 2 modes.
• Standalone chat.php page renders identically.

Out of scope

• Admin moderation events. chat.php provides delete / block / unblock
  controls that currently fire no events. Following the same naming
  convention, these would become admin_chatbox_post_deleted,
  admin_chatbox_post_blocked, admin_chatbox_post_unblocked. Useful for
  audit logging or notifying users of moderation actions on their posts.
  Tracked separately.
• Notify message body cleanup. The NT_LAN_CB_* constants and the
  HTML inside the notify message body are part of the broader markup pass.
• Legacy globals. The remaining global $e107cache, $e107; and
  global $pref, $tp; declarations in chatbox_menu.php are tracked in
  a separate cleanup issue.