In a recently developed and published website, I ran into a problem with the scheduler module, which is driving me absolutely crazy. I'm hoping someone has experienced the same problem.

At node/add form I enter a publish and unpublish date. The scheduler format used is Y-m-d H:i:s
The dates are stored in the DB. Also the node will show up on the content > scheduled overview page.
So far so good.

Here's where the shit hits the fence. When editing this node the fields are empty. So when the user saves the node the stored values are overwritten by the empty fields. And the node won't be unpublished.

I'm using scheduler with date popup. But disabeling date popup and setting scheduler to a textfield hasn't had any results. When I take a var_dump of the value in scheduler_form_alter -> nodetype_form

  $form['scheduler_settings']['publish_on'] = array(
            '#type' => 'textfield',
            '#title' => t('Publish on'),
            '#maxlength' => 25,
            '#required' => $publishing_required,
            '#default_value' => isset($defaults->publish_on) && $defaults->publish_on ? format_date($defaults->publish_on, 'custom', $internal_date_format) : 'test',
            '#description' => $description_format.$description_blank,

The #default_value contains the correct date format. When I add #value to the form with the #default_value the fields are correct.

Can anybody help me why the #value of this fields stay empty?

Thank you.




This does not sound like a problem solely caused by scheduler otherwise plenty of other people would have noticed it. Maybe another module of yours is altering the form with a hook_form_alter. Admittedly this should not cause a problem, so I'm not saying that scheudler isn't at fault. But it is working fine for me and many other users, so it must be some interaction with another module of yours.

Can you list all the hook_form_alter functions which your site knows about, then we can check which it might be.


I forgot to say, can you show us what is in the $defaults object? If you have devel module, just add dpm($defaults) and get a screen grab, or if not, add drupal_set_message('<pre>' . print_r($defaults, true) . '</pre>') or something like that.

Hi Jonathan,

Thanks for you quick reply. I'm also guessing that it's another module, but the problem is that I have really no idea which one. We have used hook_alter_form in a custom module, but there's an if statement that validates that it has to be an ubercart product and we don't use scheduler on ubercart product type nodes.

The website is quite complex and has around 50/60 contributed modules installed :S

In our back-end theme (modified garland), scheduler_form_alter is being called three times:


The last one is a custom module which is a block. I have disabled this block to exclude this form from this page and this hasn't had any effect on scheduler.

The var_dump of $defaults on the bottom of scheduler_form_alter gives me the following result. (Which looks fine by me).

stdClass Object
    [publish_on] => 1306367837
    [unpublish_on] => 1306637843

Scheduler is used with vertical tabs, but excluding this fieldset from vertical tabs also had no result.

Thank you very much for your help.

OK, good to see that $defaults is correct. I just want to make sure I know exactly the problem you are getting. When you view the generated source code on the node edit form, what do you get in the scheduler edit fields? In a clean D6 set-up, for unpublish, with vertical field tabs and text entry not pop-up I get:

<label for="edit-unpublish-on">Unpublish on: </label>
<input type="text" maxlength="25" name="unpublish_on" id="edit-unpublish-on" size="60" value="2011-04-28 17:17:17" class="form-text" />

Do you get nothing in the value=" " string, whereas in scheduler_form_alter() the value of $form['scheduler_settings']['publish_on']['#default_value'] is set correctly as a formatted text string?

If you have the devel module you can get a list of every function known to the system, so can find all the hook_form_alter() ones. Also have you checked if this happens on all node types? You might have some hook_form_NODETYPE_node_form_alter() functions too, which only come into effect on specific node types.


Thanks for your time and help Jonathan, It's very much appreciated!

The #default_value of $form['scheduler_settings']['publish_on'] returns the following 2011-05-26 01:57:17
Which seem to look fine. Weird right?

Just out of curiosity, why is the value save as #default_value and not just #value.
When add #value to the array the value is visible in the form. I'm just starting to understand module and form api and don't know the difference between the two.

There are a lot of form alters probably around 100/150 or so :S

But when I print $form_id on scheduler_form_alter only these three are shown:


Is it possible that another form_alter is breaking up scheduler?

Thanks Jonathan.

Priority:Major» Normal

I maybe asked too many questions in my last post. My first question is important. If you view the source code of your generated page, do you see anything like my example? Could you paste the html to show us here?

Hi, sorry I forgot to paste the source code, it's the same as your's but the value is empty.

What I don't get is that, when I var_dump($form['scheduler_settings']['publish_on']) I get 2011-05-26 01:57:17, which is a valid output. But the #default_value isn't set as #value.

<fieldset style="display: none;" class="vertical-tabs-scheduler_settings vertical-tabs-pane">
<div class="form-item" id="edit-publish-on-wrapper">
<label for="edit-publish-on">Publish on: </label>
<input maxlength="25" name="publish_on" id="edit-publish-on" size="60" value="" class="form-text" type="text">
<div class="description">Format: <em>2011-05-23 12:18:23 </em>. Leave blank to disable scheduled publishing.</div>
</div><div class="form-item" id="edit-unpublish-on-wrapper">
<label for="edit-unpublish-on">Unpublish on: </label>
<input maxlength="25" name="unpublish_on" id="edit-unpublish-on" size="60" value="" class="form-text" type="text">
<div class="description">Format: <em>2011-05-23 12:18:23 </em>. Leave blank to disable scheduled unpublishing.</div>


What I don't get is that, when I var_dump($form['scheduler_settings']['publish_on']) I get 2011-05-26 01:57:17, which is a valid output. But the #default_value isn't set as #value.

To state the obvious, there is a long way between defining your form with #default_value and the html being generated with a value="" attribute. Along that route somewhere the form builder process is probably doing the right thing with the scheduler form elements and then some other process is messing it up. That is what we are trying to find out.

You talk in several of your posts about #value - are you actually manipulating the form elements directly in some way?


Hi Jonathan,

Yeah when I change the form #default_value to #value, the fields will contain the date.

Like this.

$form['scheduler_settings']['publish_on'] = array(
            '#type' => 'textfield',
            '#title' => t('Publish on'),
            '#maxlength' => 25,
            '#required' => $publishing_required,
            '#value' => isset($defaults->publish_on) && $defaults->publish_on ? format_date($defaults->publish_on, 'custom', $internal_date_format) : '',
            '#description' => $description_format.$description_blank,

Thanks for helping, do you know if there's any possibility (function or magical trick) to see which function is altering the #default_value when the form is being processed?


I would just like to chime in and say I am also experiencing a similar issue to this one. Have you found a solution to this?

I'm happy to help if you need debug info from me to backup your findings.

Still searching for a solution for this issue, we have this problem on a very large project, with 50/60 contrib modules. (Lot's of ubercart add-ons). Unfortunately I still haven't been able to locate the problem.
Seems like the #default_value is set empty by another process.

To dreamlabs in #9, why are you setting #value in the form?

To BioAlian in #10, are you doing anything with #value in any of your custom code too?

Sorry, I think I mis-understood your post in #9. You were using #value temporarily to show it does work, but does not work when it has #default_value. Is that what you meant?

Yes that is correct, I just changed it to see if the value would be set. And it strangely did.

Hi Jonathan,

Do you have any ideas left why this problem occurs? I am a bit stuck.

Been away on holiday, hence delay.

I wonder if BioAlian who posted in #10 could list their contrib modules. Then maybe you could see which one coincide with your list. I can then reject any which I have and do not cause the problem, and that might leave a small enough set to check. Worth a try?

But it would be very strange for another module to specifically alter the scheduler fieldset, so maybe we should also start thinking about what module could interfere with the general form-building process.

I also have the same issue as others in this thread, and have never had issues with any fields dropping their values on my site before. I have even tried disabling several modules that remotely might have altered my form and it still happens.

I'm working on this right now, but cannot replicate it yet. I may post some code here which you can insert.
Are you working on the 1.8 version or a later dev release? Check the file scheduler.info for details.

Hi Jonathan,

Any news? I'm using version = "6.x-1.8".


I have installed the latest dev version, stil no date. I just spend 3 hours outputting vars with no result. My thoughts; the default_value is set, but when de DB retreives the values and the format doesn't matches, can it be that it bypasses the default_value? This is driving me nuts.

Hello Dreamlabs,
Could you post here the code and the results of your output vars - it must show that somewhere the value is being dropped. Then maybe BioAlian and sk33lz can also run it.

As I've said before I cannot replicate this problem, so any assitance in showing me what you have will help.

@Dreamlabs, do I have a problem like yours:

-> #1357134: Rights problem? Different effect with manual and automatic import

There are nodes imported with dates for Scheduler, which
get empty after automatic import.


Warszawa | Cycling in Fjord Norway


I apologize for my late response. I switched jobs and things got a bit hectic. Unfortunately I don't have access to the source code of this project anymore.

I know the guy, who is working on this particular project, I will send this topic to him, to check If he still has problems with scheduler.


Not sure if similar - can add nodes with publish_on info, but when editing, the publish_on date on the form changes to the current date() (And time), which screws people up if they don't catch it.

The publishing is working fine, as long as someone doesn't edit the node and changes the date/time.

scheduler (Array, 4 elements)
publish_on (String, 10 characters ) 1333857600
unpublish_on (String, 1 characters ) 0
published (String, 29 characters ) Sunday, April 8, 2012 - 00:00
unpublished (NULL)

Edit: #default_value is being set correctly right to the end of scheduler.module, so I can only assume it's a Date Popup issue. Still digging.

Edit Edit: Probably not a related issue. My issue is related to Date module requiring >= PHP 5.2. This site is running on 5.1.x, which doesn't have DateTime. Commenting out the class check in first lines of date_format_date on line 710-712 of date_api.module is a temporary fix for this specific issue, though certianly that will have other effects.

Component:Code» User interface

I've had the same empty fields issue. As I found this was caused by a false trigger setting and to 2 orphaned actions. Be sure remove orphaned actions. I hope this helps.

+1 for the empty unpublish_on field issue.

Here is how to remove "orphaned actions"

Same problem - blank entry fields, running OpenPublish distro on D 7.19 with Omega. #25 did not work. I could not tell if the other solutions were applicable.

My scheduling nodes come from import with Feeds module.
And the thing that helped me was changing the owner
of new, scheduled post from 'Anonynous' (or non-admin)
to admin. In the importer settings, of course.

So, it was kind of rights thing.


Status:Active» Closed (cannot reproduce)

I'm closing this issue as 'cannot reproduce'.

There obviously was some kind of difficulty which we discussed from #1 to #21 without being able to replicate it. Then new users chipped in on #22, #24, #25 and #27. The error in #22 was caused by another module and I suspect that to be the case with the others too.

If anyone can point to the fault in Scheduler then please open a new issue, as this one has become too difuse.

For reference, there is also a similarly named issued raised in the 7.x queue #1453570: fields empty on node edit form

Thanks for your time on contributing to the discussion. Sorry we found no solution - but that's because we found no problem :-)


#1808416: Date showing on node view - not showing on node edit - PHP 5.4 issue that might be the problem, I bet everyone is on PHP 5.4.

Hi Nicholas,
Thanks for that link, useful to know. I am on 5.3 locally where I did the testing so would not have seen the problem. Reading that issuse, looking at the patches in #8 and #19, the php 5.3 to 5.4 change seemed to give different results for empty() when using nested arrays. The comment in #7 is useful.

However, the original person who reported the problem said that they had also tried disabling date-popup to use the normal date field:

I'm using scheduler with date popup. But disabeling date popup and setting scheduler to a textfield hasn't had any results

So it may have been the php version, would need more checking. If any of the people above who had the problem would like to check this, please report back on what they find.


I can confirm that we had a site running fine on PHP 5.3 and just upgraded to 5.4 and the fields are now empty on edit.

Thanks for the feedback. Just so we can decide whether we need to re-open this issue, can you give a few more details please?

  1. What version of Scheduler are you using?
  2. Does the error occur with Date Popup, or Textfield entry, or both?
  3. What version of Date do you have?
  4. Does it happen for old nodes created before you upgraded to php5.4 or only with newly created nodes, or both?

I can confirm this is an issue after upgrading to the latest Date and Scheduler modules. The previously installed versions that worked as intended were Date 6.x-2.8 and Scheduler 6.x-1.8.

To answer the questions in #33:

  1. Scheduler 6.x-1.9
  2. Date popup with textfield is the only widget type I am using. I can confirm the issue with that widget.
  3. Date 6.x-2.9
  4. The server is PHP 5.4 and has not been recently upgraded. The upgrade responsible for this issue is either the latest upgrade to Scheduler or Date. Ironically, I have PHP 5.3 on my local machine and it all works fine even with the newer versions of the module. I'm certain that the issue did not exist on 5.4 before the module upgrades. I'm hoping that helps to determine the issue.

I am going to rollback to the previous versions to try and track down which module it is.

To respond to the post where this issue was closed, these nodes were not recently imported. The only change has been the update of the Date and Scheduler module.

EDIT: This patch fixed this issue https://drupal.org/comment/7208980#comment-7208980

Thanks for the info. I've just done a quick compare of Scheduler 6.x-1.8 to 1.9 and I don't think there are any changes which would affect this. I suggest to try putting date module back to 6.x-2.8 first, and see if that improves things.


Version:6.x-1.8» 6.x-1.9
Issue summary:View changes
Status:Closed (cannot reproduce)» Closed (works as designed)
Related issues:+#1808416: Date showing on node view - not showing on node edit - PHP 5.4 issue

Thanks for that. The issue link is #1808416: Date showing on node view - not showing on node edit - PHP 5.4 issue and the patch is in #19

So if my understanding is correct, the fix is to upgrade Date module to a 6.x-2.x version later than Sept 26, 2013. Just thought I would add that here for anyone else who runs into the issue.