I know that i can do that with CRON but there are a lot of issues with these method. I have a Entity "Events" and when $eventDate <= Date (NOW) it will be deleted dynamically. I'm using PHP Framework Symfony2.
Why don't you want to use cron? Another approach is using queues that allow to use delayed messages (something like Beanstalkd, it has a lot of bundles for Symfony) -- but obviously it's more complicated than cron.
What issues are with a cron? You can create a symfony command that do what you want and call it from a event listener on the request or from a cron.
You can make a symfony command that delete the Event when $eventDate <= Date (NOW) and you can add a cron to run the command every X time
Related
I have 2 .net core web projects.
One of them is called ScheduledJobs and it uses Hangfire with the dashboard to both schedule and process jobs.
The other is called ClientWebsite and it schedules the jobs only - but I dont want them executing here!
ScheduledJobs works fine, if I schedule anything from there it picks them up and processes them.
But since I need to be able to schedule jobs from clientWebsite too, I have to have the following settings in startup:
services.AddHangfire(x => x.UseSqlServerStorage(Configuration.GetConnectionString("DefaultConnection"));
services.AddHangfireServer();
If I dont call services.AddHangfireServer it wont even let me schedule them.
But if I add it, then it processes them too which I dont want !
Please help! Thanks
You shouldn't need to register the hangfire service at all in the second project in this way.
If you want to purely queue jobs from it you can use the GlobalConfiguration to set up which database it should point at similar to
GlobalConfiguration.Configuration.UseSqlServerStorage(Configuration.GetConnectionString("DefaultConnection"));
Once you have done this you can register a BackgroundJobClient similar to this (this is taken from an autofac example so depending on your DI it wont be exactly the same as the line below)
builder.RegisterType<BackgroundJobClient>().As<IBackgroundJobClient>();
What this then allows you to do is resolve and enqueue jobs using the IBackgroundJobClient in your application without setting up a hangfire server at all.
In your classes where you want to enqueue jobs from you can then simple resolve an instance of IBackgroundJobClient and make use of the Enqueue method such as
_myClient.Enqueue<MyJobClass>(x => x.APublicMethodOnMyJobClass());
Details on the backgroundjobclient can be found here - BackgroundJobClient
What I need is execute one php file every hour. I found a lot of weird and not-understandable things about creating a module for Drupal (I don't need a whole module, I need to execute just ONE file).
Because my brain can't handle this dull realisation of Drupal or Cron.
Better solution is to use system crontab because it reduces load to php and your site will run faster.
Read more:
https://en.wikipedia.org/wiki/Cron
http://www.computerhope.com/unix/ucrontab.htm.
If you can't use system cron try to configure Drupal's cron: https://www.drupal.org/cron.
In worse case you can try https://www.drupal.org/project/poormanscron module.
If you want to do it the Drupal-y way, instead of a more hacky way outside of what Drupal is meant to do, use hook_cron().
To do this, you will need to create a new module with that function inside of module_name.module. You can view the documentation on creating a new module in Drupal six here. You should only need the "Getting Started" and "Tell Drupal about your module" sections.
In your module_name.module file, write a hook_cron() function. The hook will be replaced by the machine-name of your module.
The description of hook_cron() on Drupal.org is as follows:
Modules that require to schedule some commands to be executed at regular intervals can implement hook_cron(). The engine will then call the hook at the appropriate intervals defined by the administrator. This interface is particularly handy to implement timers or to automate certain tasks. Database maintenance, recalculation of settings or parameters, and automatic mailings are good candidates for cron tasks.
Without more details of what you are trying to accomplish or more details about your script, this is all I can provide.
I have a little question, how create a simple cron task who call some service action in Symfony, who could be executed automatically each night ?
Symfony2 does not manage cron tasks, simply because this is system level. That being said, you can create a command and register it as a cron task.
You can use CommandSchedulerBundle
You can now use TaskScheduleBundle to make your cron jobs within symfony.
does anybody know is it possible (drupal 6) to create several tasks which should run by crontab? I've created hook mymodule_cron but I need one more. Is it possible to create something like mymodule_another_task_cron?
Thanks
Why don't you add another task in your existing hook_cron? You can call whatever functions you want from one hook_cron.
I can highly recommend the Elysia Cron module
Elysia Cron extends Drupal standard cron, allowing a fine grain control over each task and several ways to add custom cron jobs to your site.
As a module developer the method you'll be most interested in is implementing hook_cronapi() to register jobs that can be scheduled individually through the Elysia cron admin settings.
There's also Ultimate Cron, but I can't vouch for that one as I've never used it.
I use Scrum methodology and deploy functionality in builds every sprint.
There is necessity to perform different changes in the stored data (I mean data in database and on filesystem). I'd like to implement it as a PHP scripts invoked from console. But they should be executed only once, during the deployment.
Is there any way to implement it through app/console without listing it in the list of registered Console commands? Or is there any other way to implement runonce scripts?
DoctrineMigrations covers some part of my requirements, but it's hard to implement complex changes in Model. And it does not cover changes in files on the filesystem.
I don't think symfony has a facility for that, and besides, hiding the command is not the same as securing the command.
Instead, I would make the script determine if it has been run already (could be as simple as adding a version number to a file and checking that number before running) and stop if it detects it has already run before.