Create Drupal 7 Version

Note that the test manipulates the scheduler table because I was unable to find a better choice -- i did not want to add sleep() calls to the test.

Less debug.

Missing vertical tabs attached JS.

That JS was in the original and I did not touch it.

Can't apply this patch to the latest 6.x dev... is it possible to create a new drupal-7.x-dev branch so that we can start testing scheduler with D7? Thanks.

Eric, I can maintain the Drupal 7 branch for a while if you want. Just tell me OK and I will give myself CVS access, branch etc :)

I like to confirm that above patch works good (including TestCases) but there are few issues.
1. It doesn't provides proper navigation
2. Uses absolute functions like tablesort_sql() and pager_query()
3. A bit of code clean up.

Attached patch will fix the above mentioned issues. In IRC Chx suggested to use fields to store node publish/un-publish data instead of module's own table. Sounds like a good idea, at the same time it is tricky and time consuming work as i just started with drupal 7 module development. I am currently looking for a way to acheive it, will provide a patch when i am done. In the mean time someone can review the above patch and provide links to use fields in contrib modules.

The node example from "Examples for Developers" module illustrates how to use fields for custom content types in contrib modules:
http://drupal.org/project/examples

Also see http://drupal.org/node/707832 the field API tutorial.

Thanks for those links, i will roll out a patch this weekend.

Hi Sivaji,

Just wondered if you'd had a chance to look at updating the patch to use fields for the publish/unpublish date, or if you wanted any help doing so? I too am trying to get to grips with changes made by fields API in D7, but I'd be happy to try updating scheduler as a way of learning!

@tanoshimi Please feel free to try it out. I am committed to non drupal project so i didn't get much time to work on this. Things i have learned so far, take taxonomy_tags field as an example to implement this. Ideally you need to use field_create_field() when the module is installed and field_create_instance() when the content type is created or upgraded to use scheduler.

For usage see /profiles/standard/standard.install

  $field = array(
    'field_name' => 'taxonomy_' . $vocabulary->machine_name,
    'type' => 'taxonomy_term_reference',
    // Set cardinality to unlimited for tagging.
    'cardinality' => FIELD_CARDINALITY_UNLIMITED,
    'settings' => array(
      'allowed_values' => array(
        array(
          'vid' => $vocabulary->vid,
          'parent' => 0,
        ),
      ),
    ),
  );
  field_create_field($field);

  $instance = array(
    'field_name' => 'taxonomy_' . $vocabulary->machine_name,
    'object_type' => 'node',
    'label' => $vocabulary->name,
    'bundle' => 'article',
    'description' => $vocabulary->help,
    'widget' => array(
      'type' => 'taxonomy_autocomplete',
      'weight' => 4,
    ),
  );
  field_create_instance($instance);

(correct me if this is wrong.)

I guess using fields instead of module's table will make module upgrade path from 6.x little difficult ?

Ok, so I had a little look at field-ifying the publish_on and unpublish_on dates for scheduler...

