@Dewlance said:
Are vibe-coded scripts even working? I tried one, and it throws too many errors when I run it on the server.
First run created a bunch of bullet points that never was tested locally on the dev machine.
Mostly because difference in OS and other installed software.
I think I got everything working after the initial install, the bugs found was handled.
I have added a couple of "features" that popped up as a side-effect during the install.
Whats left, test all functions.
Make sure it works.
Compare features that are available in other Panels and add them to my project.
A file Manager is useful, a webmail UI is useful.
Things like that.
@Dewlance said:
Are vibe-coded scripts even working? I tried one, and it throws too many errors when I run it on the server.
Heavily depends on the scope their maintainers develop for. Most people probably do not really care for anything else than their own environment.
Having stuff on github usually then is just something the AI recommended so itself can follow a better development flow while their user often enough do not understand anything about git or pipelines.
So if you pick random stuff, that sounds like it could do something you are looking for, will even more often already break during "installation".
I have seen tons of stuff where part of the install method is "clone the repo here and then do x y z."
That might be feasible if it actually would be source, where you then compile something from. Only nowadays it isn't.
@mikho Small preflight suggestion from reading current main (not a test install): composer.json now says ^8.4, but require_php_version() only checks major/minor, so 8.4.0 passes. The script’s own comment says the locked production dependencies need 8.4.1+. It also writes .env before attempting composer install.
Running composer check-platform-reqs --lock --no-dev in preflight(), before configure_env_file, would check the committed lock against the actual PHP/extension versions and stop before those configuration changes. Composer explicitly ignores config.platform for this check. That also catches missing extensions rather than just the PHP version.
A regression test could assert that an incompatible runtime exits with .env unchanged, then verify a clean install on the supported minimum runtime using the same committed lock (without composer update).
@ucelicloud said: @mikho Small preflight suggestion from reading current main (not a test install): composer.json now says ^8.4, but require_php_version() only checks major/minor, so 8.4.0 passes. The script’s own comment says the locked production dependencies need 8.4.1+. It also writes .env before attempting composer install.
Running composer check-platform-reqs --lock --no-dev in preflight(), before configure_env_file, would check the committed lock against the actual PHP/extension versions and stop before those configuration changes. Composer explicitly ignores config.platform for this check. That also catches missing extensions rather than just the PHP version.
A regression test could assert that an incompatible runtime exits with .env unchanged, then verify a clean install on the supported minimum runtime using the same committed lock (without composer update).
Fix (install-cp.sh): preflight() now runs composer check-platform-reqs --lock --no-dev instead of the major/minor check. It runs before the node/npm checks and before anything is written, and exits 11 on a mismatch. As you said, it checks the lock's exact PHP and extension requirements and ignores config.platform. One side effect: Composer older than 2.3 has no --lock option, so it now fails preflight too.
Regression test (.github/scripts/test-install-cp-platform-reqs.sh, now in CI):
• On PHP 8.3, the script exits 11, an existing .env is byte-identical afterwards, and no .env is created if there wasn't one.
• On PHP 8.4.1 without sodium, it exits 11 and leaves .env unchanged.
• On PHP 8.4.1, composer install --no-dev succeeds from the committed lock, and composer.lock is unchanged afterwards.
Two details make the test meaningful:
• The PHP 8.3 cases alone don't prove the fix, because the old version check also rejects 8.3. The sodium case is the one the old script fails.
• The old script checked node/npm before PHP, so in a container without Node it would stop early and pass for the wrong reason. The test gives those runs stub node/npm commands, so only the platform check can stop the script.
I also updated the vault's Installation Guide to say PHP 8.4.1 or newer, plus the extensions the lock requires.
@mikho I checked the updated script and regression test; I haven’t run the containers. The platform check now precedes configure_env_file, and the sodium case checks both the diagnostic and unchanged .env, which distinguishes it from an unrelated exit 11.
One optional addition for the Composer 2.3 minimum you noted: run a compatible PHP runtime with Composer 2.2 and assert exit 11 plus unchanged/absent .env. The current test fetches composer:2, so it doesn’t exercise the unsupported-tooling path. That would protect the “fail before mutation” guarantee if preflight ordering changes later.
Comments
Are vibe-coded scripts even working? I tried one, and it throws too many errors when I run it on the server.
Dewlance - Affordable Shared/Reseller.
WHMCS Addon - DemoTiger Video KB - Tutorial Videos for Hosting Providers.
First run created a bunch of bullet points that never was tested locally on the dev machine.
Mostly because difference in OS and other installed software.
I think I got everything working after the initial install, the bugs found was handled.
I have added a couple of "features" that popped up as a side-effect during the install.
Whats left, test all functions.
Make sure it works.
Compare features that are available in other Panels and add them to my project.
A file Manager is useful, a webmail UI is useful.
Things like that.
Meet Nix and Bruce @ https://twobirdsonelesbox.com
My project/stuff page @ https://serveraddict.net
There is a stealth model on openrouter right now with basically infinite tokens.
Free NAT KVM | Free NAT LXC
Heavily depends on the scope their maintainers develop for. Most people probably do not really care for anything else than their own environment.
Having stuff on github usually then is just something the AI recommended so itself can follow a better development flow while their user often enough do not understand anything about git or pipelines.
So if you pick random stuff, that sounds like it could do something you are looking for, will even more often already break during "installation".
I have seen tons of stuff where part of the install method is "clone the repo here and then do x y z."
That might be feasible if it actually would be source, where you then compile something from. Only nowadays it isn't.
@mikho Small preflight suggestion from reading current main (not a test install):
composer.jsonnow says^8.4, butrequire_php_version()only checks major/minor, so 8.4.0 passes. The script’s own comment says the locked production dependencies need 8.4.1+. It also writes.envbefore attemptingcomposer install.Running
composer check-platform-reqs --lock --no-devinpreflight(), beforeconfigure_env_file, would check the committed lock against the actual PHP/extension versions and stop before those configuration changes. Composer explicitly ignoresconfig.platformfor this check. That also catches missing extensions rather than just the PHP version.A regression test could assert that an incompatible runtime exits with
.envunchanged, then verify a clean install on the supported minimum runtime using the same committed lock (withoutcomposer update).Sources: install-cp.sh, Composer check-platform-reqs.
Fix (install-cp.sh): preflight() now runs composer check-platform-reqs --lock --no-dev instead of the major/minor check. It runs before the node/npm checks and before anything is written, and exits 11 on a mismatch. As you said, it checks the lock's exact PHP and extension requirements and ignores config.platform. One side effect: Composer older than 2.3 has no --lock option, so it now fails preflight too.
Regression test (.github/scripts/test-install-cp-platform-reqs.sh, now in CI):
Two details make the test meaningful:
I also updated the vault's Installation Guide to say PHP 8.4.1 or newer, plus the extensions the lock requires.
Meet Nix and Bruce @ https://twobirdsonelesbox.com
My project/stuff page @ https://serveraddict.net
@mikho I checked the updated script and regression test; I haven’t run the containers. The platform check now precedes configure_env_file, and the sodium case checks both the diagnostic and unchanged .env, which distinguishes it from an unrelated exit 11.
One optional addition for the Composer 2.3 minimum you noted: run a compatible PHP runtime with Composer 2.2 and assert exit 11 plus unchanged/absent .env. The current test fetches composer:2, so it doesn’t exercise the unsupported-tooling path. That would protect the “fail before mutation” guarantee if preflight ordering changes later.
Test reviewed.