- Edited
This extension is available for people who want to test it. Instead of:
composer require blomstra/database-queue:*Use:
composer require blomstra/database-queue:"*@beta"Let me know what you think!
Database Queue - the simplest queue, even for shared hosting
Good option for large communities in shared hosting but I think when a Flarum community growing up go in the same time to update server to VPS or Dedicate no?
And in this case maybe go with Redis?
Other question about the same.
The option "someone posts in a discussion I´m following" is affected for this?
Now, by default in Flarum when new user register, the Email Notification with "someone posts in a discussion I´m following" is active. In my case I prefer it to be disabled by default (only the part for Email). I find it too invasive and spend some resources sending emails. If the user requires it, I prefer that he activate it himself manual.
I think I remember that someone user create a small extension to leave this option by default deactivated for new users. I've looked for it but I can't find it or I may have dreamed it? 
Thanks!
1Dot Edit Users are unable to post they get oops something went wrong and then if they see in new tab but its posted the console error is attached below
What is the error in storage/logs?
Walys Good option for large communities in shared hosting but I think when a Flarum community growing up go in the same time to update server to VPS or Dedicate no?
And in this case maybe go with Redis?
Check the faq in the OP.
luceos Go into your hosting control panel and set up the following task to run every minute
Some shared hosters limit the interval you can run scripts to 30 minutes or so. What would be the impact of that when running this plugin? Just that the emails get dispatched only every 30 minutes or would something more important be effected?
What about registration emails? Could those still be dispatched immediately & independently from this queue plugin?
poVoq if it's anything like other queue plugins, all emails and things of that nature would get delayed by 30 minutes. And if you have a lot of emailing to do the queue could timeout before it finishes meaning that not all the emails are sent (so so people wait an hour, then hour and half, then two, etc.)
poVoq Some shared hosters limit the interval you can run scripts to 30 minutes or so.
What tankerkiller125 means is, even though the database queue is a queue, using the cron won't keep the worker running continuously. As such queue tasks are indeed only processed at the latest each 30 minutes if your hosting provider doesn't allow running faster.
Personally I don't think using this database queue driver on a hosting provider that limits cronjob interval to 30 minutes is the right solution. But to those that can configure it to run every minute, or at least every 5 minutes, it should be a really great intermediate solution to speed up their community.
tankerkiller125 And if you have a lot of emailing to do the queue could timeout
With this extension that isn't really possible. If the worker receives an enormous pending task list the worker will keep working on that list, after 30 minutes a new worker will be dispatched which will also start working on the task list. At some point all tasks are completed and each worker will terminate. Some hosting providers might forcefully kill duplicate workers (I certainly don't hope so), as the last task wasn't finished the new worker will simply continue with that one.
I must say, this queue driver is not tested and all I've said above is based on practical experience using cronjobs, scheduled tasks and similar environments. There might still be situations things don't go as planned, if that is the case I would love to think along to resolve that.
luceos With this extension that isn't really possible. If the worker receives an enormous pending task list the worker will keep working on that list, after 30 minutes a new worker will be dispatched which will also start working on the task list.
Shouldn't there be a protection to prevent spawning concurrent workers? Then you could probably skip --stop-when-empty flag and allow worker to run continuously.
rob006 yeah, some providers might kill duplicates or even prevent them.
luceos Some hosting providers might forcefully kill duplicate workers (I certainly don't hope so), as the last task wasn't finished the new worker will simply continue with that one.
Removing the --stop-when-empty indeed makes sense if the provider prevents duplicates and doesn't time workers out.
luceos yeah, some providers might kill duplicates or even prevent them.
I'm not even sure how they could automatically detect duplicates (since they're not duplicates - every process is doing its own job), but avoiding concurrent workers will prevent multiple problems, like race condition issues or draining all resources by workers that spawns indefinitely.
- Edited
rob006 if people decide to use this, I'd love to hear their experiences. I'll probably not invest too much time on this for several reasons:
- I've build this (simple) extension to improve performance on communities that are active, but not large.
- I've build this to generate a little goodwill on behalf of Blomstra. But we are not using it and neither am I nor discuss.
- The core team agreed to merge this alternate, simple driver into core. It means I'll have to mimic some of the logic the mail driver has. In addition we decided to only show these advanced features based on certain activity thresholds. More about this in the dev diary soon.
Can it exist alongside blomstra/flarum-redis?
shebaoting it can, but only one queue driver will be active at the same time. Blomstra/flarum-redis allows you to disable the queue, this extension (the database queue) is enabled when enabled in the admin area.
I have this set up and it works well. Thank you 
- Edited
Could you also add a public link to this so that another server could trigger it?
- Edited
luceos Can you explain a bit more? I was thinking about writing a small php script that can be accessed from the webserver publicly that triggers this plugin, as the shared host I am running this Flarum on only allows scheduled tasks at every 30 minutes. But I have another server that I don't want to put this forum on, which could just ping the php script regularly.
poVoq set up an identical flarum install on that other server that connects to the database of your production site. Run the worker there. There might be some unforeseen issues (cache flushing for instance when changing extensions) but other than that it should work as is. Note that you will need to update two installs if you update your production website.