Download the PHP package survos/iiif-bundle without Composer
On this page you can find all versions of the php package survos/iiif-bundle. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download survos/iiif-bundle
More information about survos/iiif-bundle
Files in survos/iiif-bundle
Package iiif-bundle
Short Description PHP 8.4+ Symfony bundle for generating IIIF Presentation API 3.0 manifests
License MIT
Informations about the package iiif-bundle
SurvosIiifBundle
PHP 8.4+ Symfony bundle for generating IIIF Presentation API 3.0 manifests.
@todo: make sure it works with https://manuscrits-france-angleterre.org/view3if/?target=https://gallica.bnf.fr/iiif/ark:/12148/bpt6k9907264/manifest.json&page=2
Installation
Fetch strategy (cache/retry)
ManifestLoader fetches through survos/fetch-bundle's PersistentFetcherInterface.
- Cache: keyed by manifest URL, cached forever in a SQLite pool at
var/data/fetch_cache.db— untilforget()/force_fetch. Fine for IIIF manifests, which are effectively static once published; if a source republishes a manifest at the same URL with different content,forget($manifestUrl)is needed to see the update. - Retry: up to 5 attempts, full-jitter exponential backoff (200ms base, 10s cap), on transport errors, HTTP 429, and 5xx.
- Local
.wiphosts are routed through the Symfony CLI local proxy automatically (fetch-bundle'sWipProxy) — this replaced a bundle-localstr_contains($url, '.wip')check.
Before 2026-08-08 this used a raw HttpClientInterface with no caching — every manifest render
re-fetched from the source.
Quick Start
Source images vs. IIIF endpoints — the IiifUrl resolver
ItemField::IIIF_BASE (iiifBase) is overloaded. For most providers it is just
the largest non-tiff source image — a plain, fetchable URL that imgproxy resizes
(Fortepan, Smithsonian IDS, Walters, Cleveland…). The shared NormalizeFallbackListener
(data-bundle) even sets iiifBase = largeImageUrl for every row. Only genuine IIIF
sources (e.g. Digital Commonwealth) store an actual IIIF Image API base.
Survos\IiifBundle\Service\IiifUrl is the single place that distinguishes them and
turns either into a fetchable image URL:
Never decide this by file extension. The old heuristic ("no extension ⇒ it's a IIIF
base, append /full/max/0/default.jpg") breaks both ways:
- extensionless direct images — Smithsonian IDS
…/deliveryService?id=Xgot…?id=X/full/max/0/default.jpg(404 / "Invalid URL"); - already-an-image URLs — Fortepan
…/fortepan_266.jpggot…/fortepan_266.jpg/full/max/0/default.jpg(dead link).
Resolve once, at normalize — not at sync/render
Image-URL resolution should happen once, during normalization, yielding a concrete
fetchable imageUrl. Everything downstream consumes that known URL:
media:synchistorically expected raw URLs only — it ships known URLs to mediary and must not deriveiiifBase + /full/max/…itself.- Read models / templates should prefer the pre-resolved
imageUrl.
Append sites — audit (June 2026)
Each of these re-derives the image URL instead of consuming a resolved one, guessing
IIIF-ness independently. They should call IiifUrl (better: consume the normalize-time
imageUrl):
folio-bundleRow::getThumbnailSource,FolioChatHit::thumbnailUrl,FolioAiPromptBuilder— migrated toIiifUrl.media-bundleMediaSyncItem(url/preferredUrlfromiiifBase),MediaShow::fullSizeUrl— still derive;media:syncshould take raw URLs only.meili-bundlesearch-card template (TemplateController) — still appendsiiifBase ~ '/full/' ~ size.iiif-bundleManifestSummaryExtractor,IiifExtension,IiifSize— these build from a genuine IIIF base (parsed manifest / explicit caller), so appending is correct.
Two NormalizeFallbackListeners set iiifBase today (import-bundle, guarded on /iiif/;
data-bundle, unconditional from largeImageUrl) — these should converge into one
source-image resolution that also emits the concrete imageUrl.
Output Example
Model Classes
All model classes implement JsonSerializable and use public properties with no boilerplate getters/setters.
Core Resources
AbstractResource- Base class with common properties (id, type, label, summary, metadata, rights, etc.)Manifest- IIIF Manifest with items (Canvases) and structures (Ranges)Collection- Collection of Manifests or other CollectionsCanvas- A canvas that contains annotations (images, OCR text)Range- For table of contents / structural navigation (TOC)AnnotationPage- Container for AnnotationsAnnotation- W3C Web Annotation with motivation, body, and target
Content/Body Classes
ResourceItem- Image, Video, Audio with id, type, format, serviceTextualBody- Inline text content (OCR text, descriptions)
Supporting Classes
Service- IIIF Service referenceImageService3- Convenience class for Image Service 3Thumbnail- Simplified image referenceLabelMap- Helper for language map constructionMetadataEntry- label/value pair for metadata
Enums
Motivation- painting, supplementing, commenting, tagging, etc.ViewingDirection- left-to-right, right-to-left, top-to-bottom, bottom-to-topBehavior- paged, continuous, individuals, auto-advance, etc.
Manual Construction
You can also construct manifests manually without using the builder:
Requirements
- PHP 8.4+
- Symfony 7.3+ / 8.0+
Viewers
The <twig:iiif:viewer> Twig component offers two embedded viewers:
viewer="openseadragon"(default) — deep-zoom of a single image, or paging through plain image URLs (no IIIF Image API tile server needed).viewer="diva"— the diva.js 7.2.6 page-turning document viewer (built on OpenSeadragon), for multi-page documents. It parses IIIF Presentation 2.x and 3.x and re-dispatches diva's page/zoom/loading events as bubblingiiif-diva:*Stimulus events so a host page can show per-page OCR or tags.
See docs/diva-viewer.md for the diva integration details
(OpenSeadragon peer dependency, constructor settings, and the event wiring).
References
All versions of iiif-bundle with dependencies
symfony/framework-bundle Version ^8.1
symfony/serializer Version ^8.1
survos/kit-bundle Version ^2.5
survos/fetch-bundle Version ^2.5