AttachmentStore

Corex\Security\Upload\AttachmentStore · class · Core layer

The one place an uploaded file becomes something CoreX can refer to later (spec 081, FR-004). Before this there was no upload handling in the framework at all — a repo-wide search for wp_handle_upload found two comments describing one and no code. UploadValidator’s docblock claimed “the boundary store re-checks the real MIME” about a store nobody had written, and corex-careers validated a CV and then discarded it. This is that store. ## The client’s declared type is not evidence UploadValidator checks $file['type'], which the browser supplies and anybody can set. That is worth doing — it rejects the honest mistakes cheaply — but it is not the check that matters. Here the file’s content is read, through WordPress’s own wp_check_filetype_and_ext(), and a file whose bytes disagree with its name is refused. A .pdf that is really a .php fails here or it fails nowhere. ## Where the file goes Into {@see ProtectedUploads::DIRECTORY}, not the public uploads root, and the attachment post is created with post_status => 'private'. It is still a real attachment, so addons/corex-media’s WebP pipeline and everything else hooked to wp_generate_attachment_metadata still applies — the reason this is a media-library attachment rather than a bespoke table.

Public API

__construct(UploadValidator $validator)

store(array $file, string $context): AttachmentResult

Store one uploaded file and return its attachment id.

forget(int $attachmentId): bool

Remove a stored file and its attachment. Only touches attachments this store created: without the check a caller could hand this an arbitrary id and delete a site’s logo.