PHP pagination without database: stupid?

Hi forums!

I am currently designing a website for a webcomic. This means I will be creating a new page for every comic I upload, and will be displaying the most recent one to visitors of my site. (one comic per page). I want to use some PHP pagination for my FIRST PREV NEXT LAST buttons and I wanted to ask for some smart opinions.

First: Is it possible to paginate all my comics WITHOUT a database. For example using arrays?
Second: With this pagination, would the most recently uploaded comic be shown each day as the default index/home page?
Third: Is this system still easily or regularly manageable as the number of comics increases everyday, supposedly into the hundreds as it continues?

I would love it if this was all possible without a database. Note that I am not concerned with the length or complexity of the code, only if it is both doable and not a disaster waiting to happen.

Thanks smart people! Looking good today, by the way!

May I ask why you don’t want to use a database?

First: Is it possible to paginate all my comics WITHOUT a database. For example using arrays?
Second: With this pagination, would the most recently uploaded comic be shown each day as the default index/home page?
Third: Is this system still easily or regularly manageable as the number of comics increases everyday, supposedly into the hundreds as it continues?

  1. Everything is possible (or almost :D). You could put all comics in a subfolder, get the content of that folder, order it by date (at least I think you can), display it.
    Advantage: you can upload comics to the subfolder without having to change the code.
    Disadvantage: you can’t show any additional info (an intro text or something) about the comic), unless you upload additional (text) files and write the code to manage those too.

If you want to use hardcoded arrays, you’ll have to change your code each day.

  1. See 1. Of course it would not be automatic, you’ll have to code it that way.

  2. What kind of management do you need?

You can put your comics inside filesystem and display them using php functions such as glob() and dir(). You can also sort files by date (created or modified date), again via php functions such as sort(). It is also possible to paginate the list of files. Just read all your files inside an array, and use the array_slice() function to return, say, item number 20-29. Its definitely possible.

UNIX filesystem should be able to handle hundreds of files, however I recommend that you use come kind of caching system. Say scan the directory once every 100 requests, read the file names (and date) into an array, serialize the array and store it in a text file. Use the text file for next 99 requests. Hope all of this makes sense.

Anyway, I’d still suggest that you use database. Database allows you to store metadata about your files as well, such as author, category, genre etc. Searching becomes more easier.

Thanks for all the info, this was both to find out if it was possible and to decide if it was better than using a database. I’ve made my decision based on your help, so thanks you guys!

here’s hoping that decision was to use a database, it is of course possible to manage this through the filesystem alone, but the idea of looping directories and creating text files just sounds like hard work to me.

You will find the database infinitely more convenient and scale friendly. Just store a pointer (ie. url path) to each uploaded file, store the upload date and anything else you want. Once it works you don’t have to concern yourself with the file system anymore.

P.S. regardless of which approach you go with it would be wise to group comics into some kind of folder system, whether its by date or by the auto incrementing database ID.

For what it’s worth. In my own home-rolled system I use the file system for as many div contents as possible. That makes it a lot easier to edit div fragments–with perl, sed and the keyboard directly.

I do use mysql on top of that, for metadata searching. But not for individual div contents. Layouts are defined by an XML file, where each XML element maps to a <div id=“whatever”> in the layout. Each XML element also specifies a div source, which is either “file” or “plugin_name”

No annoying and hard-to-re-arrange *.tpl template files. Most editing comes straight from the ssh keyboard, rather than a really annoying tinyMCE form.

That sounds horrible. It sounds like you’ve created something really difficult to edit and expand upon. I bet it’s a nightmare.

It’s lightning fast and oh so easy to change layouts. To keep constant page contents, but to rearrange the layout I edit an XML file…and a bit of CSS. I can do top-to-bottom remodeling without changing code. I use PHP plucene for metadata actually, and not mysql.

Mapping contents to a div blueprint defined in XML keeps things predictable. If I want to change something I know exactly where to look. Smarty template *.tpl files can be created in PHP codes anywhere, at any not so predictable level. Debugging and/or rearranging layouts with typical templating languages is horrible. And they do not separate content from logic. They just shift it around and obfuscate it.