@drwilliamhobbs, I believe reading through Ludwig documentation → can help you. For example, what you did by putting the libraries into the vendor folder manually was wrong. This is not how Ludwig works. Please read the documentation.
If following strictly the Ludwig documentation does not help you, then please post the screenshot of your "Packages" page here.
Re: #3 and #5
This Ludwig documentation file is useful:
Can I manage libraries of all contrib modules with Ludwig? →
Ludwig does not put packages files into the libraries folder. That was Drupal 7 way and it is almost completely abandoned in Drupal 8+.
The D8+ Colorbox module is an exception. It kept the old fashioned D7 way of dealing with library. Therefore the Colorbox module does not have Ludwig integration (ludwig.json file) and you need to follow instructions from Colorbox project home page to install its library manually as you did.
Closing as resolved. Feel free to reopen if needed.
All missing libraries are downloaded automatically when you visit the "packages" page. So, if none are reported missing that's good, that means that automatic download has done it's job successfully... and you are ready to install your library-dependant modules now and test if they are working properly.
Re: #8
@promo-il please read comment #6 here.
Re: #81+
The patch #2 in the new added related issue should help. Please test.
Just to confirm that patch #9 fixed a node render RuntimeExceptions reported by search_api module in my case.
RTBC in my case.
My config: D10.3.1. The patch #9 applied successfully.
Previous error message was:
Type search_api
Date Tuesday, July 30, 2024 - 23:55
User Anonymous (not verified)
Location https://my.com/node/2706/edit
Referrer https://my.com/node/2706/edit
Message RuntimeException while trying to render item entity:node/2706:en with view mode search_index for search index Default content index: Failed to start the session because headers have already been sent by "/home/my/public_html/vendor/symfony/http-foundation/Response.php" at line 1315. in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 132 of /home/my/public_html/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php).
Severity Error
Operations
Backtrace
#0 /home/my/public_html/core/lib/Drupal/Core/Session/SessionManager.php(162): Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start()
#1 /home/my/public_html/core/lib/Drupal/Core/Session/SessionManager.php(127): Drupal\Core\Session\SessionManager->startNow()
#2 /home/my/public_html/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php(311): Drupal\Core\Session\SessionManager->start()
#3 /home/my/public_html/vendor/symfony/http-foundation/Session/Session.php(222): Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->getBag()
#4 /home/my/public_html/vendor/symfony/http-foundation/Session/Session.php(242): Symfony\Component\HttpFoundation\Session\Session->getBag()
#5 /home/my/public_html/vendor/symfony/http-foundation/Session/Session.php(69): Symfony\Component\HttpFoundation\Session\Session->getAttributeBag()
#6 /home/my/public_html/core/modules/views/src/ViewExecutable.php(762): Symfony\Component\HttpFoundation\Session\Session->get()
#7 /home/my/public_html/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(2242): Drupal\views\ViewExecutable->getExposedInput()
#8 [internal function]: Drupal\views\Plugin\views\display\DisplayPluginBase->elementPreRender()
#9 /home/my/public_html/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php(113): call_user_func_array()
#10 /home/myi/public_html/core/lib/Drupal/Core/Render/Renderer.php(870): Drupal\Core\Render\Renderer->doTrustedCallback()
#11 /home/my/public_html/core/lib/Drupal/Core/Render/Renderer.php(432): Drupal\Core\Render\Renderer->doCallback()
#12 /home/my/public_html/core/lib/Drupal/Core/Render/Renderer.php(504): Drupal\Core\Render\Renderer->doRender()
#13 /home/my/public_html/core/lib/Drupal/Core/Render/Renderer.php(504): Drupal\Core\Render\Renderer->doRender()
#14 /home/my/public_html/core/lib/Drupal/Core/Render/Renderer.php(248): Drupal\Core\Render\Renderer->doRender()
#15 /home/my/public_html/core/lib/Drupal/Core/Template/TwigExtension.php(475): Drupal\Core\Render\Renderer->render()
#16 /home/my/public_html/sites/default/files/php/twig/66a95f91ba545_node.html.twig_NDqtWxoLpyRFa6oXHJ6UnJr_a/C7a4KCDRNPTvx_Z-GXBGdoFPJloemDJndA3-1dBnQp4.php(114): Drupal\Core\Template\TwigExtension->escapeFilter()
#17 /home/krkswami/public_html/vendor/twig/twig/src/Template.php(360): __TwigTemplate_7a9ce1f8bd9ce10a30ff475b2491dced->doDisplay()
#18 /home/my/public_html/vendor/twig/twig/src/Template.php(335): Twig\Template->yield()
#19 /home/my/public_html/vendor/twig/twig/src/TemplateWrapper.php(38): Twig\Template->render()
#20 /home/my/public_html/core/themes/engines/twig/twig.engine(33): Twig\TemplateWrapper->render()
#21 /home/my/public_html/core/lib/Drupal/Core/Theme/ThemeManager.php(348): twig_render_template()
#22 /home/my/public_html/core/lib/Drupal/Core/Render/Renderer.php(491): Drupal\Core\Theme\ThemeManager->render()
#23 /home/my/public_html/core/lib/Drupal/Core/Render/Renderer.php(248): Drupal\Core\Render\Renderer->doRender()
#24 /home/my/public_html/core/lib/Drupal/Core/Render/Renderer.php(165): Drupal\Core\Render\Renderer->render()
#25 /home/my/public_html/core/lib/Drupal/Core/Render/Renderer.php(638): Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}()
#26 /home/myi/public_html/core/lib/Drupal/Core/Render/Renderer.php(166): Drupal\Core\Render\Renderer->executeInRenderContext()
#27 /home/my/public_html/modules/contrib/search_api/src/Plugin/search_api/processor/RenderedItem.php(222): Drupal\Core\Render\Renderer->renderInIsolation()
#28 /home/my/public_html/core/lib/Drupal/Component/Utility/DeprecationHelper.php(40): Drupal\search_api\Plugin\search_api\processor\RenderedItem->Drupal\search_api\Plugin\search_api\processor\{closure}()
#29 /home/my/public_html/modules/contrib/search_api/src/Plugin/search_api/processor/RenderedItem.php(223): Drupal\Component\Utility\DeprecationHelper::backwardsCompatibleCall()
#30 /home/my/public_html/modules/contrib/search_api/src/Item/Item.php(281): Drupal\search_api\Plugin\search_api\processor\RenderedItem->addFieldValues()
#31 /home/my/public_html/modules/contrib/search_api/src/Entity/Index.php(987): Drupal\search_api\Item\Item->getFields()
#32 /home/my/public_html/modules/contrib/search_api/src/Utility/PostRequestIndexing.php(92): Drupal\search_api\Entity\Index->indexSpecificItems()
#33 /home/my/public_html/core/lib/Drupal/Core/DrupalKernel.php(723): Drupal\search_api\Utility\PostRequestIndexing->destruct()
#34 /home/my/public_html/index.php(22): Drupal\Core\DrupalKernel->terminate()
#35 {main}Patch #32 fixed the issue for me.
DraggableViews 2.1.4
D10.3.1
PHP 8.1
Patch #12 fixed the issue for me.
DraggableViews 2.1.4
D10.3.1
PHP 8.1
Re: #15. Thank you @tedbow.
I have added a recommendation for Ludwig users to switch to Automatic Updates contrib module at the Ludwig project page.
I hope this helps.
It would be nice to hear the experiences of Drupal UI oriented users who are using Automatic Updates already. If it works nice for them I believe we can put Ludwig EOL even before Automatic Updates push itself into the Drupal Core.
What is your current experience? Is using Automatic Updates module (for updating both Drupal Core and contrib projects) now nice and smooth or not so convenient yet? Is there any reason to keep Ludwig active still from your point of view?
Patch #4 is committed. Status is back to active for further bot suggestions.
This patch should help.
If maintainer wants this can be committed as well to help other Ludwig users.
Thanks for update @tjtj. Just a note for others who may experience the same issue.
If you are using Composer to manage your project packages you have to UNINSTALL Ludwig.
Are you using Composer or Ludwig to manage your packages... or both?
Yes. The synonyms can be stored in entity reference fields as well. So, you can declare your taxonomy related entity reference field as the source of synonyms for your desired entity.
Re: #17
You are right @dqd. It is the upgrade issue here.
The error messages which appeared in my tests described in my comments #14 and #16 are due to known issue described here: #1959170: Applying dependency on entity reference/autocomplete field does not work → . Sorry for noise.
What does that has to do with this issue which is about issues of already existing dependencies in an Drupal core update between 9.5 to 10?
As much as I have tested this issue is for general 4.x branch compatibility with D10. Not for D9 to D10 upgraders only.
I cannot reproduce what you tested.
I tested it again with 4.x-dev and the issue remains the same. Did you try to create the described dependency and edit it afterwards? No error message for you?
Re: #13
Ok. I'll try to help. Let's do a simple reproduce.
Clean standard Drupal 10.2.4 + Conditional Fields 4.0.0-alpha5 installation.
Visit /admin/structure/taxonomy/manage/tags/overview and create few Tag terms: tag1, tag2, tag3...
Visit: /admin/structure/conditional_fields/node/article and add new dependency:
- Target field: Body (body)
- Control field: Tags (field_tags)
- Keep the rest default and proceed with "Add Dependency" button.
At the next screen:
- Condition: Value
- Values input mode: Insert value from widget
- Inside the Tags field select: tag1
- Keep everything else default and save settings
Clear caches just in case...
Go to Add new Article form (/node/add/article). The "Body" field is hidden by default and it should become visible if "tag1" Tag term is selected. But it does not work. When "tag1" term is selected inside the "Tags" field - the "Body" field is not becoming visible.
It may help for debug... additionally, a few JS errors are visible inside my Chrome browser's console:
Uncaught TypeError: reference.indexOf is not a function
It may help also... the attempt to edit newly created dependancy fails with error message:
The website encountered an unexpected error. Try again later.
InvalidArgumentException: Value is not a valid entity. in Drupal\Core\Entity\Plugin\DataType\EntityReference->setValue() (line 106 of core/lib/Drupal/Core/Entity/Plugin/DataType/EntityReference.php).
Drupal\Core\Field\FieldItemBase->writePropertyValue('entity', Array) (Line: 293)
Drupal\Core\Field\Plugin\Field\FieldType\EntityReferenceItem->onChange('target_id', ) (Line: 239)
Drupal\Core\Field\Plugin\Field\FieldType\EntityReferenceItem->setValue(Array, ) (Line: 208)
Drupal\Core\TypedData\TypedDataManager->getPropertyInstance(Object, 0, Array) (Line: 91)
Drupal\Core\Field\FieldTypePluginManager->createFieldItem(Object, 0, Array) (Line: 41)
Drupal\Core\Field\FieldItemList->createItem(0, Array) (Line: 69)
Drupal\Core\TypedData\Plugin\DataType\ItemList->setValue(Array, 1) (Line: 107)
Drupal\Core\Field\FieldItemList->setValue(Array, 1) (Line: 657)
Drupal\Core\Entity\ContentEntityBase->set('field_tags', Array) (Line: 566)
Drupal\conditional_fields\Form\ConditionalFieldEditForm->getDummyField('node', 'article', Array, Object, Array) (Line: 171)
Drupal\conditional_fields\Form\ConditionalFieldEditForm->buildForm(Array, Object, 'node', 'article', 'body', 'a6457cfb-fa78-460e-abe4-b725dd0aacf8')
call_user_func_array(Array, Array) (Line: 536)
Drupal\Core\Form\FormBuilder->retrieveForm('conditional_field_edit_form', Object) (Line: 283)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)RE: #79
The Ludwig integration is added recently ✨ reCAPTCHA - Ludwig integration Fixed , so the latest 8.x-3.x-dev can be installed with Ludwig as well. Of course, the Composer is highly recommended whenever possible.
I believe this issue can be closed as outdated. If you have a proper Composer installation or the proper Ludwig + reCAPTHA 8.x-3.x-dev installation and you still experience this issue please feel free to reopen.
Tested. Everything works fine now. Closing as outdated. Thanks for reminder @rachel_norfolk.
I tried to reproduce. But, this time the build was successful.
Thanks for reply @rachel_norfolk. Closing...
Just a reminder re:#6:
TASK: @nonom Please, revert the 3.x branch Ludwig change you made recently.
D10.2.x patch fix.
D10.2.x reroll.
The 3.x branch Ludwig integration does not need fixing. It was fixed already before v3.0.6 is released:
📌 Ludwig integration needs an update Fixed
@nonom Please, revert the 3.x branch Ludwig change you made recently.
Commit to 4.x is ok.
Thank you so much @fgm for your elaborated reply.
I have a rather small site, so switching back to db cache makes a lot of sense.
I'll close this issue as "Cannot reproduce", and maybe someone else will open it again in the future if he/she experience the same issue.
Thanks again! Have a nice holydays!
BTW... one more question.
I couldn't find any information regarding core "Internal Page Cache" and "Internal Dynamic Page Cache" modules when using Memcache.
Should I uninstall this two core modules or should they stay installed? Or it doesn't matter?
Thanks for reply @fgm.
It's a shared sever with cPanel.
These screenshots may help:
- cPanel PHP extensions screenshot
- Status page screenshot
- phpinfo() screenshot
- Memcache statistics (turned on by Memcache admin module) screenshot
devad → created an issue.
Ludwig patch is here.
the 'v' library version prefix is not needed any more. Removed.
The "mobiledetect/mobiledetectlib" library has one new dependency. The "psr/simple-cache" library. It's added to the ludwig.json file
Both libraries are PSR-4 autoload type, so the mobile_detect.module Ludwig integration code snippet is not needed any more.
This patch should do the job nicely.
A request: @nonom Please enable 3.0.x and 4.0.x branches for automated tests.
Maybe it is a bit too late to radically change the concept here but I'll ask nevertheless...
Is it possible to have here two different sets of radios which are shown/hidden by JavaScript?
One set available if the "Required" checkbox is unchecked and the other set of radios available when the "Required" checkbox is checked. As suggested in comment #239.
That would give us enough flexibility for all options we need both currently and in the future.
Note: The "Synonyms UI" submodule is canceled and merged back to the main "Synonyms" module before v2.0.0 is released... due to the WSOD problem described here:
Note: The "Synonyms UI" submodule is canceled and merged back to the main "Synonyms" module before v2.0.0 is released... due to the WSOD problem described here:
Additionally... it would be nice if we can make here the "Limit list to select items" option to work nicely with "Is not one of" operator as well... which is not the case currently... but of course, it can be done in the separate issue as well.
This bug (which has evolved into feature) is still around although Views joined the Drupal core many years ago.
Let's assign the "Bug smash initiative" to this issue and see if the Bug smash initiative team has will to deal with it.
It would be great to have Views cleaned up from this ugly 15 years old bug before D11 is released. :)
I am willing to help with manual tests and feedbacks as much as I can.
If you have the Ludwig module already installed, but somehow the library is still not present, the error message is this instead:
Feeds requires the library "laminas/laminas-feed". It can be downloaded by the Ludwig module, which you appear to have installed. Go to Packages list to install the missing libraries.
And "Packages list" links to /admin/reports/packages.
I'll consult @devad (maintainer of the Ludwig module) if this instruction is correct. I did try to install the Ludwig module first and then Feeds afterwards and the library was still missing. But when I went to /admin/reports/packages, the library got downloaded and installed. And then I was able to install Feeds successfully.
Yes. This is all correct Ludwig instructions. Thanks.
MegaChriz → credited devad → .
Glad this helped.
yes, clearing caches worked in fact..
Ludwig has a cache clean embedded into it's code... but it can cache clean only the cache at the site where you have visited the Ludwig > Packages page. At all other sites you need to clean caches manually.
The same drill with cache clean (at all your sites) you will need to go through after updating the symfony_mailer (or any other Ludwig-managed module) next time.
Also... at your multisite configuration... do you have a multiple modules/symfony_mailer folders or only one for all sites?
Did you try this suggestion?
You can try to clear caches at all your sites after visiting Ludwig Packages page... just in case that's the problem in your case.
I don't have any experience with multisite configs,
so where is the difference?
You can try to clear caches at all your sites after visiting Ludwig Packages page... just in case that's the problem in your case.
My log record. Screenshot attached.
I tested.
I get the same error if I try to install Drupal Symfony Mailer module BEFORE all packages are downloaded by Ludwig.
After all packages are reported as downloaded by Ludwig the Drupal Symfony Mailer module installation goes smoothly for me. No more WSOD or errors in logs.
Hi Jochen.
Please send a bit more data about your config.
- Your Ludwig version
- Drupal core version
- php version
For full set of use case options I suppose we should have here:
Case a - when the "Required" field checkbox is not checked
1a. End date is required when the start date is provided (default behavior currently - selected as default for BC reasons)
2a. End date is optional when the start date is provided
(3a.) End date can be provided even if the start date is not provided
Case b - when the "Required" field checkbox is checked
1b. Both start date AND end date are required (default behavior currently - selected as default for BC reasons)
2b. Start date is required only
(3b.) End date is required only
(4b.) Start date OR end date is required
The radio options 3a, 3b and 4b are postponed for later addition. The follow-up issue is here: ✨ Allow start date to be optional Active
Note: English is not my native language, so the better wording is welcome of course.
For full set of use case options I suppose we should have 4 radio options available here:
o Start date AND end date are required
o Start date OR end date is required
o Start date is required only
o End date is required only
The description should be conditional, like "Whether an end date must be provided *if* a start date is given".
+1 for this suggestion.
This description is clear and easy to understand IMHO.
I thing I need to tackle the composer hurdle. I've been doing the old way for so long that I'm a little intimidated by setting it up.
I really like the Ludwig idea, but I think they want to discontinue it.
Ludwig will be around until a new similar official UI tool is completed. 💬 Retire Ludwig? Postponed
bluegeek9 → credited devad → .
Yes, you have the URLs right. The library names should be kept the same as composer's.
This ludwig.json file should work.
{
"require": {
"composer/ca-bundle": {
"version": "1.3.7",
"url": "https://github.com/composer/ca-bundle/archive/1.3.7.zip"
},
"maxmind/web-service-common-php": {
"version" : "v0.9.0",
"url": "https://github.com/maxmind/web-service-common-php/archive/v0.9.0.zip"
},
"maxmind-db/reader": {
"version" : "v1.11.0",
"url": "https://github.com/maxmind/MaxMind-DB-Reader-php/archive/v1.11.0.zip"
},
"geoip2/geoip2": {
"version" : "v2.13.0",
"url": "https://github.com/maxmind/GeoIP2-php/archive/v2.13.0.zip"
}
}
}
Since you said you are using Ludwig... did you created manually the ludwig.json file inside your modules/visitors folder?
Duplicate of related issue. Committed to .dev already.
I have created and pushed a new Synonyms release today for D10 users convenience reasons.
Just a note.
The v1.8.5 of the library requires PHP8:
"require": {
"php": "^8.0"
}
If we upgrade Ludwig library to v1.8.5 it will not be usable for users with Drupal9 + PHP7.4 configuration.
But Drupal 9 is EOL few days ago, so I suppose such an update is ok.
The 2.x-dev version → has Ludwig integration updated already. See:
https://git.drupalcode.org/project/mailchimp/-/commit/91497012bfa8af86ce...
Note: The /refs/tags part of the URL is not needed, so the URL can stay as it is now.
Re: #6
Ludwig is not a proper place to add dependencies to other drupal modules. The .info file is a proper place for that.
See the related issue.
Thanks @ressa and others.
I have changed the first two sentences at the top of the project page to reflect your idea.
Ludwig is retired.
Just a correction... Ludwig is not retired. 💬 Retire Ludwig? Postponed . You can read @bhojanz comment #6.
It is not recommended (Composer is)... but it has not be recommended ever since it was created by Drupal Commerce team 7 years ago. :)
Drupal Commerce supports Ludwig still. However, if you decide not to support it any more within this project - that's ok of course.
Re: #10
If Wordpress can do it fully automatically even in the background I see no reason for Drupal not being able to do the same
It's work in progress. Called Automatic Updates. Not ready for use yet (Alpha release only) . You can take a look at:
https://www.drupal.org/docs/8/update/automatic-updates →
https://www.drupal.org/project/automatic_updates →
Re: #8
Hi @true pal. The second part of your post with a question is off-topic here. To get a proper help it would be better to delete that part from this closed issue and post it as a new issue (support request).
Note for maintainers: It would be nice to have Mobile Detect branch 3.0.x available for automated tests.
Re: #23
If you are using Ludwig to manage your library dependencies (instead of Composer) and you are also using the latest 3.0.x-dev version of Mobile Detect you may need the patch #2 from related issue.
Simple library version upgrade patch.
Note for maintainers: It would be nice to have branch 3.0.x available for automated tests.
Here are some examples which might be useful for issue-reproduce purpose:
Condition which works nicely in my case:
Target controlled by "list type" field with Condition: "Value" and Values input mode: "Any of these values (OR)"
Does not work:
Target controlled by "list type" field with Condition: "Value" and Values input mode: "Insert value from widget"
Does not work:
Target controlled by "entity reference type" field with Condition: "Value" and Values input mode: "Insert value from widget"
Does not work:
Target controlled by "entity reference type" field with Condition: "Value" and Values input mode: "Any of these values (OR)"
Note: All of these conditions worked nicely before I made the D10 upgrade.
This issue still exists in alpha5 as well.
RE #95:
Hi @newswatch. This is not an ideal place for such feature request or further discussion but I will reply here once to help you.
The request for any project's Ludwig integration should be posted at project's issue queue.
The Upgrade Status module dependencies (core dev included) are too complicated for Ludwig integration though.
You can read and follow info "Installation on sites not using composer" at the Upgrade Status project page → .
Thanks all. I tried a .dev committed Facets plugin and it works nicely.
Can you explain why this change is needed? Should we be updating our requirements in composer.json as well?
The best is to update the ludwig.json in the same time the composer.json is updated.
However, the Composer.json file is updated without a ludwig.json update. So, this patch is needed to keep the ludwig.json file in line as well.
I am not familiar with Ludwig and why we need to duplicate requirements there so forgive my ignorance.
This is an explanation from official Why Ludwig? → documentation:
Contributed Drupal modules often require external PHP libraries. Therefore, ever since Drupal 8 is released, preferred tool for Drupal site management is Composer. Ludwig is written as an UI alternative to users who are not friendly with the command line tools yet, or want to avoid Composer usage for other reasons.
Also, you mention downgrading the version, but the patch looks like an upgrade from 9.6.2 to 9.8.0.
From patch #2 to patch #3 interdiff:
- "version" : "9.10.0",
- "url": "https://github.com/thephpleague/csv/archive/9.10.0.zip"
+ "version" : "9.8.0",
+ "url": "https://github.com/thephpleague/csv/archive/9.8.0.zip"