Trongate PHP Framework Docs
Introduction
Basic Concepts
Understanding Routing
Intercepting Requests
Module Fundamentals
Database Operations
Templates
Helpers
Form Handling
Form Validation
Working With Files
Image Manipulation
Working With Dates & Times
Language Control
Authorization & Authentication
Tips And Best Practices

Where to Store Images

In a Trongate application, image storage is a design decision - not a personal preference. Every image must live either inside a module or in the public directory, and the correct location is determined by ownership and scope.

Store images inside a module only when they are owned and rendered exclusively by the module.

Storing Images Inside a Module

An image belongs in a module when it exists because the module exists. If removing the module would render the image useless, that image is module-owned.

Use Module Storage When the Image Is:

Content-bound to a module:

  • Product images belonging to shop items
  • User profile pictures managed by a users module
  • Featured images for blog posts
  • Category thumbnails used exclusively by a news module

Generated or transformed by the module:

  • Cropped profile images produced by an editor
  • Watermarked images created during processing
  • QR codes generated for tickets, invoices, or downloads

Specific to a single feature’s interface:

  • “Hot Topic”, “Pinned”, or “Solved” icons in a forum
  • Status badges such as “Draft”, “Published”, or “Archived” in a CMS

Third-party branding used in a narrow context:

  • Payment provider logos shown only during checkout
  • Social network icons used only within a share widget
  • Shipping carrier logos displayed only after purchase

Module Storage Configuration

Why Module Storage Works:

  • Clear ownership: The module controls its own assets
  • Portability: The module can be moved or reused intact
  • Isolation: Assets do not leak into unrelated features
  • Organisation: Code and content stay together

Storing Images in the Public Directory

An image belongs in the public directory when it represents the application as a whole or is used by more than one module.

Use Public Storage When the Image Is:

Part of site-wide branding:

  • Main site logo used in headers, footers, emails, or PDFs
  • Logo variations for light, dark, or icon-only contexts
  • Favicons and app icons

A global user interface element:

  • Navigation icons shared across modules
  • Reusable UI symbols such as search, menu, or close icons
  • Generic buttons or decorative separators

Used for layout or visual structure:

  • Background images appearing across multiple pages
  • Hero images for landing or marketing sections
  • Textures, gradients, or decorative patterns

Consumed outside standard page rendering:

  • Images embedded in emails
  • Images used in PDFs or downloadable files
  • Open Graph and social preview images

Public Storage Configuration

Why Public Storage Works:

  • Shared access: Multiple modules can reference the same asset
  • Simpler URLs: No module asset trigger required
  • Clear intent: Assets represent the entire site

The One Question That Settles Every Decision

When you are unsure where an image belongs, ask one question:

“If I remove this module, does the image still make sense?”

If the answer is no, store the image inside the module. If the answer is yes, it belongs in the public directory.


Quick Decision Checklist

Store in a MODULE if:

  • ✅ The image is created, uploaded, or processed by one module
  • ✅ The image represents content owned by that module
  • ✅ Removing the module makes the image irrelevant

Store in PUBLIC if:

  • ✅ The image is shared across modules
  • ✅ The image represents site-wide branding or UI
  • ✅ The image appears in layouts, emails, or downloads