Do not port Elysia Cron, recommend Ultimate Cron for Drupal 8

Hi,

it's good for me to define some "standard" between the two of us in some aspect of cron processing.

Probably a hook_cronapi() standard could be a good starting point.

I've changed it in Elysia Cron 2.0 inspired by Drupal 7 hook_menu and similar hooks (i'm trying to get the "Drupal way", when possibile...), to add some features asked by users (hook_alter, #file), and to develop a much more flexible way to define jobs. I don't know what is your mechanism about it, however if you want to illustrate me some points that are diverging we can discuss them.
(Consider that i released the new api a little time ago, so i'm not intended to completely change elysia_cron system. But i can consider some improvements or try to have a compatibility layer with your module, as a starting point).

About influencing the Drupal 8 core cron... i think that Drupal SHOULD have a much better cron (the cron system is nearly the same in all Drupal versions, since a long time ago...), and should have AT LEAST a better segmentation of tasks (modules should define more than a task...) and a basic frequency management (at least hourly/daily/weekly...).

But it seems to me that Drupal folks are not really interested in this topic, at least by looking at Drupal forums... it seems that cron management is intended only as a "power user feature".

However, if you have some ideas to "influence Drupal 8" i can surely help...

For reference, this is elysia_cron structure:

function hook_cronapi($op, $job = NULL) {
  $items['key'] = array(
    'description' => 'string',
    'rule' => 'string',
    'weight' => 1234,
    'callback' => 'function_name', 
    'arguments' => array(...),
    'file' => 'string', // External file, like hook_menu
    'file path' => 'string',
  );
  return $items;
}

1) About the "hook_cronapi" call and the parameters ($op/$job), i think that a standard hook should have NO parameters, just like D7 hook_menu and similar functions.
Elysia cron has them for backward compatibility, but they should be used no more (and if a future Elysia Cron 3.0 will be release they will be dropped).

2) description and callback are the same between EC and UC: Ok

3) weight and arguments are only in EC: names are taken from hook_menu standards, so i think there is no problem with them. If you ever plan to implements them use these names. I think that at least a "weight" argument should be in an hook_cronapi proposal (how do you manage callback order in EC?)

4) module, function, configure, unsafe ara only in UC. I don't know what are their meaning, however they could be distinctive to UC and if you are not interested in "standardize" them it could be OK.
If you think some of them should be in the standard hook, tell me what are their meaning.

5) The real big difference is between EC "rule" and UC "settings".
I don't know how we can join them.
However probably the best thing to do to define a standard is thinking about a generic way to define this key, without considering too much our particular implementions.
How can be defined a generic drupal cron cron?

I really don't know this... i think that drupal core should implement only a basic timing system, not a precise "crontab like" timing. Something that just understand words like "daily", "monthly", "hourly" and similar...
If a Drupal user needs more precise timings he should use some 3rd party modules (like EC or UC).

Or, like you say, core core should have NO RULES AT ALL, and only the weight system to define run order.
In this case every extension could have its own method to define timings.

6) A note on EC's disabled / UC's enabled: for me the best think is having a "status" key that uses some constants like "CRON_ENABLED" and "CRON_DISABLED" (and maybe, in a future, other values).
(CRON_ENABLED can be "1" and CRON_DISABLED "0", this should be similar to your "enabled" key)

7) file/file_path: there are some difference (you use only "file" with full_path). The reason for EC's file+file_path is to use the hook_menu syntax. However i think that this is not a great problem. UC can continue to support its "file" key even if we put in standard file+file_path.

From this consideration, a starting point for a standard could be this:

function hook_cronapi() {
  $items['key'] = array(
    'description' => 'string',
    'status' => CRON_ENABLED|CRON_DISABLED,
    'weight' => 1234,
    'callback' => 'function_name', 
    'file' => 'string', // External file, like hook_menu
    'file path' => 'string',
  );
  return $items;
}

file+file path is not really relevant, we can drop it if it's a problem.

This is only my idea, tell me your changes...

Sorry for my late answers but i'm very busy at work in this period...

However, i see that the main difference in our approach is in crontab rules syntax (point 5).

IMHO, Crontab syntax is difficult to understand to every "non programmer" (and even for a lot of programmers).
Even modern linux distributions tries to hide it with a basic scheduling system that only specify if a job is hourly|daily|monthly|weekly.

When i released the first version of elysia cron, googling for user feedback resulted in a lot of people complaining they aren't able to use crontab syntax.

