Drupalwoo ☉

Using Drupal's Media Library for video and document management

Drupal's Media Library gives editors a shared catalogue instead of asking every content team to upload the same asset again. A media item is a Drupal entity, so its file, title, metadata and access rules travel with it wherever it is referenced. That separation matters on busy sites: marketing pages, news articles and resource hubs can point to one controlled asset rather than several competing copies.

Video and files need different source fields, display treatment and permission checks. Videos may be uploaded MP4 files, linked from YouTube or Vimeo through an oEmbed source, or supplied by another approved provider. Documents may include PDFs, Word files, spreadsheets or accessible attachments. The Media Library interface provides browsing and selection, while the media type and its source field determine what happens during upload or embedding.

A sound implementation starts with the publishing problem, not the upload screen. Decide which assets must remain editable, who may reuse them, how old records are retired and whether external hosting is acceptable. Then design the library around those rules. This avoids a familiar Drupal trap: a technically valid media type that becomes difficult to search, govern or integrate with editorial workflows.

Plan the right media types

Media types define the behaviour of the library, so create a small set that reflects how the organisation publishes rather than one generic catch-all type. In Structure > Media Types, add types such as Video, PDF document and Supporting file. A dedicated Video type can expose fields for a transcript, poster frame and source, while a document type can carry a document category, review date and accessibility notes. Reuse the same type for similar assets to keep selection forms manageable.

The source field is the technical control point. A File source accepts uploads and creates a managed file; an oEmbed video source can create an external embed after you configure an approved provider; and version-specific media-source plugins may support additional remote services. These options are not interchangeable. An uploaded video is delivered from your Drupal site, whereas an oEmbed item depends on the provider remaining available and on its privacy settings. Test each source against the exact fields and edit form used in production.

Choose the source before designing the visible fields. YouTube and Vimeo suit editorial teams that already manage video channels, while self-hosted MP4 delivery gives greater control but adds storage, bandwidth, transcoding and captioning work. For documents, self-hosted files simplify permission design and auditing; a link to a file in a corporate system may be better when many records already live in SharePoint or OneDrive. Treat Media Library as an entity layer, not a complete digital asset management suite: optical character recognition, automatic video transcoding, version lineage and advanced rights expiry usually require contributed modules or external services.

Structure the library for reuse

Library structure determines whether editors can find an asset under pressure. Add a controlled taxonomy vocabulary for media categories, then use it consistently across video, documents and files. Useful facets might include content area, document type, campaign, audience and year. Keep terms shallow: a category such as Governance belongs at one level, while Sydney operations and Melbourne operations can be separate terms if both recur. Free-text tags are useful for exceptions, but they should supplement rather than replace the taxonomy.

Names are another search layer. Set a naming convention that includes the asset type, subject and version, for example “Policy – Remote Work – v3”, while retaining the original filename inside the managed file. Editors work with a clear title; administrators can still trace the upload to its source. Restrict title changes where version identity matters, and avoid relying on a timestamp alone because the same video can be attached to several pages.

Descriptive metadata should be filled when the media is created, not reconstructed during a campaign launch. A short description helps editors understand what an asset contains, while fields for owner, review date and licence or rights status support governance. For an Australian publisher, use Australian English consistently and display dates as day/month/year to remove ambiguity for teams in Sydney, Melbourne and Brisbane. Include a status such as approved or needs review if media must pass through a checking routine.

Build a consistent editorial workflow

A library works best when creation, approval and retirement are separate responsibilities. The person who uploads a file may not be the person who confirms factual accuracy, accessibility or usage rights. Give authors permission to add media, editors permission to select it in content, and reviewers a defined route for checking sensitive records. Record the owner and next review date so responsibility does not disappear into a shared inbox.

The Media Library dialog can limit users to media they are permitted to view, but it is not a complete publishing workflow. Combine it with sensible media permissions, restricted content types and an approval step in the destination content. Editors should see the media title, type, description and status before selecting an item. If a damaged or superseded file is found, mark it unavailable and update affected pages rather than replacing the entity silently.

Many Australian schools and councils publish learning materials and policy documents alongside public web content. Their teams often work across Microsoft 365, Moodle or Canvas, so document naming, shared-drive links and download behaviour need consistent rules. A central Drupal library is especially useful when the same training video or template is reused across several branded pages. It also gives administrators one place to assess accessibility and rights across those channels.

Protect and present documents

Treat uploads as untrusted input. Configure the file field with an allowlist of extensions and corresponding MIME types, a sensible maximum size, and filename handling that prevents executable files from being served as active content. PDF is convenient for documents, but it does not remove the need for malware scanning, accessibility remediation or review of embedded scripts. Check server upload limits as well as Drupal configuration so large training videos do not fail with a generic form error.

Permissions need two layers. Drupal media permissions control who can create, update or select a media entity; file-access rules control who can retrieve the underlying document. A protected file that is linked directly may bypass entity-level checks, so secure download routes and access-aware templates must be used deliberately. Avoid relying on obscure URLs as security. Restrict the file directory, use non-guessable storage paths, and never place confidential documents in a publicly served directory. For Australian organisations handling personal information, align retention and access with the Privacy Act 1988 and applicable Australian Privacy Principles.

Presentation is separate from access. For display-only string transformations, such as creating a clean document label from an uploaded filename, the Drupalwoo guide to a custom Twig filter provides a useful pattern. Such filters must not decide whether a user may download a file, and their output should be escaped for the context. Always test the document link with anonymous, authenticated and restricted users, checking both the response and the browser's handling of PDF or Word downloads.

Configure video from source to page

Start with the source field and the intended player. For YouTube or Vimeo, configure the relevant oEmbed provider, restrict provider hosts where required, and test that the URL is transformed into a permitted embed. The provider controls the thumbnail, playback page and some privacy behaviour, so an oEmbed preview is not identical to a file stored in Drupal. For uploaded MP4, provide a poster image, a WebVTT caption track and a fallback link. Drupal does not automatically transcode every uploaded format into a browser-friendly video stream.

Captions and transcripts should be part of asset acceptance rather than an optional enhancement after publication. YouTube and Vimeo can use captions managed on their platforms, while uploaded video needs a caption file and a player configuration that exposes them. The same principle applies to documents: a tagged PDF may still need manual checks for reading order, headings and meaningful alternative text. Record any manual accessibility decision in the media description so a later editor understands why the asset was approved.

Video is often attached to a resource rather than published as a standalone article. Reference the media entity from a content type such as Resources, Events or News, then let the display template choose the aspect ratio, controls and fallback message. A team in Sydney may schedule a campaign launch at 9:00 a.m. AEDT while colleagues in Melbourne and Brisbane begin work at different points in daylight-saving time; publishing dates and embargoes should therefore be stored clearly and reviewed against Australian Eastern and Central time zones. That removes a common source of errors in a country where one campaign can involve teams in several time zones.