Investigate our options for putting file attachments on kuma wiki pages. Create follow-up bugs for implementation.
Whiteboard: u=developer c=wiki p= → u=developer c=wiki p=2
The ideal way to do this is going to be similar to how we handle demos already; we probably can't just directly re-use the existing code, but writing something like it should not be terribly difficult. As jsocol reminds us, if we do any custom field types like we did with demos, we need to be careful to maintain Django's own ability to swap out backends for multi-homing. Architecture-wise, we're probably looking at two new models plus the migration script: one model to represent the file in a high-level way, one to actually store the current revision of the file, and possibly some sort of intermediary between the two. Migration-wise, this probably isn't too terribly hard, since under the hood Django (in the default backend) just wants to store the filesystem paths. Tricky things to consider: we'll have to do some file-management stuff at some point, because Django past 1.2 does not clean up orphaned files, so we'll either have to live with the occasional orphan or come up with our own cleanup facility for them. And if/when we switch to something like multi-homed setup with S3, we'll have to move the physical files somehow.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Component: Docs Platform → Editing
Product: Mozilla Developer Network → Mozilla Developer Network
You need to log in before you can comment on or make changes to this bug.