Comment to 'Pruning but with other content types : Delete post after expired period'
  • UPDATE: Expert Review Request – Timeline Cleanup Script Ready for Feedback!

    Happy New Year 2026 to the entire UNA community! 🎉 Wishing everyone a prosperous year ahead! ✨

    **Quick status:** Power outage + personal commitments delayed testing, but now **urgent** due to storage limits on a live production site. Currently restoring an old backup for staging.

    **What I need from UNACMS experts (@LeonidS @unateam @Developers App India @CluBDeveloper @AQB Soft @Jerome Mingo and @Andrey Yasko ):**

    **Does this approach look safe/sound for UNA 14?**

    Code Snipped --------------

    delete_old_timeline_posts.php is attached to this thread

    Key improvements

    • Dry-run mode: First run shows exactly what would be deleted without touching anything.

    Deployment steps

    text
    1. Save as /var/www/html/delete_old_timeline_posts.php
    2. chmod 755 /var/www/html/delete_old_timeline_posts.php
    3. touch /var/log/timeline_cleanup.log && chmod 666 /var/log/timeline_cleanup.log
    4. Test: php /var/www/html/delete_old_timeline_posts.php
       → Check log for "dryRun: YES" results
    5. If good: edit $dryRun = false; and $daysOld = 14;
    6. Add cron: 0 3 * * * /usr/bin/php /var/www/html/delete_old_timeline_posts.php >/dev/null 2>&1
    7. Monitor logs for 7 days
    8. Then: $daysOld = 60;
    

    Quick checks before running

    Run these on your DB to preview:

    sql
    -- How many old posts?
    SELECT COUNT(*) FROM bx_timeline_events WHERE type='post' AND date < UNIX_TIMESTAMP() - (86400*14);
    
    -- Sample old posts
    SELECT id, owner_id, object_id FROM bx_timeline_events WHERE type='post' AND date < UNIX_TIMESTAMP() - (86400*14) LIMIT 5;
    
    -- Files linked to old events?
    SELECT COUNT(*) FROM bx_files_2_timeline ft JOIN bx_timeline_events e ON ft.timeline_id = e.id 
    WHERE e.type='post' AND e.date < UNIX_TIMESTAMP() - (86400*14);
    

    Cascading deletes: Handles comments (bx_timeline_cmts), notifications (bx_ntfs_*), and files (bx_files_2_timeline, bx_files).

    Per-event processing: Safer than bulk delete, logs each step.

    Comprehensive logging: Full audit trail in /var/log/timeline_cleanup.log.

    File cleanup: Removes DB entries for attached media (physical files need storage module cleanup if not automatic).

    **Key questions:**

    1. Will deleting old `bx_timeline_events` (type='post') cascade properly to related tables? (`bx_timeline_cmts`, `bx_ntfs_*`, `bx_files_2_timeline` / `bx_files`)

    2. Any hidden dependencies or modules that recreate timeline entries?

    3. File storage: Does UNA auto-delete physical files when `bx_files` rows are removed, or do we need extra hooks?

    4. Better way via Studio app / API / cron service?

    **My plan:**

    1. Test dry-run on staging (old backup) → share results

    2. Live: Phase 1 (14 days), monitor 7 days → Phase 2 (60 days)

    3. Cron: daily 03:00 with lock/logging

    **Goal:** Safe auto-pruning of timeline posts >60 days to control disk growth.

    Your expert eyes would save weeks of trial/error! 🙏