birthday block doesn't reflect changes in birthday or new users

Can you give me a link to the site? I then have a better picture of what's showing what and maybe why, because I'm guessing a lot here.

For instance, are you sure you have set the block to show more than 1 day in advance, because that would explain why it doesn't show the birthdays of tomorrow. You can set this in the block settings at admin/build/block/configure/birthdays/by_days. It should, by default, show 7 days in advance. Another reason might be that the {dob} table is empty. Can you check that? And what does the other block show (the one that just simply shows the N upcoming birthdays)? That one should always show N birthdays. Can you check that aswell?

I think the strange dates you see are the result of the bugs in the old version. The old version sometimes saved the 01-01-1900 dates and did strange things with the year information. These were then saved in the {dob} table. With the wrong data in the {dob} table, these are also present in the new module (as it uses the same data) and in the profile-module (after synchronizing).
To solve this (if that is the problem indeed the problem), everybody who has a strange date, needs to change his/her profile to the correct date. Or you have to do it for them. At the moment it's not possible to remove a already set birthday, I think it's a good idea to alter this and add a button to reset the birthday of the user.

Concerning the blocks:
Did you set the user access (admin/user/access) to grant the appropiate roles the right to access birthdays? If not, that should solve your problem.

Lastly the bug concerning not being able to change the birthdays. I haven't a clue at this moment why that happens. The blocks and the user-profiles use the same date formatting system and the same data source. Therefore, if it shows correctly in the profiles, it should show correctly in the blocks. I definitly need an example website for this to figure this one out. Make sure to set the appropiate user access to make sure I can see something. It seems, again, that nothing is saved to the {dob} table. Does drupal report any MySQL errors in the logs?

Can you try synchronizing profile to birthdays? (the other sychronization). This should fill the {dob} table again and thus show some people in the block.

Now I think of it, I think I know why your {dob} table is empty: you said you uninstalled to module completely (using drupal) when you encountered that memory overload problem. That drops the {dob} table, and when you installed it again an empty {dob} was created.

This doesn't explain why the new and edited users aren't ending up in the {dob} table. But it at least gets us a bit closer to the solution.
Please sync back and see if new users (or edited ones) are ending up in the {dob} database (and in the block).

The only thing I can think of is that in some cases birthdays_save_user() isn't called properly or something like that. That would cause new users and edits to be saved in profile table, but not in the {dob} table and also new users wouldn't show a star sign (which is the case on your test site).

This is strange, because the synchronization uses birthdays_save_user() too, but that still does its work properly, right? Plus that I can't reproduce this in any way.

Can you insert the following code around row 632 after function birthdays_save_user(&$edit, &$user, $category) { to check whether birthdays_save_user() is called?

drupal_set_message("I'm in birthdays_save_user()",'error');

Then try to edit the birthday of a user and see whether the error string appears when you save. If it does, move that piece of code within the first if-statement and repeat the editing. If it still shows, place it in the last if-statement and repeat again.

Then tell me what happened.

Can you go to birthdays settings (admin/settings/birthdays) please and press 'save configuration' for me again? I have the impression that your profile field name isn't registered correctly, and saving can reset that.

Then try adding and changing stuff again.

I haven't read everything yet (off to bed), i'll do that in the evening. But here are some remarks concerning your last reply.

The newest version lists only people who have accessed the website once after registration. This is because normal users (not admin) can't see the profiles of these people. Showing a link to these non-existing profiles is not a good idea. So that might be why new users aren't showing up directly.

And I believe you have to synchronize once more 'from profile to birthdays'.

To solve everything for you, we need to reset the entire module to the new version in CVS and reset all settings.

Please do the following things in this order.

- Go to the modules administration and disable the birthdays module
- Go to the uninstall tab and uninstall birthdays module
- Download the newest birthdays.module from CVS: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/birthdays/b...
- Download the newest birthdays.install from CVS: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/birthdays/b...
- Replace the old files with the new ones you just downloaded
- Enable (and thus install) birthdays module.
- Go to birthdays settings
- Select everything you need and save settings.
- Synchronize from Profile module to birthdays module
- Go to user access and check the birthdays access settings
- Everything should work now.

Note: You will stil have people with birthdays of 0000-00-00 and 1900-01-01 and so on, because those were inserted by the users during the buggy previous version. As an administrator you can now go to their profiles and reset those birthdays by means of the "reset birthdays" button. Or you can give them the power to reset their own birthday.

Hi,

On the checkbox:
I already fixed the check box bug earlier today, but the frontpage tar.gz hasn't been updated yet (updated on 14:00). It's in CVS so you could fix it now if you want to, or you can wait until the frontpage has updated.

On the date listing of Choze:
I'm on it! I can reproduce it, so it's easier for me to find why it's doing it.

I found what went wrong with the sorting of the birthdays_get_birthdays_by_days() function(s).
MySQL sees strings of numbers as strings, not as integers. This made '1004' (4th of October) come before '406' (6th of April), which is not correct. By forcing it to compare them as integers the comparison goes correctly.

I've attached a patch and committed it to CVS (takes a few hours to show on the project page).

I guess that's that for all the bugs you had encountered. Thanks for going through with trying to get to the bottom of it, we've discovered and fixed many issues that way!
If you encounter any more new issues, please open a new issue. For now I gather this can be tagged as 'fixed'.

I hope we get a few days without any bug reports, so that we can introduce our first stable release! Thanks again!