D7 Core does not provide a 'date' field type, nor any date-related field widgets. Date module (http://www.drupal.org/project/date) is currently in development for D7 and provides a range of useful date field types (Date, Datestamp, and Datetime), together with a popup calendar widget, so this seems like a good approach. However, date is still under heavy development and is not stable enough to use these field types at the moment. So it's hard to do much more from a practical point-of-view until date fields settle down.

My second issue is more of a theoretical/approach one: at the moment, scheduler v6.0 does not have a dependency on date module, but if present it uses it to present the popup calendar. I guess if you were to fieldify scheduler to use one of the date field types, that would create a dependency on date, which is significant (date module is complex and nearly 1.5Mb) - one of the things people seem to like about the existing scheduler is that it is lightweight and relatively simple. The alternative I guess would be for scheduler to define it's own "schedule_date" field type to remove the dependency, but this seems like duplication.
It seems reasonable to me to expect a scheduling module to have a dependency on a date module - what do others think?

As sivaji points out, it also requires a little bit of thought about the upgrade path to move from table-based to field-based etc.

Thanks for the info, Eric. I tend to agree with you about not wanting to introduce a dependency on date, but I can't see any other way to sensibly use fields other than using the date field types and widgets. As owner of the scheduler module, what's your opinion on whether/how D7 scheduler should use fields rather than storing them in the scheduler table?

It should be noted that the patch included by sivaji in #11 works absoutely fine to implement all the existing functionality of scheduler 1.6 in D7, but it does so in a way that is perceived to be a "Drupal 6"-approach, i.e. it is using nodeAPI rather than fields. I've mentioned in other threads that, just because we have fields in D7, we do not necessarily have to use them in every use case... what is the benefit here of making the scheduler dates into fields?

Just use text fields. We can do more if/when date for D7 appears.

drupal 7 has a date form element now

Subscribing

subscribing

subscribing

What's the status on this? The latest patch is from February.

Subscribing. I'm also concerned with drupal 7 version of this module.

As Moshe pointed out, Drupal 7 has a date form element. Can Scheduler use that instead of the Date module? If so, that'd help keep it lightweight. Features like the ability to use Date's drop-down calendar would be nice, but could those be optional modules added into future iterations of Scheduler 7.x?

This is one of two modules keeping me from moving one of my sites to D7.x, but I am, alas, more of a content creator than a coder. My coding talent consists of occasionally noticing things like, "Hey, is this function supposed to have a semi-colon in the same place that this almost-identical one does?"

I would love to see this in D7.

First off, chx, I assume you're waiting until at least RC1 to do any more with this, right? So would testing sivaji's patch from back in Feb be useful at all, or not?

If I use the existing patch and then a New, Improved final version of Scheduler for 7.x (with Borax!) comes out, it shouldn't affect anything previously published via Scheduler, correct? As in, all I'd have to do would be change info for stuff scheduled for future publication and drop or truncate any obsolete tables?

Was also thinking of trying to apply the patch from http://drupal.org/node/960030 before this. Good idea? Bad idea? "Step away from the crack pipe and stop running with scissors," type of idea?

I want to find ways to contribute, and I figured that at least testing the last patch might be helpful. I apologize if some of my questions sound stupid. I'm a writer who ended up falling into a bunch of web stuff years back, and while I enjoy it, my skills consist primarily of taking apart other people's PHP until I either break it or (if I'm lucky) get it to do what I wanted.

If someone could turn this into a GCI task that would be wonderful.

Subscribing. Thanks

subscribe

subscribing

subscribe

Attaching a bleary-eyed patch based on the latest CVS checkout of 6.x-dev. Known issues:

• the test fails, at least on my install
• in _scheduler_strtotime(), I use straight-up strtotime() to override _scheduler_strptime() (note the p)
• the content type settings form is 'missing'. Code's still there, but parts of it need to be wrapped in arrays to show up (with JavaScript enabled; at least you can get a working form with JavaScript disabled)

Like I say, bleary-eyed, intent is to get things moving forward on this again.

subscribing

Subscribing. Need this in a project that starts next week.. :)

subscribing

subscribing - this module is gold :)

subscribing

subscribing

subscribing

Subscribing

Subscribing

@chx: In you patches you uncommented the deletion of all scheduler variables in the uninstall hook

Eric, I think you mean 'commented out' not 'uncommented'. The delete line became commented out, and has since been removed enirely from the function.

I nearly missed this update because the status was closed(fixed). Changed it back to fixed, set priority to normal and removed chx as the assignee, to reflect how this thread is now being used. Hope that is OK.

Great that rc1 only had one bug that was found (in 8 days of being released). We've now got 140 installations of the D7 version. It is all looking very good.

We've got 240 installations using 7.x and I would say yes make official release 1.0

Having an official release may flush out some more bugs (if they exist) whereas we probably will not find them just relying on the RC releases as fewer sites will try them. Go for it. I'm here to help you fix/test if anything nasty crops up (which it won't of course!)

I am very sad we still use our own database fields etc instead of field API :(