Updating had a numbered list inside INSTALL.md and a code block in the
dashboard, and between them they were missing the step that decides
whether an update works at all.
Rehearsed both paths end to end against a real 2.0.0 install before
writing any of this down. On Docker the whole update is `docker compose
pull && docker compose up -d`: the entrypoint waits for the database,
migrates, ensures the roles, and starts the workers, and it does not
start nginx until that finishes — so a failed migration is a container
that stays down rather than a half-updated site taking traffic. The
generated APP_KEY on the storage volume is left alone. Verified: 69
migrations to 73, key unchanged, data intact, healthcheck healthy.
The manual path is where the gap was. Replace the files, run the four
documented commands, and the site still serves the old version: with
`opcache.validate_timestamps=0` — what every production guide recommends,
and what our own image ships — PHP never re-reads a file it has already
compiled. The database is on the new version, every visitor is on the
old code, and `php artisan` cheerfully reports the new version the whole
time you are trying to work out why. Reproduced exactly that, then
watched a php-fpm reload fix it.
UPDATE.md is now the whole procedure for both, INSTALL.md keeps the short
sequence with the reload added, and the in-app instructions gained the
same line — in the code block, which is not translated, so no locale is
left saying something different.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
The retake was 2720x2664 — near square, because it fitted both columns
of widgets end to end. Next to files.png and portal.png, both 16:10, it
read as a different kind of picture and took three times the vertical
room in the README for it.
Same 1360x850 at 2x the other two use. The point was never that every
widget be legible in one frame — only that they all be switched on, so
the installation looks like one somebody uses rather than one nobody has
configured.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
The old one photographed a development database: 58 files totalling
7.3 MB, "template-business" and "new-editor" among the largest, two
clients in the storage table, and eight identical "Logged in" rows as
the recent activity. It showed the layout and none of the point.
This one is a plausible installation — real-sounding client
organisations against their quotas, files with names and sizes somebody
would recognise, a month of uploads and downloads with a working week's
rhythm in it, and activity that says what people did rather than that
they arrived. Every widget is on, in the two-column layout, so the
picture also answers "what does this thing actually track".
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Client file sharing, rebuilt from the ground up: a private area per
client, resumable uploads, folders, groups and categories, sharing with
expiry dates and download limits, comments, file versions, an activity
log, a REST API, and sixteen languages.
This repository begins here. ProjectSend 2 was developed privately, and
that development history is not published — the previous generation
remains available, with its own history, at projectsend/legacy.
Free software under the GNU General Public License v2, or (at your
option) any later version.
Ignacio Nelson