Custom Media Library Development for CMS

The editor uploads one image into five records — the budget is eaten by duplicates, disk grows, pages slow down.

We develop media libraries for CMS to avoid these issues. A centralized repository with smart search and automatic optimization solves the duplicate problem. In one project, a client lost 40% of disk space due to repeated files. After implementing our library, space was freed, and page loading doubled in speed. We use cloud storage on S3. Asynchronous preview generation and presigned URLs reduce load.

How to speed up image upload?

Presigned URL is a technique where the file goes directly from the browser to S3, bypassing the server. The server only generates a temporary link and confirms the upload. This reduces PHP load to zero: even 4K videos upload in seconds instead of hanging on max_execution_time. Server load drops by 5-10 times, saving up to 150,000 rubles per year on infrastructure. This approach eliminates the risk of server overload.

The comparison shows: presigned URL is 5-10 times faster and more secure. We use this method in all projects — it is tested under load of up to 500 simultaneous uploads.

Why should preview generation be asynchronous?

After image upload, we launch a queue (based on Redis) to create previews. The user doesn't wait — in a few seconds all versions are ready.

class GenerateImageConversions implements ShouldQueue
{
    public function handle(): void
    {
        $conversions = [
            'thumb'  => ['width' => 150,  'height' => 150],
            'medium' => ['width' => 800,  'height' => null],
            'large'  => ['width' => 1920, 'height' => null],
            'webp'   => ['width' => null, 'height' => null, 'format' => 'webp']
        ];

        foreach ($conversions as $name => $params) {
            $image = Image::make(Storage::get($this->media->path));
            if ($params['width']) {
                $image->resize($params['width'], $params['height'], fn($c) => $c->aspectRatio());
            }
            if (isset($params['format'])) {
                $image->encode($params['format'], 85);
            }
            Storage::put("media/conversions/{$this->media->id}/{$name}", $image->stream());
        }
    }
}

This approach saves 40% of disk space by converting to WebP and resizing to required dimensions. Conversion reduces traffic by 30–50%, saving up to 50,000 rubles on bandwidth. Contact us — we will select optimal queue settings for your infrastructure.

How to organize search and filtering?

Search in the media library is built on indexing fields: file name, alt text, title, and caption. For standard volumes (up to 50,000 files), a full-text MySQL index is sufficient. If there are more files, we connect Elasticsearch — it provides search in milliseconds even with millions of records. Filters by file type, date, and size speed up navigation.

We will help you choose the right option during analysis.

Media library interface

Main UI capabilities:

• File grid with previews (or list for performance with 10k+ files)
• Filters: file type, folder, date, size
• Search by name, alt text, and custom fields
• Drag-and-drop upload with progress indication
• Folders and subfolders for structuring
• Multi-select and bulk operations (delete, move, edit alt)
• Edit alt, title, caption directly in the library
• Copy URL to clipboard with one click

We build the editor picker widget on React (or vanilla JS for older CMS):

function MediaPickerButton({ onSelect, multiple = false }) {
    const [isOpen, setIsOpen] = useState(false);

    return (
        <>
            <Button onClick={() => setIsOpen(true)}>Choose from library</Button>
            <Dialog open={isOpen} onOpenChange={setIsOpen}>
                <DialogContent className="max-w-4xl h-[80vh]">
                    <MediaLibraryGrid
                        onSelect={(files) => {
                            onSelect(multiple ? files : files[0]);
                            setIsOpen(false);
                        }}
                        multiple={multiple}
                    />
                </DialogContent>
            </Dialog>
        </>
    );
}

Data model

media_files (
  id, original_name, file_name, disk, path,
  mime_type, size,
  width, height,        -- for images
  alt, title, caption,  -- SEO and accessibility
  folder_id,
  uploaded_by,
  created_at, updated_at
)

media_folders (
  id, name, parent_id, created_at
)

media_conversions (
  id, media_id, name,  -- 'thumb', 'medium', 'large'
  file_name, width, height, size, created_at
)

What is included in the work

• REST API for media file management (Swagger documentation)
• Server-side presigned URL generation
• Asynchronous queue processing (up to 50 files per minute on one worker)
• Editor picker widget (React/vanilla) with multi-select support
• Scheduled job configuration for unused file cleanup
• Editor team training (1 hour)
• 3-month warranty on identified bugs

Work process

1. Analysis — study current load, file types, integrations
2. Prototyping — design interface, agree on data model
3. Development — implement backend (Laravel 11 + S3) and frontend (React 18)
4. Testing — load testing up to 500 simultaneous uploads, memory leak checks
5. Deployment — queue setup, CI/CD, monitoring via Grafana

Timeline and cost

A typical project takes 3 to 4 weeks. Cost is calculated individually — depends on integration complexity and required customizations. Order a consultation to evaluate your project.

Typical mistakes when creating a media library

• Generating previews synchronously — user waits, server freezes
• Storing on local disk — grows to hundreds of gigabytes
• No cleanup — junk takes up to 30% of space
• Tight coupling to one CMS — difficult to reuse

We have encountered all these pitfalls in our own projects and guarantee that your media library will be fast, scalable, and user-friendly. Order a turnkey media library development — get a free consultation.

