The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.The 8.x version is not working on current HEAD: it still uses class_loader(), settings() and has other issues which need to be fixed before addressing #2355425: Support for Pheanstalk version 3.0.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 0001-Issue-2476537-port-to-current-8.x-HEAD-all-tests-pas.patch | 43.36 KB | fgm |
| #2 | 0001-Issue-2476537-port-to-current-8.x-HEAD.patch | 12.58 KB | fgm |
| #1 | 0001-Issue-2476537-port-to-current-8.x-HEAD.patch | 7.22 KB | fgm |
Comments
Comment #1
fgmSuggested patch. Testing needed, but at least the requirements pass and report entries correctly.
Comment #2
fgmNew version:
Comment #3
fgmMore (all ?) fixes to the module : all tests pass.
Followups :
This patch includes early steps for both in addition to the module port.
Comment #4
fgmFWIW, I've completely restarted development from scratch for 8.0.x and Pheanstalk 3 on http://github.com/FGM/beanstalkd : when it is ready in a few days, I'll submit it here again. That version no longer depends on Libraries module, but directly autoloads from the root composer.json, as available since 8.0.0-beta16.
Comment #5
gordon commentedThanks for all your work. I have taken the 7.x-2.x to where I have wanted to and merged this into 8.x-1.x. This version is using composer manager and pheanstalk 3.1.x
The biggest problem that I have seen is that dumping a huge patch is hard to work out what has been done and a lot of the changes seem to be changes for the sake of change, eg $noeol -> $no_eol
I will start picking through the patch file and committing all the changes in smaller chunks.
Thanks again.
Comment #6
fgmHi Gordon. Not sure I was clear, but what I mean is that the patch in #3 is no longer representative of where I think we should be going : the code currently on Github is very different (and all new code has near 100% test coverage). Also, since core 8 now allows editing the project composer.json since https://www.drupal.org/node/2574533, this allows simpler installations without a remaining dependency on Composer Manager, which I took advantage of by just dropping this part of the mechanism and relying on that configuration instead.
FWIW, the static analysis results are available on https://scrutinizer-ci.com/g/FGM/beanstalkd/
I'm working on this today for a customer, and supposed to have a complete working version tonight (my time), BTW. Can we find a way to avoid duplicated effort ?
Comment #7
gordon commentedHi,
I have taken a look at this version, and there are something I like, and some not so much, and somethings that you have done which allows the way for future things I want to do.
It is a bit hard doing this via the issue, if you would like to contact me via https://www.drupal.org/user/959/contact and we can discuss this further.
Gordon
Comment #8
fgmContacted offline for simpler discussions If anyone else is following this, the current HEAD on github is supposed to be completely operational regarding the queue handling.
Next step is the CLI runner. Probably as a Drush plugin: not sure there is any good reason to do it standalone or using Console.
Comment #9
fgmCLI runner done on the github repo.
Comment #10
fgmStatistics report redone and improved : reports on all stats, and displays stats by category.
Comment #11
fgmMore tests, and the multi-queue runner is now included.
Code merged back from github to drupal.org. Thanks Gordon for adding me as co-maintainer. For now, I'll continue development on github because it is more convenient than d.o. (notably the ability to squash commits, the use of web hooks for notifications, etc), but will be pushing changes back to d.o. regularly.