Serendipity Forums

I've just done a host of posts for August ( been away to post them when I got back ).

I'm using the assign multiple categories plug and I've added all these with 2 Categories but the entry count next in the archive section is counting the entry twice, once for each category assigned.

Have I the plugins running in the wrong order or is this actually a bug?

www.gojamboree.org.uk/blog

Hi!

Yes, this sadly is a bug in the archives sidebar plugin. It was already reported in the german section (http://www.s9y.org/forums/viewtopic.php?t=6056) - but I'm currently clueless as to how to fix it, as the complex SQL query is hard to get the count right for all 3 Databases we support and fitting them into one single query. :-/

Best regards,
Garvin

Do you have a look at http://www.s9y.org/forums/viewtopic.php ... c&start=15 ?

I glanced at this yesterday whilst waiting for a reply on my bug and istm the problem is that the archives code does a $serendipity['GET']['category'] before doing the count, which afaict isn't neccesary. (I think this causes the join to categories which you shouldn't really ever want to do in the archives plugin) So maybe just removing that bit would be enough? I didn't actually test this or anything, but might be worth investigating.

I think, that is wanted:

When you go to a category, the archive is supposed to to show only the articles of the choosen category.

Ah yes, I was thinking at the time I looked at the code some type of if statement was warrented but couldn't remember when I posted that comment. So maybe it needs to test "if category selected then $serendipity['GET']['category'] " else do nothing. Would be a simple change to test out anyway.

Could you not just have it go something like this?

sort order timestamp

find ( first timestamp in august )

for ( first entry in august to last entry ) {
increment archive total + 1
}

Surely it doesn't matter about the categories as the archive section is all about the number of entries between the beginning of 1 month and the next?

I'm sorry if you think I'mbeing pushy.

Hi!

Sadly SQL doesn't work like that.

We would need to fetch ALL rows just to get the total count with your prosposed algorithm, which would vastly decrease performance.

Best regards,
Garvin