I have users who can't remember that they scheduled a node. A message confirming that they did so would be very nice.

        // Right before we save the node, we need to check if a "publish on" value has been set.
        // If it has been set, we want to make sure the node is unpublished since it will be published at a later date
        if (isset($node->publish_on) && $node->publish_on != '' && is_numeric($node->publish_on) && $node->publish_on > time()) {
          $node->status = 0;
          drupal_set_message(t('This post is unpublished and will be published @publish_time.', array('@publish_time' => date($date_format, $node->publish_on))), 'status', FALSE);
        }
        break;

That's at the end of hook_nodeapi('presave'...

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Eric-Alexander Schaefer’s picture

Status: Active » Closed (won't fix)

I dont think we are going to include this.

NancyDru’s picture

Status: Closed (won't fix) » Active

How about an option? I've run into users all over the place who don't understand why their nodes aren't showing up right away. This simple change stopped most of our phone calls.

jonathan1055’s picture

Hi Nancy,

I wanted the same thing, and achieved it by adding:

  if ($vars['unpublished'] && isset($vars['publish_on']) && $vars['publish_on']) {
    $vars['for_publishing'] = t('Created on @datetime for publishing at @publish_date',
                                array('@datetime' => format_date($vars['created'], 'custom', 'jS M Y'),
                                      '@publish_date' => format_date($vars['publish_on'], 'custom', 'H:i \o\n jS M Y')));
  }

into my theme's hook_preprocess_node(), and

  <?php if ($unpublished): ? >
    <div class="unpublished"><?php print t('Unpublished'); ? ></div>
    <div class="for_publishing"><?php print $for_publishing; ? ></div>
  <?php endif; ? >

into node.tpl.php.

I know you could have figured this out too, but just thought I'd share it, in case it is any help.

Jonathan

Eric-Alexander Schaefer’s picture

I am curious. A user writes an article and enters a time for scheduled publishing and clicks "save". How can they forget between entering the time and klicking the save button? I don't get it.

NancyDru’s picture

How about they notice that some text in the body needs to be updated and by the time they get done, they have forgotten. My users do it all the time.

It can also happen when using Vertical Tabs, which I'm really getting to like, switching to another setting group, like comments, what they specified disappears; Yes, the tab says "scheduled for publishing", but they don't seem to notice that.

Eric-Alexander Schaefer’s picture

Version: 6.x-1.6 » 6.x-1.x-dev
Status: Active » Needs review
FileSize
960 bytes

Here you go. Please review...

NancyDru’s picture

Looks good. I haven't tested yet.

BTW, here's what my own submit handler does:

  $msg = NULL;
  if (!empty($form_state['values']['publish_on'])) {
    $msg .= t('This post will be published on @publish_date.',
      array('@publish_date' => str_replace('-', 'at', format_date(strtotime($form_state['values']['publish_on']), 'large'))));
  }
  if (!empty($form_state['values']['unpublish_on'])) {
    $msg .= ($msg ? ' ' : NULL) . t('This post will be unpublished on @unpublish_date.',
      array('@unpublish_date' => str_replace('-', 'at', format_date(strtotime($form_state['values']['unpublish_on']), 'large'))));
  }
  if ($msg) {
    drupal_set_message($msg . ' ' . t('The time is approximate as Forrester checks the scheduling every 20 minutes.'));
  }
Eric-Alexander Schaefer’s picture

Status: Needs review » Fixed
jonathan1055’s picture

Nancy's code has the benefit of using Drupal's format_date() function, which takes care of the users selected timezone (if any) or the website's default timezone. The message which Eric's code creates just displays the time using date() which could confuse users in other timezones. Just pointing out and recording the difference, which could be addressed later if required.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.