Views Scheduler aims to provide the users of drupal with the ability to automatically manipulate content on a regular basis.
While the main objective is to be able to automatically publish/unpublish content on a regular basis, once the system is completed it should also be able to set up different views containing different contents.
The project will also allow the administrator to create nodes in which work ready for publication can be queued up in and published when the time arrives.
Project @ http://drupal.org/project/view_scheduler
Student: Shakur Shidane (Flk)
Mentors: Earl Miles and John VanDyk.
Views scheduler: Update info for testing
Hi,
I am currently working on the views scheduler project (SoC), i just wanted to give you guys heads up that currently it is open for testing and that i would really appreciate if you could have a go at it an report back any bugs/feature requests.
Project @ http://drupal.org/project/view_scheduler
cvs @ http://cvs.drupal.org/viewcvs/drupal/contributions/modules/view_scheduler/
What does views scheduler do:
It allows for the scheduling of views and linking any scheduled view to any number of actions.
Possible use:
creating a publishing queue and having certain number of nodes published (promoted, stickied etc) from that queue.
Come and test
Heya guys,
sorry i havent posted in a long while but god the time just flew by (so much to do, so little time).
God how horrible it is to code during boiling summer (omg its totally boiling here....i soo miss the rain :P)
Over this period i have had quite few problems which when i look back seem so simple such as understanding that actions_do() accepts an array of actions and a loaded node(node_load($nid)) not just node id.
so whenever i ran something like:
<?php
actions_do(action_node_publish,5);
?>I would get a bunch of errors:
Warning: Attempt to assign property of non-object in /home/flk/vhosts/kolaz.techarena.co.uk/modules/actions/actions.inc on line 17Update
OK, for the past few weeks i have been reading around different area's such as the form api, _cron hooks etc.
At times i could see what was happening and other times... i was totally lost.
For example for the past week or so i have been working on updating schedule module to work with 4.7.
So far i have built most of the form (god, how i wish i knew about lullabots formupdater before i began this ;P)
but i have been stuck on one single issue form_set_value() (http://api.drupal.org/api/head/function/form_set_value && http://drupal.org/node/51104 ) which allows for setting values to the form elements during the _validation stage.
Trials and Tribulations
Sorry i havent posted in while been busy with so many different things, so much to learn/do so little time hehe :D.
Anyways for past few weeks i have been attempting to create a plan of how go about each stage of the project. But because of what i need to learn and acheive the project just seemed bigger everytime i had a look at it :(.
After a session with drupals SoC pyschiatrist (webchick ;P), I do believe i have it figured out, well the first part anyways (first lesson learnt; dont think about the whole project, take it a chunk at a time).
I spoke to earls about it aswell and this is what i i think is the best way to get moving and seeing some progress will probably help,so to begin with i think its best if I got a list of exactly what i need from the schedule.module, whats missing.
This basicly means see if code is hijackable and what is needed on top of that code to make a ideal schedule module for our use.
Btw this could also be approached from the other end figuring out what i need form the views and whats missing etc.
From the views point, whats missing is an ID, an Entry point, and way to control the schedule.
now taking into consideration the schedule.module db design which i see as:
Read more
How I understand this project
This post is not instructional! I'm trying to make sure I understand the goals and am looking for confirmation only =)
The goal, as I understand it, is to implement a cron hook that tracks an arbitrary number of schedules. For every schedule that has come due, bindings to that schedule are loaded. Each binding has a view that is programmatically generated and piped to actions from the actions module.
So what this looks like from the inside:
- create a schedule. This ultimately should be one of { every time cron runs | every X hours/days/minutes | once in/on x hours/days/minutes}. Most likely the first implementation will focus on "every time cron runs" to avoid getting bogged down in scheduling logic.
- Create bindings. A binding is a pairing of a schedule to a view. You can bind as many views to one schedule as you want.
- Attach actions to bindings. Every {view:schedule} pair can have a stack of arbitrary actions.
- When cron runs a number of qualifying schedules get triggered. For each schedule, its bindings are loaded. For each binding, the view is processed/rendered and piped to the action stack. Each action can operate on each view. What the view is, in this case, is a list of nodes.
