Correct, we do not show the last photo and this is a known issue which has no solution at this time (this has been covered several times in the forums).
In order to use a single query to get the member listing we use the GROUP BY which does not allow us to sort the date for the last photo uploaded. However, prior to this an additional query for every user displayed was required - which meant alot of queries per page.
We do not have a solution as yet to do both a single query and get the last photo.
Please do not PM me for support or sales questions. Thank you for your understanding.
If I understand the code correctly, you have all userids after the query has been performed. Couldn't you use a second query then using WHERE userid IN (userid1,userid2,userid3,userid4,...) to get the last photo for each user.
With grabbing the userid and bigimage fields from the database, you get all information needed to map the fotos to the correct user. This would only add one additional query per page which uses an existing index.
How is the possible quick solution for this one coming along? This is one that causes a LOT of flailing with our users... both from the aspect of complaints and "reported as a bug"... and from the aspect of user satisfaction. They really seem to like seeing their latest photo thumbnail up on the page.
As Michael says here ... "It's a trade-off" ... ( which has the same irritable sensation of a bug bite )
"It's an issue of efficency; in the prior version of PhotoPost we did the main query and then if you were viewing thumbnails a second query for each member being displayed to find the latest thumbnail. This means that the showmembers page with 30 members would result in 30 additional queries per page. Using the method, we save the 30 queries, but loose the last photo uploaded thumbnail. It's a trade-off.
MySQL does support sorting columns during the GROUPing of records, by grouping the records from the photos table, we save any processing of members who have no photos at all."
On a user perspective, this is a very big trade-off because it affects the front door to their gallery of pics.
Am I correct to presume that this was a trade-off for providing the Group by Member / Sort by Feature?
Or was the show last photo feature going to be removed anyway to improve performance?
I understand, Chuck, that you don't consider this a bug support issue, so would you be so would you be so kind as to move it to the Discussion or Suggestions Forum?
I get this creepy pestering feeling replying to a 'Not a Bug' Thread in the Bug Forum
Well, I'm not in the position to say if it's a bug or not. What I can say is that in prior version the last uploaded photo has been showed in this column. That's why the column header says "last uploaded photo". So the expected behaviour is exactly that.
If your intention was to change the behaviour of the software, please just communicate that and rename the column heading to something like "random photo".
Considering the fact that this changed behaviour wasn't mentioned in the release information and reading Michael's post in this thread, I got the impression that he
classifies this as a bug (with status OPEN), but hasn't come up with a appropriate solution yet. That's why a suggested a possible solution that only adds one extra query.
So I'd really appreciate a reply from the lead developer that clarifies the situation so that everyone knows if that issue will be tackled or not.
MJM trade off,efficiency, speed whatever Essentially he is saying that with the efficient code that he can not grab the last photo since you can't sort within a group by mysql statement. He decided not to run 30 additional queries per page and that is the trade off he is referring to. If it is decided it is in the best interest of the program to go in a direction to improve speed and it is suppose to be coded this way then it is not considered a bug.