When writing articles, the most annoying part is often not the text.
It is the images.
An image needs to be compressed, converted, uploaded, copied, and then inserted back into Markdown. Doing this once is fine. Doing it ten times becomes noise.
So ByteForge Studio needs a smoother image workflow.
Basic Idea
When writing, images should still be allowed to stay local first.
For example:
After the article is finished, a local script can run. The script scans the image, compresses and converts it, uploads it to R2, and replaces the local path in the article with the final online address.
This way, writing does not have to be interrupted again and again.
Three Image Layers
One image should not have only one version.
List pages need small images. Article bodies need standard display images. The original file should only be opened when someone really wants to inspect details.
The plan is to split each image into three versions:
thumb: thumbnail, used on home cards, lists, search results, and related posts.display: standard display image, used in article bodies and asset detail pages.original: original file, used only for viewing the source image or downloading.
This makes pages faster and keeps mobile pages from loading huge original images by default.
R2 Should Only Store
R2 is suitable for image hosting and large-file storage, but all management pressure should not be thrown onto the R2 dashboard.
The better shape is:
- R2 stores final images and large files.
- A local script handles conversion and upload.
- Markdown keeps only the final reachable image address.
- The local repository keeps only necessary small images, default images, and temporary backups.
This keeps the project repository from becoming heavier and heavier.
Deletion Should Be Careful
After a successful upload, the local original should not be deleted immediately.
The safer approach is to move it into an archive directory first. After confirming that the website displays correctly, it can be cleaned manually.
For example:
media/archive/This looks a little slower, but it avoids accidental deletion.
What the Future Script Should Do
The script should at least do several things:
- Scan local image references in Markdown.
- Generate thumbnails, display images, and original-file records.
- Upload processed files to R2.
- Replace local paths inside articles.
- Generate a processing report.
- Clean local images only after confirmation.
The final goal is not complexity.
It is to reduce repeated actions.
When writing, just write.
Let the tool handle the images.
