Changing the sort (or search, category, owner) inside a folder on the
client portal navigated to the top of My files, because the list query
was built without the folder. And opening a folder, or following a
breadcrumb, dropped the chosen sort, because folderUrl() carried only the
folder id. Every portal theme shares the hook, so all four were affected.
The list query now carries the open folder, and folderUrl() carries the
sort when it is not the default (newest first), so default addresses
stay clean. Search and the filters still show a flat list across every
folder, as MyFilesController intends; clearing them returns to the
folder. The staff library is unchanged: there, dropping the folder for a
search is documented intent.
Checked in a browser on a client account: sorting by name inside a folder
stays in it and reorders it, and a folder link from a sorted list keeps
the sort.
Reported by @cookiebaker (#1806)
A new capability, granted by both editions. Self-hosted installs keep zip
downloads as they are. A platform removes it through
PROJECTSEND_CAPABILITIES_DISABLED. The free shared instances do this,
because building an archive holds the zips worker, the disk and a CPU on
a server that thousands of accounts share.
- The three zip routes sit behind capability:downloads.zip, so a
hand-made request gets a 404, not just a missing button.
- BuildZipDownloadJob refuses a build that was queued before the key went
away. The row ends failed and is never stamped as started.
StalledZipBuilds stays quiet when the key is off, so leftover rows
raise no worker banner.
- The zip buttons are hidden. In the portal, the checkboxes and the
selection bar are hidden too, since they exist only to pick files for a
zip. Staff /files keeps its checkboxes, which also drive bulk edit.
- Archives already built are not touched. They expire on the normal
purge schedule.
- A guard test walks the router. It fails if any route that reaches
ZipDownloadsController, or dispatches the build job, lacks the
middleware. No API route builds zips today.
The case goes last in the enum, because the control plane reads keys in
enum order.
The frontend translator replaced placeholders by exact match only:
`:${name}`, nothing else. But the catalogs it consumes are Laravel JSON
catalogs, and Laravel's convention has always been three forms — :name
receives the value as-is, :Name capitalized, :NAME upper-cased. The
backend translator honours all three; fifteen values in lang/nl.json
and one in lang/tr.json already rely on it. Dutch writes "Add :name" as
":Name toevoegen" because the noun opens the phrase there and gets the
capital; Turkish does the same with "Go to page :page" as ":Page
sayfasına git". Through this hook, those sixteen values rendered the
literal ":Name" and ":Page" instead of the replacement — the value was
right for the language and wrong only for the half of the app that
reads it with an exact-match replace.
t() builds the three variants per replacement now, longest placeholder
first — strtr's implicit rule made explicit, so with :name and :names
both in play, :name cannot eat the front half of :names. Ties keep
insertion order, which resolves a fully-colliding key to the as-is
value, the same answer the backend's assignment order produces.
No test accompanies this: there is no JavaScript test runner in the
project, and the PHP suite exercises the backend translator, which was
never wrong. Counter-checked by running both implementations over the
affected catalog values in node — the old replace leaves ":Name
toevoegen" and ":Page sayfasına git" literal, the new one renders
"Bestand toevoegen" and "2 sayfasına git" — plus the existing in-repo
call shapes (":used of :limit", ":name — files"), which come out
byte-identical to before.
useZipDownload sets an interval that polls zip-downloads/{id} every two
seconds until the build reports ready or failed. The only paths that
ever cleared it were those two answers and close() — there was no
unmount cleanup at all, no useEffect in the file. But the pages that
hold the hook are Inertia pages: navigating away unmounts them without
close(), and the interval keeps hitting the endpoint every two seconds
for as long as the tab lives, polling for a download nobody can receive
any more. A zip stuck in pending — the exact case the polling exists
for — polls forever.
Three holes, one leak:
- No cleanup on unmount. A useEffect returning stopPolling closes the
main path.
- An unmount while the store POST is still in flight: its then() runs
after the cleanup already did, and would set a fresh interval on the
dead component. The unmounted flag makes that then() a no-op.
- A second start() while a poll is running overwrote pollRef and
orphaned the first interval the same way. start() stops the previous
poll first now.
No test accompanies this: there is no JavaScript test runner in the
project, and the PHP suite never mounts a component. Verified with
tsc, eslint and prettier, and by reading the two consumers —
files/index.tsx and use-portal-files.ts — both of which only ever
clear the interval through the dialog's onClose today.
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.
ignacionelson