Frequently Asked Questions

You should run a scan whenever files or content change.

Recommended times include:

• After uploading many files
• After removing documents from pages
• After a site migration or bulk update
• On a regular schedule for maintenance

Scanning reviews files and site content.

Scan time depends on:

• How many files exist
• How many pages the site has
• Server performance

Longer scan times are normal for large sites.

Common reasons include:

• The file was added after the last scan
• The file was deleted
• The file is in a system folder that is not tracked

Running a new scan usually resolves this.

These labels describe how a file or asset was added (shown in the "Location" column).

• Upload: Added through a page or form using Drupal's managed file system  
• Media: Added through the Media Library  
• Server: Added directly to the server (e.g., via FTP/SFTP) in Drupal’s file system (such as /sites/default/files), outside the Media Library or upload forms  
• External: Linked from another website (e.g., Google Docs, YouTube)

All items are tracked the same way in the inventory. External items are included for awareness, even though they are not controlled by the site.

Yes, if you have permission and the file is not in use.

Before deleting:

• Remove the file from all pages
• Run a scan to confirm it is no longer used

Deleting a file permanently removes it from the site.

Files can be referenced in places that are not obvious.

Examples include:

• Draft or unpublished content
• Older page versions
• Blocks or reusable components
• Menu items

Use the inventory's usage information to locate where the file appears.

No. The inventory reflects the last scan.

After replacing a file:

• Run a new scan to update the inventory
• Archived files may show warnings if they were modified

System generated files such as styles, thumbnails, and scripts are excluded automatically.

You do not need to manage these.

The inventory returns to the state it was in at the time of the backup.

After restoring:

• Run a new scan
• Review archive warnings
• Confirm file usage is accurate

No. The Digital Asset Inventory does not track SVG code that is embedded directly in HTML content (inline SVGs).

What counts as an inline SVG:

• SVG code pasted directly into CKEditor or a text field
• SVG elements rendered by a theme template
• SVG icons included via a Twig {% include %} or {{ source() }} function

These are part of the page markup, not separate files, and are not detected by the scanner.

The inventory tracks SVG images that exist as files in Drupal.

Key distinction: If the SVG has a file URL (for example, /sites/default/files/logo.svg), it is tracked. If it is embedded directly as markup, it is not.

Inline SVGs are not separate digital assets—they are part of the HTML document itself.

Technical reasons:

• No file to reference or track (no URL, no file entity)
• The SVG code is stored in the database as part of the content field value
• Scanning would require parsing and extracting markup fragments, which is outside the module's scope

Practical reasons:

• Inline SVGs are typically small icons or decorative elements
• They often come from theme templates, not content entry
• Tracking them would create noise in the inventory without clear compliance benefit

Yes. All SVG images—whether inline or file-based—must meet WCAG 2.1 AA accessibility requirements when used as meaningful content.

Decorative SVGs

• Add aria-hidden="true" to hide from assistive technology
• Ensure they do not convey information users need

Meaningful SVGs

• Include a <title> element to provide an accessible name
• Use role="img" when appropriate
• Ensure sufficient contrast for any text or shapes within the SVG

Note: The Digital Asset Inventory does not track inline SVGs, but your accessibility review process should still include them.

Upload an SVG file when:

• The image is reused across multiple pages
• You want it tracked in the Digital Asset Inventory
• Content editors need to manage or replace it
• The SVG is large or complex
• You need version control or audit trail

Use inline SVG when:

• It's a small icon (under 1KB)
• It's theme-controlled, not content-controlled
• You need to style it with CSS (fill, stroke colors)
• Performance is critical (avoids HTTP request)
• The SVG is purely decorative

Recommendation: For content-managed images that need tracking and potential archiving, upload as a file. For theme decorations and UI icons, inline embedding is appropriate.

Yes. YouTube and Vimeo videos added through the Media Library's "Remote Video" media type are tracked in the inventory.

How remote videos appear:

• Location: Media
• Asset Type: YouTube or Vimeo (detected from URL)
• Category: Embedded Media
• File Size: "-" (dash, since there's no local file)

Note: Remote videos added via Media Library are different from YouTube URLs pasted directly in content:

Both methods are tracked, but Media Library videos have additional metadata like the media title and can be managed through the Media Library interface.

The file size column shows "-" (dash) for assets that don't have a local file:

• External URLs - Google Docs, YouTube links pasted in content, etc.
• Remote video media - YouTube/Vimeo added via Media Library
• External resources - Any asset hosted on another server

These assets are tracked for compliance purposes, but since there's no local file, there's no file size to report.

When you view the usage details for any asset, you'll see an Embed Type column that shows how the asset is embedded in content. This column appears for all asset types (documents, images, videos, audio, external assets):

For video and audio assets specifically, additional Accessibility Signal columns show detectable features:

Signal values:

• Yes - Feature detected in this usage
• No - Feature not found in this usage
• Unknown - Cannot determine (e.g., external/iframe content)
• — (dash) - Not applicable to this media type

Note: The Controls, Captions, and Transcript columns only appear for video and audio assets. Image assets show an Alt Text column instead. The Embed Type column appears for all asset types.

Yes. The File Name search field searches both file names and URLs. This means you can find external assets by typing part of their URL.

Examples:

• Type "docs.google.com" to find all Google Docs, Sheets, and Slides
• Type "youtube" to find all YouTube video assets
• Type "dropbox" to find all Dropbox links
• Type "drive.google.com" to find Google Drive files

This is useful for finding all external assets from a particular service or domain.

The scanner detects files referenced through several types of HTML tags in text content. The scanner uses a universal sites/[^/]+/files pattern that works across all Drupal installations (default, multisite, Site Factory). Examples show the default /sites/default/files/ path:

The scanner also detects files referenced through:

• File and image fields on content
• Media reference fields
• Link fields with URLs
• Navigation menu links

Files that are only referenced in theme templates, custom code, or JavaScript-loaded content are not detected by the scanner.

Orphan references may temporarily appear after content is deleted. Drupal cleans up unused paragraph components in the background.

If a scan runs before that cleanup completes, the orphan references will appear. Once Drupal finishes removing the unused components, they will no longer show in future scans.

This is expected behavior. The inventory always reflects the current state of the site at the time of the scan.