Empty Expiration Date Field is filled with bad information! - default Expiration Date set to '1970-01-01'

Hi,

this is my solution is to check if it's necessary to show the expire date field. If it's not required, don't show it.
At line 41 on node_expire.module, change the if condition to this:

  if (isset($form['type'])
      and $form['type']['#value'] .'_node_form' == $form_id
      and $ntypes = variable_get('node_expire_ntypes', array())
      and $ntypes = $ntypes[$form['type']['#value']]
      and !empty($ntypes['required'])) {

To avoid the 1970-01-01 value is as easy as not try to insert an empty default date:

    case 'prepare':
      if (!isset($node->expire) && !empty($ntypes['default'])) {
         $node->expire = format_date(strtotime($ntypes['default']), 'custom', NODE_EXPIRE_FORMAT);
      }

at line 25 on node_expire.nodeapi.inc.

It works for me

Looking at the nodeapi prepare state, it looks like the default expire time isn't being used right. I changed this to be:

    case 'prepare':
      if (!isset($node->expire)) {
        $ntypes = variable_get('node_expire_ntypes', array());
        if ($ntypes['default']) {
          $node->expire = format_date(strtotime($ntypes['default']), 'custom', NODE_EXPIRE_FORMAT);
        }
      }
      break;

Woops. Patch without the print_r

In the 'prepare' case you should not pull in $ntypes again as it is passed as a parameter. The parameter version already is keyed into the content type of the node whereas variable_get is not.

I made the above change and it worked

however, every time i run cron.php i get the error below

it doesn't appear to break the website, would be good to get rid of message though

anyone any ideas?

user warning: Table 'web33-hartland.cache_views_data' doesn't exist query: DELETE FROM cache_views_data WHERE expire != 0 AND expire < 1245341978 in /var/www/vhosts/coastwise.org/httpdocs/includes/cache.inc on line 166.

user warning: Duplicate entry '50' for key 1 query: INSERT INTO node_expire (nid, expire, expired) VALUES (50, 0, 0) in /var/www/vhosts/coastwise.org/httpdocs/includes/common.inc on line 3422.

@mattys:

I'm not sure about the first warning, but the second one is addressed here (with a working patch): #426636: Errors on cron run

I'm not sure if I should post this here or on http://drupal.org/node/405608

* If I use tororebelde's fix in #1, the default function works properly. However, on a node type that isn't set to require a node expire date, the node expire date field doesn't show up at all, so you can't manually set an expiration for some node.

* If I use the patch submitted on http://drupal.org/node/405608 by arthurf, the field is no longer incorrectly required, but the default expire date and "required" functions stop working. I can set a node type to default-expiration of, say now +60 days, or some specific date, and/or set the expiration to be required, and both are ignored. You see a blank expiration field, and you can save the node without a date entered even if it's set as required in the node type settings.

It seems to me that the correct fix (at least partially) is just to modify line 26 in node_expire.nodeapi.inc to read

if (!isset($node->expire) and is_string($ntypes['default'])) {

That way, the node expire value on a form is not filled with Jan 1 1970 if the default is empty.

Regards,

Nigel

(Edited: Test should be is_string(), not `!= ''`).

Okay. I think I've got it nailed.

There are two changes needed in node_expire.nodeapi.inc.

At line 20, change it to read:

if ($row->expire)
$node->expire = $row->expire;

and at line 26 (27 after the previous change):

if (!isset($node->expire) and is_string($ntypes['default'])) {

Regards,

Nigel

I applied this patch first: http://drupal.org/node/426636#comment-1651286

Then I made the changes suggested by Nigel in #9. I am still getting a "You have to specify a valid date" message and a 1969 date on a node that shouldn't require that node expiration be set (same behavior as before the patches). I may have applied the patches in the wrong order or something. Please advise and thank you for the patches.

The kicker for me was users who couldn't edit the expiration getting "Cannot set node expiration in the past" or whatever since the expiration date was being set behind the scenes as "1970-01-01".

I ended up modifying the OP's code to:

      if ($node->expire == '0' && !user_access('edit node expire') )
      {
        unset($node->expire);
      }

I'll try this patches, from bottom up. Until then i am using default node expire time without blank, just set some big year or add +999 weeks. This should work for sure until module is perfect :-)

"You have to specify a valid date." from default Expiration Date: 1969-12-31 symptom of this bug, yes?

eh, think ive just submitted #614098: empty node expiry patch which is similar.

#546494: Disable node_expire completely for certain node types might be of interest to those reading this.

Thanks for this fix tororebelde in #1. Yes, this works for me as well. After cron, I did receive boatloads of warnings. I uninstalled and reinstalled the module with these changes and added dummy entries. The cron warnings disappeared and it would seem, fingers crossed, that everything is working. Other content types not using node expiration do not expose the field...a very necessary option, in my opinion.

Is this module being maintained, or should I eventually be looking elsewhere for an expiration function down the road? The reasons I decided to use this were 1) fields for node expiration in cck and 2) it is easy to expose the expiration field where I want it.

@protoplasm: FWIW, I've switched to the schedule module.

subscribing...

I think this will make the issue search easier, since most people see this in their node creation forms before reporting a bug.

How about this patch? Please help me in testing this..

I have added the above patch to a 6.x-2.04 installation and it seems to solve this problem.

It does solve the problem of filling bad info (default value of 1970-01-01) in the 'Expiration Date:' field (btw, this field's name should be 'Expiration date:' - why the capital in date?), but what I've tested is to set a 'Expiration Date Required' (again why capitals?). I see that the field is not actually set to 'required' though (I see no 'required' red asterisk indicator) and I was able to save a node despite the restriction!

PS: I filed a separate issue for #869394: Unnecessary Capitalization Of Words Throughout Forms, but I am not sure if I should also file another for the 'Expiration date required' setting not actually having any effect.

... I am not sure if this setting had the same issue even before applying the patch in #21

...also patch in #21 inserts some white space, corrected it and gave it a nicer name ;)

Thanks mahil and klonos.

I see that the field is not actually set to 'required' though (I see no 'required' red asterisk indicator) and I was able to save a node despite the restriction!

This is because you left Expiration Date blank. I am trying to give user an option to save a node which never expires. Hope you understand what I am saying.
"Default date to consider the node expired. Format: PHP strtotime format. Leave it blank if this content type never expires."

Regarding #869394: Unnecessary Capitalization Of Words Throughout Forms, I will change that soon. And thanks for patch.

Let me know if you find any other issues.

I understand the workaround you are trying to make available to users and the situation it might occur on. My mind is too blur at the moment to think of any better way to do this, and even if I did, I'd still need to file a different issue for that... I'll do so if anything just hits me ;)

Check out 6.x-2.x-dev. Report bugs.

So, we now actually have a dev version available! Great news!!!

PS: I always use dev versions where/when available ;)

Latest version must fix this. Reopen if not or file an issue if you find any new bug.

I think there is another bug related with this and I opened a new issue about it
look at
http://drupal.org/node/914810
I've been a long searching on many code files but i havent found the solution
:(

I'm getting this again after upgrading to the latest version