I've been having a bit of trouble trying to work out the best approach to this and thought I might be able to get some advice here.
I'm building a portfolio. The portfolio needs to be set up such that the admin user can decide which portfolio items are visible on the front end, and in what order they appear.
The portfolio will have items added to it over time, but the front end will only display up to 4 items at once.
At first I was thinking I'd have a few extra columns on my portfolio table, such as
I then looked at creating a single view which would contain 4 select inputs (name="order"), each select containing a list of all the portfolio records. They could select them in the order they wanted and then I would take the POSTed array and loop through them, setting the ids posted to be visible and incrementing the order.
But then I realised that I'd need to reset older visible/order records before doing that, and suddenly I realised I'd be getting into a whole chunk of database queries.
So then I thought, well what if I just have a 'portfolio_ordering' table. That could just have one column which stored a serialised array of the preferred ordering. In fact it could just be one record which got overwritten any time the order/visibility was changed.
This sort of works, and when displaying on the front end I have to get the ordering/visibility record first before I can get the portfolio records. I was thinking I could just use whereIn, but then my ordering isn't carried through. So I'd need to approach that slightly differently.
Am I missing something very obvious? Is there a better way to do this? The first approach seems most logical for queries. It would allow something like
But then as far as I could see I'd end up with a messy situation when trying to update that data from the admin ordering/visibility form.
At the end of the day here, so perhaps the brain just isn't seeing clearly... any query efficient suggestions much appreciated!