Pruning but with other content types : Delete post after expired period

Want posts to auto-expire after X days (e.g. 30), then **prune/delete** automatically.

- Stories module uses `expires_at` field, auto-set on creation

- Add DateTime "expires_at" field via Studio > Forms for any content

- Pruning via UNA cron: delete where `expires_at < NOW()`

Proposed Pruning Function for other content types perhaps

web
web
web
  • View
    331
  • More
Replies (4)

    • Hello @Chris Andre Buys !

      Well, UNA already has the possibiltyi to delete inactive users with all theri content. I suggest that this auto-action may meet the questios from the active users with not so old, but deleted posts :-)

      • @LeonidS .. I honestly thought the response to this thread would only come somewhere in the new year, but my dear friend Leon is always on top of his game and ready to help. Please take a few days off and tell the @unateam they must dare say something to you… I’ll come over personally and give them all a big hug for making sure we’re covered even on Christmas Eve.

        Anyway Leon lol, hope it's okay for some love talk... My requirement is simple. Regardless user activeness or inactiveness do I just want posts to live 30 days as a means to go slow on increasing disk space given the nature of affairs. We get quite a number of media posted like video and images resulting in rapidly grow disk space. After carefully exam our options was this one by far the most feasible one. User place a post and also among many that soon become history and forgotten too, all the more reason to let it go.

        • Thank you for your warm words, dear @Chris Andre Buys ! Wish you all the best in coming 2026 too! About your request: well, it will require the custom work which will include:

          1) Add the option to the `sys_options` table for the posts pruning;

          2) Add the record to the `sys_cron_jobs` table with the name like 'bx_posts_pruning' to call there proper class one time per 24 hrs.

          3) The class BxPostsCronPrunning itself.

          The common way to reproduce steps and create own pruning file can be impressed by the Ads app example as it has such feature.

          • 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! 🙏

            delete_old_timeline_posts.php 4.3 KB
            Login or Join to comment.