Archive Plugin - observations

[Don Chambers]

1) I noticed the sidebar archives plugin, when showing entry totals for a time period, counts an entry for each category it is posted to... So, if I have a single entry in March 2008, but it is assigned to 3 different categories, the archive sidebar shows: March 2008 (3). While this behavior makes sense for the sidebar category plugin, I think it is misleading for the archive plugin.

2) Start from the homepage, select "older" from the archive sidebar plugin, and you get somewhere like here: http://blog.s9y.org/archive. The entry count for each month correctly reflects the total entries for that month, which is what you would expect. Again using that page as an example, let's say that in August 2007, which shows 6 total entries, 3 of those entries were marked as "hide from front page". Those "hidden" entries, though part of the month's total of 6, would not be viewable if you were to select "View Full" or "View topics". So, a visitor sees "hey, there are 6 topics for this month"... then navigates to the overview or topic listing for that month, they will now only see the 3 entries NOT marked as "hide from front page".

I'm not sure where I stand on this one because the archive pages are specific to the source of navigation. In other words, if I was viewing an overview page for "Category 5", then selected any link in the archive sidebar, the returned list of entries would be specific for just that category (ie, if I select August 2007 while looking at Category 5 overview, the returned entries would be just Category 5's entries in August 2007). If an entry is truly hidden from the frontpage, and I navigate to archive view, I suppose it makes sense that those hidden entries are not listed there. Regardless, I think something should be considered to clear up a potential visitors confusion for these entries hidden from the frontpage.

[garvinhicking]

Hi!

1.) Yes, this is a "flaw in the matrix". Counting entries in SQL with the table structure can't really be done in a better way, if read privileges need to be evaluated.

2. Actually the same applies to this. If this page were to evaluate read privileges (which it doesn'T do yet), then you would get duplicate counts as in 1. So I think the proper count for usual cases on this page would be preferable, if one has to choose betwen those two malheurs.

Someone with better SQL knowledge than me might want to inspect this issue, because I don't really see a workable approach to this...

Regards,
Garvin

[Don Chambers]

Someone with better SQL knowledge than me.....

Is this the equivalent of "when hell freezes over" ?

I had not taken read privledges into consideration for this.... Perhaps, in time, a solution will be found. For now, I just wanted to point out the behavior in case it was an oversight.

[garvinhicking]

Hi!

Is this the equivalent of "when hell freezes over" ?

Nah. More like "Dang, would somebody please jump aboard the train and get his hands dirty, pretty please with sugar on the top?"

Regards,
Garvin