We use the birthday sidebar hook, but i had to rewrite it because it has the annoying hardcoded 5 entries limit. No problem here, BUT there were also only 6 entries shown, even when more users had birthday today.

I checked the birthday cache and saw that not all entries are in there. A quick look into the cache code brought a second hadrcoded limit on this really annoying 5 user limit in the cache loading method.

IP.Calendar 3.3.3

File: adminapplications_addonipscalendarsourcescache.php

		while( $r = $this->DB->fetch() )
		{
			/* Only allow 6 per day, then the "upcoming birthdays" can display 5 and know there are more to display */
			$_days[ $r['bday_month'] . '.' . $r['bday_day'] ]++;

			if( $_days[ $r['bday_month'] . '.' . $r['bday_day'] ] > 6 )
			{
				continue;
			}

			$birthdays[ $r['member_id'] ]	= $r;
		}

Why?

It doesn't cost anything to load all todays users when recaching one time a day and gives other much more flexibilty to use it. And more, removing this kills also an unexpected behavour of this cache.

I agree why is it limited?

I had to get a hook and install it to fix what use to be default.

Because some sites had 20+ "today's birthdays". The default hook is designed to show 5 with a "View more" link (the link is not showing correctly in the current release - this issue has been fixed for the next release), so there is no need to store more than 6. By storing 6 we know we have 5 to show, and need to show a view more link. That is all that our software needs, so it is all that we store.

It is good practice not to store more data in a cache than you actually need to.

Brandon is there plans on fixing back the Anniversaries as well with the same procedure you listed above?

so if i want to display more in a sidebar hook, i have to create an additional cache that stores more than 6, right?! not the way of reusabilty but ok.

can be closed.

You don't have to create a cache, no, you could simply query for however many you wanted.

it will be displayed on the main page of my site, so i think caching would be better

Up to you, I suppose, it's a lot easier to not cache it, and I doubt you'll see any performance issues.

If anything, it should honor a power setting or something imho(I say this only because from an admin perspective being locked into random num x hardcoded in by dev is annoying(thus something I avoid doing and fix when located), and AFAIK status updates and recent topics hooks have such a power setting)..... the reasoning is dead simple, that cache is designed to be a light way to pull out 5 birthdays occurring today optimized for efficiency. Increasing the number to 'all' moots the point, and you should be pulling them yourself, that cache serves it's designed purpose.

Calendar had an overzealous caching issue once, I'd not like to see another.

it will be displayed on the main page of my site, so i think caching would be better

1) You could use IP.Content to create a block and cache it

2) You could create a hook to overload the adminapplications_addonipscalendarsourcescache.php file and pull more records

Because some sites had 20+ "today's birthdays". The default hook is designed to show 5 with a "View more" link (the link is not showing correctly in the current release - this issue has been fixed for the next release), so there is no need to store more than 6. By storing 6 we know we have 5 to show, and need to show a view more link. That is all that our software needs, so it is all that we store.

It is good practice not to store more data in a cache than you actually need to.

Brandon

This makes pretty good sense since I normally have 50+ per day, so are we going to have to wait until 3.4.5 for this work?

I loaded 3.4.4 onto my test forum and this hook for showing 5 birthdays with a 'View More Link" is still not working, just fyi.

Brandon

This makes pretty good sense since I normally have 50+ per day, so are we going to have to wait until 3.4.5 for this work?

I loaded 3.4.4 onto my test forum and this hook for showing 5 birthdays with a 'View More Link" is still not working, just fyi.

The fix is in IP.Calendar, which is a separate application from IP.Board. That would be why it doesn't appear to be fixed yet (even though that particular issue is indeed fixed in our svn repository).

Yes, the fix for the 'view more' link will be in the next Calendar maintenance release.

The fix is in IP.Calendar, which is a separate application from IP.Board. That would be why it doesn't appear to be fixed yet (even though that particular issue is indeed fixed in our svn repository).

Yes, the fix for the 'view more' link will be in the next Calendar maintenance release.

Thanks guys, just forgot the Calendar is separate install now and not together with the board anymore. :blush:

Just curious when is the next Calendar release?

The next maintenance release is in the pipelines soon. The next major release will likely coincide with the 4.0 Suite.

is this now fixed in 3.4.5 as I am not seeing the view more link in 3.4.5 beta, still limited to just six

thanks

The fix is in Calendar, not Board.

The fix is in Calendar, not Board.

sorted

thank you