And, the most important fact, i think that for 99% of drupal installations crontab syntax is totally useless.
A very few sites needs to specify the exact minutes of execution, or have needs for complex rules (and a lot of sites doesn't needs crontab timings at all, the standard "run all jobs every hour" is ok).

Elysia cron is for that 1% of drupal installs (and maybe another 1% for debug purpose).
Drupal core cron should be easy, a basic (but expandable) system to cover the 99% of users...

Another problem in crontab syntax is the specific implementation. It's not very easy, and there are some subtle problems than can be trickier to solve. An example is this:
http://drupal.org/node/1265442
I don't think drupal core cron should mess with this implementations...

However, i think that this could be discussed with other drupal members and mantainers. Maybe drupal community is interested in your approach and want to follow it.
Maybe not.

Before making a lot of work in patching drupal core, we should try to understand if there are chances that the patch can be accepted by drupal folks...

Sorry, i wasn't able to go there :(

It's good to see this discussion here! I, for one, am interested in seeing how we can really make Drupal's cron functionality better. Right now, depending on the site, I have some drush jobs hit by separate cron tasks, and I have other things scheduled via elysia_cron. I have to do this many times, simply because one module = one cron schedule.

I'd love to see, mainly, (a) the ability to specify a set of cron jobs/tasks in hook_cron(), and then (b) the ability to stick these jobs into separate schedules. It could be simpler than what elysia_cron currently does, but would be a thousand times easier for me than having to manage cron schedules for some things via hook_cron(), and other things via drush scripts and crontab on the server.

Related #2169267: Replace drupal_cron_run() with a Cron service.

Core won't work different in any way with that, it's still a all or nothing, but a module like elysia_cron just has to replace that service and then it can implement it's "run what needs to be run" logic in there, transparent to everything else, no more custom cron.php scripts and stuff like that required. And it could extend the service to also offer methods to run a single sensor and so on.

I really like the idea of the Elysia Cron "crontab like" syntax.

Far more than 1% of the site's I build rely on it as critical functionality. I'd say closer to 10-15% have their own cron schedules that needed careful tweaking at some point.

Don't totally count it out for core!

This should work the way that Berdir described in #16. That way, even if this doesn't make it into D8, it should be D9 ready :)

I see there's no recent activity here.

Just wanted to mention that we provided a working Ultimate Cron port for Drupal 8 that is about to be merged into the d.o repo and MD Systems will continue to maintain that. I would love if we can collaborate and maintain it as a joint solution together.

We are looking forward to consider Elysia Cron features to make it feature complete.
And we would appreciate if you would mention the port on the project page. Mentionning "similar modules" is a common practice.

Thanks all for your contributions :)

We would be happy to contribute testing patch, quality assurance, documentation, and agile project management services if needed

Related pages

• Drupal 8.0.0 will be released on November 19, 2015
• News about "Porting modules and themes to Drupal 8 "
• "Drupal Module Upgrader" module. Which can do some of this automatically for you, covering many API hooks.
• Documentation about "Converting 7.x modules to 8.x"

I updated this ticket title so it's easier to find it with aggregators and search engines

That related ticket show the D8 porting status on the module project page under "Recommended releases" section at https://www.drupal.org/project/elysia_cron

Which invites additional contributors to join the efforts

Details at https://www.drupal.org/project/contrib_tracker

@Francewhoa I'm confused about the information that you share here.
I don't see a maintainer responding here since 3 years. The last commit in this (D7) repository is 2 years ago.

@gielfeldt Is more working on ultimate cron project and not elysia cron.

What direction are you heading now?
Ultimate Cron is well progressed and pushed forward step by step. There are not many things remaining until we will move to d.o and release alpha.
You are welcome to join forces to complete the port or test it.

However, if ultimate cron is really the recommended direction, then description at #2615318: [elysia_cron] Elysia Cron needs overhaul.

Hi miro_dietiker :) Thanks for asking

There are three efforts:

1. Port Elysia Cron from Drupal 7 to 8 at https://www.drupal.org/node/1442434

2. Port Ultimate Cron from Drupal 7 to 8 at https://www.drupal.org/node/2233283

3. While at the same as above efforts 1 and 2. There is a third effort toward collaboration between both ports. Including shared API between both modules.

To clarify and reflect the above I updated some tags and the issue summary

Minor edit to clarify further

After long time of inactivity at Elysia Cron, we should help the users to find its healthy replacement:
Ultimate cron has an alpha release for D8 since 4 months and is about to get beta soon.

Is this title proposal acceptable? :-)