CMS development: solving real editorial bottlenecks, not installing plugins

A news publisher had a WordPress site with 5 editors. Every article required 15 minutes of manual formatting because the WYSIWYG mangled pasted text. After 6 months, the database had 12 different font sizes and 7 custom colors. The redesign would cost $30k just to clean up the mess — and no one would admit it.

We develop content management systems (CMS) that prevent this from day one. Instead of free-form <textarea> hell, we design structured content models, custom WYSIWYG editors using ProseMirror, and media libraries that offload to S3+CDN within two sprints. This is CMS development without shortcuts.

When is headless CMS justified and when not?

Headless CMS (Strapi, Contentful, Sanity) decouples content management from frontend rendering — the API serves content to any client: website, mobile app, smart display. You get omnichannel delivery and a React/Vue frontend that never touches the admin panel. But if your editors need “save and see” preview and you have no separate frontend team, headless costs extra: you must build a preview layer or use a service like Vercel’s preview deployments.

Sanity customises Studio down to the field level — each field is a React component you can replace. Portable Text (its rich content format) ports to any renderer via custom serializers. For complex editorial workflows with multiple authors, Sanity is the best choice. Contentful offers stable cloud infrastructure with a marketplace of extensions, but monthly bills scale with content volume — typical enterprise plans are $500–$2,000/month. Strapi is self-hosted, open source, with a TypeScript API and custom fields via plugins, but you manage the hosting and backups.

Traditional CMS (WordPress, Craft CMS) works when editors need a familiar admin UI and the frontend is rendered server-side. Craft CMS provides Matrix fields, flexible entry structures, and built-in localization — it’s a professional tool for content teams that need granular permissions and versioning.

How do we build a WYSIWYG editor that doesn’t break layout?

The editor is the most complex component — not a <textarea>. The sweet spot is Tiptap, built on ProseMirror. Every element (headings, lists, tables, code blocks, images) is an extension. Collaborative editing via Yjs works out of the box. Lexical (Meta) is more performant (>60fps typing on mobile) but harder to extend. TinyMCE is a corporate standard at 300KB bundle, but it generates dirty HTML on paste — inline styles, nested <span>,   everywhere.

The root cause: pasting from Word. font-family, mso-* properties, empty <span> tags — all leak into the page unless you sanitize. We configure ProseMirror’s pasteRule with DOMPurify to strip everything except allowed tags. Result: clean, semantic HTML that survives a redesign without manual cleanup. Editors save 2–4 hours per week per person.

Media library: from upload to CDN with transformation

Saving files to the server disk is the classic mistake. The disk fills, scaling fails, and CDN becomes impossible. The correct pipeline: upload to S3-compatible storage (AWS S3, Cloudflare R2, MinIO) → CDN (CloudFront, Cloudflare) → on‑the‑fly transformations.

Imgproxy or Thumbor generate any size and format dynamically: https://img.example.com/resize:800:600/format:webp/plain/s3://bucket/photo.jpg. The original lives once, derivatives never occupy disk. Cloudflare Images costs $5 per 100k images, including transformations. Video uploads use Cloudflare Stream or Mux — encode to HLS, adaptive streaming for any bandwidth. Without this, a 1080p video (500MB) loads entirely before play, causing a 5–8 second delay on 3G.

What’s included in media library development

Why structured content outperforms free-form HTML

Free-form WYSIWYG leads to chaos in a year: 7 font sizes, 12 colors, random margins. Redesign requires manual cleanup of thousands of posts. Structured content stores “what” instead of “how”: not <p style="font-size:24px; color:red">Important!</p>, but a callout block with variant: warning. The CMS stores the structure; the frontend decides rendering. Sanity Portable Text, Contentful Rich Text, and Strapi Dynamic Zones all follow this pattern — and it reduces rework by 70% during redesigns.

Work process

1. Analysis of editorial workflows — who edits, how often, what content (articles, landing pages, product data), whether localization is needed.
2. CMS selection — based on scenarios, not trends. We compare headless vs traditional with a weighted matrix.
3. Content model design — record types, fields, relationships, validation rules.
4. Implementation — frontend integration, editor customization, media library, previews.
5. Testing — real‑world scenarios: paste from Word, upload 100+ files simultaneously, load test the API (200 req/s target).
6. Deployment and documentation — editor guide (text + video), API description, access credentials, 1 month support.

Timelines and budget

Budget is calculated individually after an audit. Client examples: a mid‑sized media site saved $40k/year by eliminating manual formatting; an e‑commerce platform reduced time‑to‑publish by 60% with a headless Sanity setup. Contact us for a free project estimate.

What you get after delivery

• Working CMS with configured access rights (admin, editor, reviewer)
• Full content model documentation and API reference
• Editor training documentation (text + video)
• Code covered by tests (PHPUnit for Laravel, Jest for JS)
• 1 month post‑launch support with SLA

Our experience and guarantees

Over 40 completed CMS projects — from small editorial sites to enterprise media portals with 200k daily unique visitors. We use licensed tools (Sentry for error monitoring, SonarCloud for code quality) and guarantee zero critical bugs at launch. All code is version‑controlled and deployable via CI/CD.

For your specific needs, contact us to discuss requirements. We’ll provide a technical proposal within 2 business days.