Expiration Dates being set

I'm unable to duplicate this. I added a text ad and an image ad, but in neither case was the expiration date set. What steps did you go through to create your ad? Did you enter anything at all in the scheduling section?

No, left them blank. I just click Create Content>Ad, and go from there. I edit the title, Description, URL, Pub options (not promote to front page), and add the attachment. Then I submit it, and then have to go back in and make Active. When I go back in the dates are set, but they are blank during the initial entry of the ad.

On a related note, for the ones I explicitly blanked the dates, I get a watchdog entry like the following:

Automatically expired ad Shukuen1 with nid 137.

Actually it happens on all of them, they all show expired now after my cron run. So none of them are displaying now.

FYI, all of these are in a group I created called widebanners, for all banners which are 468x60 pixels. Might make a difference since it's not the default group.

Do you have any other non-core modules enabled? Perhaps one that provides scheduling or workflow for nodes? (I'm wondering if there's a namespace collision with node->autoexpire, though it seems like a stretch.)

When you go back to set the image ad as "active", is the scheduling fieldset collapsed or expanded? Is there actually a date in the expired section?

If you go back and re-enable the ad, being sure to remove any values in "automatically expire ad", does the ad automatically expire again on the next cron run?

If you set a real expire date some time in the future, does this value get saved and does the ad then say "ad will expire in n days", and not expire on the next cron run?

I have a whole bunch enabled, but no idea if there would be any collisions.

When you go back to set the image ad as "active", is the scheduling fieldset collapsed or expanded? Is there actually a date in the expired section?

I think Scheduling is expanded when I go back in, and yes, both activation and expiration dates are filled. And both for the previous day, as I mentioned originally.

If you go back and re-enable the ad, being sure to remove any values in "automatically expire ad", does the ad automatically expire again on the next cron run?

Yes. It will auto-expire if I leave the auto-generated date (which is in the past), and if I blank the date.

If you set a real expire date some time in the future, does this value get saved and does the ad then say "ad will expire in n days", and not expire on the next cron run?

This is exactly what happens. A future expiration date (I made it jan 30 2020) does not seem to auto-expire prematurely, so far.

I've reviewed all the autoexpire logic, and I don't see any reason for your problem. I'm starting to be more and more suspicious of namespace collision. Can you execute the following query in your database and send the output?

Thanks for your help debugging this! I wish I could duplicate it locally...

In addition to the above information, which OS are you using?

No problem with the debugging help. I suspect your'e right, though.

Here is the query result:

block
comment
filter
help
menu
node
page
story
system
taxonomy
user
watchdog
graphstat
aggregator
archive
blog
book
contact
forum
legacy
locale
ping
poll
profile
search
statistics
throttle
tracker
upload
legal

The server is CentOS Linux, Kernel version 2.4.21-47.0.1.EL, Apache version 1.3.33, MySQL version 4.0.27-standard

I do not see any suspects in your list of enabled modules, and grepping through their code does not reveal any namespace collision. There must be something funky with my expiration logic. I'm out of time for debugging this now, but will look at it again as soon as I can -- for now I recommend setting your expire dates way in the future, as you have.

That works for me.

I was unable to duplicate this bug, or to spot the logical fault. I will leave this issue open to remind myself to continue looking into it, and hopefully to collect more information as to what is causing this problem on your installation. If anyone else is experiencing this problem, please speak up.

This bug is very low priority for me, but I thought I'd share my experience as an additional data point.

I am also seeing this issue (with beta5). In my case, the activate and expire times are always set to 10PM when I save an ad with blank schedule fields. It happens on newly created nodes or when I manually delete the fields on an existing node.

I doubt it makes any difference, but I tested with both IE7 and FF2 and saw the same results.

If my current local time is before 10PM, the date set is yesterday. If my local time is between 10PM and midnight, the date set is today (but the time is obviously still in the past).

One idea that comes to mind is that my user's timezone setting (under my profile / edit / locale settings) is 2 hours before the web server's timezone setting. So the localized display time (10PM) is 2 hours before midnight (start of the current day) on the server.

I wonder if the differences between user timezone, server timezone, and GMT could be confusing the default date/time calculation for these fields.

(In any case, the easy work-around is to edit the node and set the expire date to some time in the future.)

JM

In my case my user timezone is 3 hours behind the server timezone (mine is PST, server is EST). But my results are similar.

Which version of the module are you using? I'm still unable to duplicate, though I recall this happened to me once long ago -- perhaps you're using an outdated version of the module? Please download -beta7 and try again.

This has been fixed in the DRUPAL-5 version. Jeremy, you'll need to backport:

http://cvs.drupal.org/viewcvs/drupal/contributions/modules/ad/ad.module?...

In short: strtotime('') or strtotime(0) will use the current timestamp - thus, if a user DID NOT set the autoexpiration date, it'd be set immediately in insert/update nodeapi (since the value wouldn't exist). I just added a ternary check.

Thanks Morbus, fix backported to the 4.7 branch.