So I’m currently cooking together a mod for a game that logs player stats into two files. These files get automatically transferred from the game server to the web server, where I then parse and render the stats into a functional leaderboard table.
Now here’s where I need some brains: I wanna implement a seasonal system — each season lasting 3 months. The stats files get updated daily, but once a season ends, both files should be archived (e.g., dumped into a /Seasons directory with a timestamp or name like season_spring_2025.json or similar).
Archived seasons should then also be accessible and viewable via a collapsible section in the frontend (like an accordion view of past leaderboards).
So the real question is:
What kind of PHP logic or structure would you recommend for managing these seasonal transitions, file rotations, and dynamic rendering of archived leaderboards?
Would you go full OOP? Use a cron job for rotation? Database vs flat file indexing? Curious to hear how you’d architect this.
The heck is that supposed to mean in this context. How is that relevant to the rotation of files?
Yes. Because PHP is transactional based on a user’s requests, not based on time.
Personal choice. I would probably do it in a database because then I can crossreference easily using the database’s memory allocation to load data as-need vs loading entire files into PHP’s memory. But it may depend on what your end goal with the data is, what your database limitations are, etc.
Two main .txt files are constantly being updated with new statistics on the game server. A Bash script uploads these two files every hour to the web server, into a specific folder. From there, the main PHP script on the web server parses the data from these .txt files. I made sure that the entire files are not loaded into RAM to keep it resource-efficient.
My idea is to write a PHP script that runs via a cronjob on the web server every three months, archiving these two files into a Seasons folder. The archived stats will then be displayed in a collapsible section beneath the main leaderboard table.
Full “OOP” in this context means structuring my PHP code with classes like StatFile, Season, and SeasonManager to handle loading stats, archiving them after 3 months, and rendering leaderboards, all cleanly separated.
File rotation (moving JSON files) would still be done via a cron job, but OOP keeps the logic modular, testable, and easier to scale (e.g. adding filters, storing season metadata in DB later), it’s about clean architecture, not just moving files…
I understand your point about using a database, and I would actually like to use one eventually, but since this project is intended more as a “DLC” for a larger game server mod, I want to keep it as simple as possible, users should only need to configure the correct folder paths in a config file.
Perhaps in the future, when more statistics are available from the log files, i can consider using a database, but for now, I want to keep everything as lightweight and simple as possible.
So…if you’ve already decided to use OOP (which is still entirely irrelevant to what you do to the files), and you’ve already decided to use a cron job, and you’ve already decided not to use a database…
What was the point of the thread?
You seem to have started with a “question”, and then decided you dont care what people respond with, you’re gonna do it your way. So… good luck, and good bye?