Posted by Eric Schaefer on October 8, 2009 at 11:03am
| Project: | Scheduler |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Title says it all...
| Project: | Scheduler |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Title says it all...
Comments
#1
#2
#3
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.
#4
Less debug.
#5
Thanks a lot. I will check it out next weekend.
#6
Missing vertical tabs attached JS.
#7
That JS was in the original and I did not touch it.
#8
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.
#9
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 :)
#10
Go ahead!
#11
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()andpager_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.
#12
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
#13
Also see http://drupal.org/node/707832 the field API tutorial.
#14
Thanks for those links, i will roll out a patch this weekend.
#15
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!
#16
@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_tagsfield as an example to implement this. Ideally you need to usefield_create_field()when the module is installed andfield_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 ?
#17
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.
#18
Dependency on the date module should be optional, because it is rather large and is moving slowly. I have posted a ready to use patch almost a year ago and other people have even extended it and it has not even been considered yet. If you have a dependency on such a module your own module breaks with it. The date fields also have some limitations I encountered when integrating the date popup. I can not remember right now, but I will look it up...
#19
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?
#20
Just use text fields. We can do more if/when date for D7 appears.
#21
drupal 7 has a date form element now
#22
Subscribing
#23
subscribing
#24
subscribing
#25
Is there a accumulated patch for this? More eyeballs could be looking at this...
#26
What's the status on this? The latest patch is from February.
#27
Subscribing. I'm also concerned with drupal 7 version of this module.
#28
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?"
#29
I would love to see this in D7.
#30
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.
#31
If someone could turn this into a GCI task that would be wonderful.
#32
Subscribing. Thanks
#33
Sub, and thanks to those working on this!
#34
subscribe
#35
subscribing
#36
subscribe
#37
Attaching a bleary-eyed patch based on the latest CVS checkout of 6.x-dev. Known issues:
_scheduler_strtotime(), I use straight-upstrtotime()to override_scheduler_strptime()(note the p)Like I say, bleary-eyed, intent is to get things moving forward on this again.
#38
subscribing
#39
Subscribing. Need this in a project that starts next week.. :)
#40
subscribing
#41
subscribing - this module is gold :)
#42
subscribing
#43
subscribing
#44
subscribing
#45
Subscribing
#46
Subscribing
#47
We need to get this moving forward. I created a D7 branch and added the latest patch plus some small extra changes.
http://drupal.org/cvs?commit=485794
A dev release will be available in a couple of hours.
#48
BTW: If you encounter anthing missing or buggy please do not post it in this issue, but create a new issue for 7.x-1.x-dev!
#49
Closing this. We will post here when a official release is ready. Stay tuned.
#50
The dev release is live now.
#51
If you want to help, you could compare the current 7.x-1.x-dev release (which might be updated daily) with the current D6 release (1.8) or the current 6er dev relase (if you are really brave). Goal for release 7.x-1.0 is to have the same functionality as in the current D6 release. If you encounter a undocumented bug or missing functionality please file a new issue and describe what you expected to see and what was actually happening. Thanks.
#52
@chx: In you patches you uncommented the deletion of all scheduler variables in the uninstall hook. Is there a functional reason for that or was that merely for debugging purposes?
#53
Eric, I think you mean 'commented out' not 'uncommented'. The delete line became commented out, and has since been removed enirely from the function.
#54
You are right. <stupidexcuse>It was late</stupidexcuse>
#55
I just released 7.x-1.0-rc1 (http://drupal.org/node/1061628).
This release is pretty stable is will become 1.0 if no bugs are found the next couple of days.
#56
7.x-1.0-rc2: http://drupal.org/node/1069700
#57
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.
#58
RC3 has arrived: http://drupal.org/node/1078892
#59
This is day 8 since RC3 and no new issues since then. What do you think? Release or wait another week?
#60
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!)
#61
I am very sad we still use our own database fields etc instead of field API :(
#63
I will make scheduler more sevenish later. First make it work, then make it pretty. ;-)
#64
7.x-1.0 is out. Grab one while supplies last...
#65
Automatically closed -- issue fixed for 2 weeks with no activity.