I’m working on some project with a need for a queue for kirby. and I made one! as well (similar to queue for kirby) with the only difference, that it’s lot less developed at the moment. And that it supports multiple workers working at the same time (using flock)
kirbyQueue github repo
- Added a widget that shows failed jobs and allows to retry or to cancel them
- Added support for job title to show when the job is in the failed list
- Added a support to retry failed to jobs before sending to failed folder
- Added a way to make jobs as only a function
- refactored code
- added tracking for jobs failure
Now this still needs some work but the basic idea is there. I would love to hear some ideas
@seb - I really liked what I saw from your queue. And would have tried forking your thing and working on it directly, if it wasn’t for the fact I already made this and was just too lazy to make a readme (it’s still not great sadly ) - but I would love to hear your ideas and even co-operate on this.
Oh! I searched in both the forum and Jens’ plugin repo, and I didn’t find any queue, so I thought nothing existed yet. Not that it’s a competition, ofcourse, or that there can only be one
As for not making readme’s in time: I turn that around. At first, my plugin was only a readme, and once I described how I thought it should work, I wrote the code to make it work. Readme-driven-development, is that a thing? I like the approach.
Your plugin is a bit messy in some points. There is a lot of indentation going on, an not much OOP. For example, if you use
getopt() within the Worker class, that means you can not really use that class outside of the command line. And I haven’t tried it out, but things like
$count < count($files)+2 look suspicious to me. What two files are you ignoring there? And what if the users has more or less files that should be ignored?
(I don’t mean this as shade! Just some points where I think your plugin could improve.)
On the other hand, I think my plugin could indeed use a worker that is available as Deamon or via Supervisor. I have no experience with those, so I didn’t made that part yet I should/could look into flock() too.
At first, my plugin was only a readme, and once I described how I thought it should work, I wrote the code to make it work.
Nice approach. It sounds similar to dream code where you code how the code should look like in a perfect world and then try to keep that as long as possible.
You are of course absolutely correct - I usually make something rough that works, then refactor it to look decent. I’m super impressed with people who have the patience to start designing the way you did.
Anyway, I refactored the code to be more OOP. I really appreciated the feedback, and would like to hear more if you got any :).
And of course that can be as many plugins for this as needed. but I do think it might be a good idea to co-operate some. As you can see I lifted some of your code to add a new feature (queue jobs as a function or class).
As for flock - the main thing I noticed that is important is that PHP treats every request from the same browser (different tabs for example) as the same process - hence giving the panel direct control over it might cause collisions (might be resolved using static variable for panel commands maybe?)
Another thing is that you will not be able to use the kirby toolkit with it, you will need to mess directly with the php file commands (fopen, fclose, etc)
p.s The process with the readme is very similar, for me, to TDD where you write the test then code to it. So it makes sense
New version released, this is more or less shaping to be like I want it to. If nobody comes up with a new idea I will add some testing and bump the version to 1.