The Entityqueue Scheduler module provides an Entityqueue handler that allows creating scheduled subqueues. It allows you to schedule changes to the queue, allowing you not only to change what items are published in the queue at a given time but also in what order they should appear.
When you create a new Entityqueue and select the "Scheduled queue" handler, you automatically get a "Live" subqueue. From there you can add new subqueues, each subqueue requires a unique date on which it should be published. When a scheduled subqueue is published, the "Live" subqueue is updated with the items from the scheduled subqueue, and then the scheduled subqueue is deleted.
Project page
git clone http://git.drupal.org/sandbox/jojonaloha/2142361.git
Comments
Comment #1
PA robot commentedThere are some errors reported by automated review tools, did you already check them? See http://pareview.sh/pareview/httpgitdrupalorgsandboxjojonaloha2142361git
We are currently quite busy with all the project applications and we prefer projects with a review bonus. Please help reviewing and put yourself on the high priority list, then we will take a look at your project right away :-)
Also, you should get your friends, colleagues or other community members involved to review this application. Let them go through the review checklist and post a comment that sets this issue to "needs work" (they found some problems with the project) or "reviewed & tested by the community" (they found no major flaws).
I'm a robot and this is an automated message from Project Applications Scraper.
Comment #2
jojonaloha commentedComment #3
s_leu commentedIn the module file as well as in the install file you have db_selects.
Instead of
I don't see the reason to have further separate query-> statements as there are no dynamic parts in the query.
So instead you could just use
Also i'm not sure if the direct dependency to date_api is correct. date_api is part of the date module so i
would rather depend on both as it's not obvious for installing users that aren't familiar with the date module,
that date_api is part of the date module.
Comment #4
ram4nd commentedPareview still gives some issues: http://pareview.sh/pareview/httpgitdrupalorgsandboxjojonaloha2142361git
Comment #5
ram4nd commentedComment #6
jojonaloha commentedI've fixed the remaining pareview issues, although I think some were false positives. http://pareview.sh/pareview/httpgitdrupalorgsandboxjojonaloha2142361git
The reason is that addExpression() and innerJoin() are some of the exceptions that you can't string together. It's because they both return the alias, because the alias you pass in may actually not be the one used if that alias is already in use.
I updated the queries to make that more clear and reduce the extra
$query->calls that can be removed.I agree that the message from drush can be confusing:
But I don't think adding a dependency on the date module is necessary, since it isn't actually a dependency. I updated the project page and README to make it more clear where to find the date_api module.
Comment #7
heddnThis should use
$t = get_t();for the description. Have to use $t because this is used on install.$t('description' => 'The date this subqueue is scheduled to be published.'),This repeats code from the hook_schema_alter(). Better to do as:
function entityqueue_scheduler_update_7000()This repeats code from the hook_install. Either wrap the call for add field and index in a conditional db_index_exists and db_field_exists or don't repeat the logic.
Depending on how many queues there are to update, you might try using $sandbox for the entityqueue_scheduler_update_7000. See hook_update_N()
The .info file should include a version of 7.x-1.x
Comment #8
heddnComment #9
klausi@heddn: descriptions in hook_schema must not run through t() since that only creates overhead for translators.
Comment #10
heddn@klausi, good to know and it even makes sense.
Comment #11
jojonaloha commentedWow, didn't realize this was in Needs Work, otherwise I would have updated this sooner.
In any case:
I changed to
as you suggested, but I think the update script should be fine they way it is because the field didn't exist before, and the update script will only run if you are updating from an older version. Otherwise if this is the first time you are installing the module, then only the code in hook_install() is run.
Good point, I updated this as well.
I don't think this is needed, see https://www.drupal.org/node/542202#version
Comment #12
kaareWhile trying to grasp what entityqueue and entityqueue_scheduler actually do [1], I got this error on the page
admin/structure/entityqueue/list/<QUEUE>/subqueues/2/edit:Recoverable fatal error: Object of class DateTimeZone could not be converted to string in date_now() (line 1753 of /usr/local/share/drupal/7/modules/date/date_api/date_api.module).
The queue handler is of type Scheduled queue. It doesn't fail for the Multiple subqueue handler so I suspect a critical bug in this module.
I miss a note/paragraph about similar projects and what this solves compared to others. E.g. Scheduler. Is it a solution for publishing content at scheduled times in entityqueues only? As this module is rather specific, a more detailed explanation on the project page would help, maybe even with example usage.
Overall, the code quality seems good.
Notes
Comment #13
jojonaloha commentedActually, I think that error is a Date module issue: #2325207-2: DateTimeZone could not be converted to string
I also updated the project page a bit to clarify how this module differs from Scheduler.
Comment #14
jojonaloha commentedComment #15
Noe_ commentedIt looks good to me.
Comment #16
kscheirerNo issues found, this looks good to me! It wasn't quite clear to me why someone would install this module, perhaps an example use case would be helpful.
Thanks for your contribution, jojonaloha!
I updated your account so you can promote this to a full project and also create new projects as either a sandbox or a "full" project.
Here are some recommended readings to help with excellent maintainership:
You can find lots more contributors chatting on IRC in #drupal-contribute. So, come hang out and stay involved!
Thanks, also, for your patience with the review process. Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.
Thanks to the dedicated reviewer(s) as well.