Disk to URL plugin migration
With fylr 6.35, the plugins shipped on disk become url plugins installed from their own releases. What the upgrade will do, and what to check.
The essentials
This page is only about the plugins fylr shipped on disk, inside the distribution. A plugin you installed yourself from the marketplace —
fylr-plugin-sequence,server-pdf,ai-metadataand everything else in the plugin overview — is already a url plugin and is not affected: it is not listed here, and the upgrade does not touch it.The shipped plugins become url plugins, installed from their own releases. The upgrade converts every enabled plugin that has a successor; the few without one are removed.
Your configuration and permissions move with a plugin, including where the plugin is renamed. There is nothing to write down before the upgrade.
A distribution plugin that is switched off at that moment is removed instead of converted. Switch it on before you upgrade if it should stay — off again afterwards is fine.
If your fylr cannot reach the internet, the plugin manager will mark the plugins it could not download and offer to install them as ZIP — your browser fetches the release and hands it to fylr.
If you use the Drupal, TYPO3 or WordPress connector, you must obtain an updated fylr license that enables it — without that grant the plugin cannot be enabled after the upgrade. Contact Programmfabrik before you upgrade.
Until now, every fylr release shipped a fixed set of plugins inside the distribution: type disk, listed by path in fylr.yml, impossible to remove, and updated only by the next fylr release. From fylr 6.35 on, fylr ships no plugins. Each plugin comes from its own release instead — with its own version, its own release notes and its own update cycle.
fylr 6.35 has not been released yet — this page describes the upcoming upgrade. The mapping below reflects the current plan; the final mapping ships with the release.
The three kinds of plugins
url — fylr downloads the plugin from a release URL and keeps it up to date, following the update policy shown in the plugin manager. This is what the shipped plugins become.
zip — a package uploaded by an administrator. It stays exactly as uploaded until a new ZIP replaces it — the choice when fylr cannot reach a release URL.
disk — loaded from a server directory via
plugin.pathsinfylr.yml. From 6.35.0 on, this is only for developing and running your own plugins; fylr no longer installs anything this way itself.
What the upgrade will do
Every enabled plugin from the distribution that has a successor in the table below becomes a url plugin pointing at the successor's release — enabled as before, and configured as before. Where a plugin is renamed, its configuration, its granted system rights and any export that uses it are moved to the new name by the upgrade.
Disabled distribution plugins are removed. Their stored configuration is kept and applies again if a plugin of the same name is installed later.
Plugins you installed from your own directories are not touched. The upgrade recognises a distribution plugin by its name and by its location inside the fylr Docker image (
/fylr/files/plugins/easydb/); a plugin loaded from any other directory is left exactly as it is.Distribution plugins with no successor are removed — they are obsolete, or their function is part of fylr itself by now. See the second table.
After the restart, each converted plugin downloads its release once and keeps itself up to date from then on. It is installed from exactly the release the plugin manager offers for a fresh installation — a migrated plugin and a newly installed one are the same package.
The downloads need outbound HTTPS to github.com, *.githubusercontent.com and programmfabrik.github.io. If your instance cannot reach these hosts, see Installations without internet access.
How plugins will migrate
The names in the table are the internal plugin names, as shown in the plugin manager.
custom-data-type-gvk
unchanged — the same custom type, delivered by the repository fylr-plugin-custom-data-type-k10plus
custom-data-type-link
unchanged — delivered by fylr-plugin-custom-data-type-weblink
easydb-barcode-display
new name — the successor is a different plugin: your masks and PDF templates are re-pointed to it automatically, see below
easydb-custom-mask-splitter-detail-linked-plugin
new name
easydb-export-transport-ftp-plugin
unchanged — delivered by fylr-plugin-export-transport-ftp; saved export transports keep working
easydb-hijri-gregorian-converter
new name — ported to fylr; masks using its splitter keep working
The custom data types cerlthesaurus, dante, geonames, georef, getty, gn250, gnd, goobi, gvk, iconclass, nomisma and tnadiscovery share a library plugin, commons-library, which fylr installs alongside them; it does nothing on its own and needs no configuration.
The Drupal, TYPO3 and WordPress connectors become licensed plugins: enabling one requires a fylr license that grants it by name. If you use one of these connectors, you must obtain an updated license from Programmfabrik that enables it — do this before you upgrade, or the plugin will be installed but cannot be enabled.
The renamed plugins
Sixteen plugins change their internal name. This is the list to hold against the plugin manager afterwards — everything else keeps the name it has today.
basemigration
fylr-plugin-basemigration
easydb-barcode-display
fylr-scancode-display
easydb-coin-viewer-plugin
fylr-plugin-coin-viewer
easydb-connector-plugin
fylr-plugin-connector
easydb-custom-mask-splitter-detail-linked-plugin
fylr-plugin-custom-mask-splitter-detail-linked
easydb-detail-map-plugin
fylr-plugin-detail-map
easydb-display-field-values
fylr-plugin-display-field-values
easydb-drupal-plugin
fylr-plugin-drupal
easydb-easydb4migration-plugin
fylr-plugin-easydb4migration
easydb-editor-field-visibility
editor-field-visibility
easydb-editor-tagfilter-defaults-plugin
fylr-plugin-editor-tagfilter-defaults
easydb-hijri-gregorian-converter
fylr-plugin-hijri-gregorian-converter
easydb-orcid-plugin
fylr-plugin-orcid
easydb-presentation-pptx-plugin
presentation-pptx
easydb-typo3-plugin
fylr-plugin-typo3
easydb-wordpress-plugin
fylr-plugin-wordpress
You do not have to do anything with this list before upgrading — it is here so a changed name in the plugin manager is recognisable rather than alarming.
Configuration, rights and exports
A plugin's configuration is stored under its internal name, and so are the system rights it defines. Where a plugin is renamed, the upgrade moves both to the new name, together with any export that produces or transports through that plugin. Nothing has to be written down beforehand and nothing has to be re-entered afterwards.
A plugin that is not converted — switched off, or loaded from your own directory — keeps its configuration under the old name, so nothing is lost there either.
The barcode plugins
Everything a plugin contributes to your data model — custom data types, mask splitters, PDF Creator elements — survives the migration, renames or not. The barcode plugins are the only case where the successor is a genuinely different plugin: Scancode Display registers its mask splitter and its PDF Creator element under new names.
The upgrade rewrites both for you: masks that used the barcode splitter now use the Scancode splitter, and PDF Creator templates containing a barcode element now contain a Scancode element. There is nothing to edit by hand, and easydb-barcode-display-pdf-plugin disappears because Scancode Display already contains that PDF element.
PDF Creator and the PDF Server
Where PDF Creator renders changes with the upgrade, and it is worth knowing which of the two plugins you have.
The shipped pdf-creator — the one this page is about — does not render PDFs itself. It sends the HTML to whatever is configured in the base configuration under pdf_creator.fylr_url, and if that is empty it looks for the PDF Server (server-pdf) plugin and uses that. This is why many instances have server-pdf installed at all.
Its successor renders PDFs itself. From version 1.1.0 the marketplace plugin carries its own renderer and calls it directly. Two things follow:
server-pdfis no longer used. It is not removed by the upgrade — the migration only touches plugins fylr shipped, andserver-pdfwas always installed by an administrator — so it stays until you uninstall it. You can, unless something of your own posts to itshtml2pdfendpoint, which remains a public API.pdf_creator.fylr_urlis no longer used either — it is not a setting of the new plugin. If you pointed PDF Creator at an external rendering service, that service is no longer contacted after the upgrade; rendering happens on your own exec server instead. The fylr distribution ships the required Chromium, so nothing needs installing; a custom exec server may needSERVER_PDF_CHROME.
This is not tied to 6.35. If you already installed PDF Creator from the marketplace, the change happened when that plugin updated to 1.1.0 — the marketplace plugin updates on its own policy, independently of your fylr version. The upgrade path described above applies to instances still running the shipped, on-disk pdf-creator, which is converted to the marketplace plugin by the migration.
Plugins that will be removed
These plugins have no successor and are removed at the upgrade:
easydb-barcode-display-pdf-plugin
absorbed: fylr-plugin-scancode-display already contains this PDF Creator element, and the upgrade re-points your templates to it
easydb-falconio-plugin
the Falcon.io service no longer exists
easydb-remote-plugin, server
easydb5 infrastructure with no function in fylr. server is the easydb5 "Server Status" page — not the PDF Server (server-pdf), which is a separate marketplace plugin and is not removed by this migration — see PDF Creator and the PDF Server
easydb-auto-keyworder-plugin
obsolete; automatic keywording is now the licensed ai-metadata plugin, which is configured differently and is not a drop-in replacement
easydb-plugin-zooniverse-import
a project-specific import
easydb-hotfolder-plugin
the hotfolder is part of fylr itself
webhook-plugin
no fylr successor
example-plugin
the developer example, continued as fylr-plugin-example
The last two are in the list for completeness: the fylr distribution has not loaded them for a long time, so most instances do not have them at all. If yours does — from an easydb5 migration, or a path you added yourself — it is removed like the rest.
If you actively use one of these, talk to us before upgrading.
The plugins oai, easydb-ldap-plugin and easydb-sso-plugin are not in this list because fylr already ignores them: OAI-PMH, LDAP login and SSO have been part of fylr itself for some time, and the plugin loader skips these three by name. They are not installed today and nothing changes for them at the upgrade.
After the upgrade
Open the plugin manager and check that every plugin you use is listed, enabled, and shows a version and a build date — the proof that its release was downloaded. Configure the renamed plugins, and check masks that use a custom mask splitter or a custom data type.
Installations without internet access
If fylr cannot download a plugin's release, the plugin manager marks that plugin as not installable — the entry is there, but the plugin is not operational. Each such plugin offers a one-click install as ZIP: your browser downloads the release from the plugin's stored URL and uploads it to fylr as a ZIP package. It is the machine you administer from that needs to reach the release host, not the fylr server. If your browser cannot reach it either, download the ZIP on any machine that can, and upload it in the plugin manager yourself.
A plugin installed this way is a zip plugin: it stays as uploaded, and updating it means repeating the step with a newer ZIP.
Last updated