sluc23 (17824176) at 16 Jan 08:00
2.0.3
sluc23 (17824176) at 16 Jan 08:00
2.0.3
An extra ç
got inserted into this file, which causes weird errors in unrelated places.
thanks @JonGold !
An extra ç
got inserted into this file, which causes weird errors in unrelated places.
sluc23 (e6f168e0) at 19 May 13:40
fix php warning
sluc23 (1aeeeb6c) at 15 Feb 16:45
bootstrap on construct if it's not
sluc23 (1aeeeb6c) at 15 Feb 16:45
bootstrap on construct if it's not
sluc23 (af4ee9a6) at 16 Dec 10:55
bandwidth-throttle/token-bucket: 2.0.1
sluc23 (39b6dac1) at 16 Dec 10:55
sluc23 (af4ee9a6) at 16 Dec 10:54
bandwidth-throttle/token-bucket: 2.0.1
sluc23 (39b6dac1) at 16 Dec 08:59
2.0.1
sluc23 (39b6dac1) at 16 Dec 08:58
2.0.1
@JonGold I am not following you when you say CiviCRM extensions can't be installed via Composer
. We DO install extensions via composer.json file in a D9 stack (along with D9 core, modules themes, etc..), that is why we don't include /vendor
, because at the end extensions will use main D9's vendor/
folder, not extension's vendor/
.
In case you don't use D9 composer approach, you will have to manually execute composer install
on extension folder to get dependencies and vendor/
will be created anyway..
Am I missing something?
This extension generates several PHP warnings on each Civi page load, this fixes it!
This extension generates several PHP warnings on each Civi page load, this fixes it!
While it's best practice to exclude a vendor
file from a git repo when packages are installed via Composer, CiviCRM extensions can't be installed via Composer. Thus, the norm is to include composer.lock
and vendor
folders in the repo (see extensions like Stripe as an example). Doing otherwise leads to confusion - both on initial install and when committing to a repo on a dev site (since the installed packages won't transfer to the test/live sites).