johnnyq 69fd43051f Keep collations at utf8mb4_general_ci going forward: functions.php now ends by calling databaseConnectionCollation, which runs SET collation_connection = 'utf8mb4_general_ci' on the connection config.php opened, so a string the server makes itself, CAST(x AS CHAR) for one, matches the tables where on MySQL 8 it came out utf8mb4_0900_ai_ci and failed beside a column with Illegal mix of collations, on a new install as much as an upgraded one; only the collation is set and not the character set, no SET NAMES and no mysqli_set_charset, because on a server that defaults to latin1 the connection has always been latin1 and changing it shows every accented letter already stored as two wrong ones, where setting collation_connection alone leaves what is stored and what is stored after the same; admin/database_updates.php calls databaseCollationRepair after a run that applied at least one database update and finished, so a table a migration creates without a COLLATE is given the collation db.sql has in the same run, with what it changed and what it could not going to App Logs and to the output of scripts/update_cli.php, a table it cannot change left as it was and never failing the update, and a run that stops at a failed migration leaving this for the run that finishes; run on MySQL 8.0 and MariaDB 10.11, on a latin1 server default and through update_cli.php --update_db with a migration written as 2.4.1 was; CONTRIBUTING.md and the 26.11.7 changelog section say so

2026-11-11 20:52:46 -05:00

..

custom

Copy crons from /scripts to /cron, added custom directories for api/v1/, /setup, /cron and /scripts

2025-10-07 13:55:54 -04:00

.htaccess

Enhance .htaccess rules

2026-08-03 17:51:04 +01:00

restore_cli.php

Implemented Check for updates which removs the last shell exec from web ui, and reimplemented db_update switch to update_cli.php

2026-08-26 23:38:23 -04:00

setup_cli.php

Set up a hosted instance and connect it in one command - Add Instance takes the address it will have, and the instance page gives a ready setup_cli command with the connection code and the client's company name, address, phone, website, tax ID, currency and primary contact as the first admin; setup_cli gains --manager-code and --manager-required (connects after setup, writes the managed line to config.php, exits 3 if it set up but could not connect), --ask-missing, --generate-password, --json and ITFLOW_SETUP_ environment variables for any option, and shows the cron job as a crontab line and for a hosting panel with the full PHP path; Managed Instances shows a connected instance whose cron has never run as Waiting for its cron job with the command to add, and the Managed Instances job says so in its notification; new managedSetupCommand(), the cron command in the instance report and the waiting state in managedInstanceHealth(), changelog updated

2026-11-06 14:29:27 -05:00

update_cli.php

Keep collations at utf8mb4_general_ci going forward: functions.php now ends by calling databaseConnectionCollation, which runs SET collation_connection = 'utf8mb4_general_ci' on the connection config.php opened, so a string the server makes itself, CAST(x AS CHAR) for one, matches the tables where on MySQL 8 it came out utf8mb4_0900_ai_ci and failed beside a column with Illegal mix of collations, on a new install as much as an upgraded one; only the collation is set and not the character set, no SET NAMES and no mysqli_set_charset, because on a server that defaults to latin1 the connection has always been latin1 and changing it shows every accented letter already stored as two wrong ones, where setting collation_connection alone leaves what is stored and what is stored after the same; admin/database_updates.php calls databaseCollationRepair after a run that applied at least one database update and finished, so a table a migration creates without a COLLATE is given the collation db.sql has in the same run, with what it changed and what it could not going to App Logs and to the output of scripts/update_cli.php, a table it cannot change left as it was and never failing the update, and a run that stops at a failed migration leaving this for the run that finishes; run on MySQL 8.0 and MariaDB 10.11, on a latin1 server default and through update_cli.php --update_db with a migration written as 2.4.1 was; CONTRIBUTING.md and the 26.11.7 changelog section say so

2026-11-11 20:52:46 -05:00