Upgrading to 4.0

Omeka S Installing
1

On the Omeka S download page there’s a non-working link to the Installation/upgrade instructions page.

Which leaves me with the question: how to upgrade my 3.1 installation to 4.0 ? Just make a backup, install new version, and all is ok?

2

Hmm, sorry about that… looks like there was some temporary problem with the user manual for S. The link should be functioning correctly now.

You’re basically on point with the process of upgrading. The instructions just provide some tips to help people know what should be retained (like locally-stored uploaded files, database credentials and local configuration).

3

Thanks, I also found the info in the included README.md

But I just reverted back to 3.2.3 because some modules complained about not being version 3.

For the upgrade part of the documentation, please add a check for new versions of all installed modules prior to upgrading Omeka S.

I’ve checked some repos and some have updates and are available for 4.0, but some - that I really need like Omeka-S-module-Ark - are not yet updated.

And some modules don’t show me that there’s a new version, like Value Suggest. I have 1.11.0 and the newest version (with omeka_version_constraint = "^4.0.0") is 1.13.0.

FYI: Performing the command grep omeka_version_constraint */config/*.ini in the module directory provides me with a todo list for the upgrade to Omeka 4 …

  • AdvancedResourceTemplate/config/module.ini:omeka_version_constraint = “^3.1.0”
  • AdvancedSearch/config/module.ini:omeka_version_constraint = “^3.0.0”
  • AnalyticsSnippet/config/module.ini:omeka_version_constraint = “^3.0.0”
  • Annotate/config/module.ini:omeka_version_constraint = “^3.1.0”
  • ApiInfo/config/module.ini:omeka_version_constraint = “^3.1.0”
  • Ark/config/module.ini:omeka_version_constraint = “^3.1.0”
  • BlockPlus/config/module.ini:omeka_version_constraint = “^3.2.0”
  • BlocksDisposition/config/module.ini:omeka_version_constraint = “^3.0.0”
  • BulkEdit/config/module.ini:omeka_version_constraint = “^3.0.0”
  • BulkExport/config/module.ini:omeka_version_constraint = “^3.1.0”
  • Cartography/config/module.ini:omeka_version_constraint = “^3.0.0”
  • CleanUrl/config/module.ini:omeka_version_constraint = “^3.1.0”
  • Collecting/config/module.ini:omeka_version_constraint = “^3.0.0”
  • Comment/config/module.ini:omeka_version_constraint = “^3.0.0”
  • CSSEditor/config/module.ini:omeka_version_constraint = “^3.0.0”
  • CSVImport/config/module.ini:omeka_version_constraint = “^3.0.0”
  • CustomOntology/config/module.ini:omeka_version_constraint = “^3.0.0”
  • CustomVocab/config/module.ini:omeka_version_constraint = “^3.2.0”
  • DataCleaning/config/module.ini:omeka_version_constraint = “^3.0.0”
  • DataRepositoryConnector/config/module.ini:omeka_version_constraint = “^3.0.0”
  • DataTypeClass/config/module.ini:omeka_version_constraint = “^3.0.0”
  • DataTypeGeometry/config/module.ini:omeka_version_constraint = “^3.0.0”
  • DataTypeRdf/config/module.ini:omeka_version_constraint = “^3.0.0”
  • EasyAdmin/config/module.ini:omeka_version_constraint = “^3.1.0”
  • Export/config/module.ini:omeka_version_constraint = “^1.0.0 || ^2.0.0 || ^3.0.0”
  • Feed/config/module.ini:omeka_version_constraint = “^3.0.0”
  • FileSideload/config/module.ini:omeka_version_constraint = “^3.0.0”
  • Generic/config/module.ini:omeka_version_constraint = “^3.1.0”
  • HideProperties/config/module.ini:omeka_version_constraint = “^3.0.0”
  • IiifServer/config/module.ini:omeka_version_constraint = “^3.1.0”
  • ImageServer/config/module.ini:omeka_version_constraint = “^3.1.0”
  • ItemRelation/config/module.ini:omeka_version_constraint = “^3.0.0”
  • ItemSetsGraph/config/module.ini:omeka_version_constraint = “^3.0.0”
  • ItemSetsTree/config/module.ini:omeka_version_constraint = “^3.0.0”
  • Log/config/module.ini:omeka_version_constraint = “^3.1.0”
  • Mapping/config/module.ini:omeka_version_constraint = “^3.1.0”
  • NestedDataType/config/module.ini:omeka_version_constraint = “^3.0.0”
  • Next/config/module.ini:omeka_version_constraint = “^3.0.0”
  • NotifyCreateUpdate/config/module.ini:omeka_version_constraint = “^3.0.0”
  • NumericDataTypes/config/module.ini:omeka_version_constraint = “^3.2.0”
  • OaiPmhRepository/config/module.ini:omeka_version_constraint = “^3.0.0”
  • PdfEmbed/config/module.ini:omeka_version_constraint = “^1.0.0 || ^2.0.0 || ^3.0.0”
  • Reference/config/module.ini:omeka_version_constraint = “^3.0.0”
  • Search/config/module.ini:omeka_version_constraint = “^3.0.0”
  • SearchSolr/config/module.ini:omeka_version_constraint = “^3.0.0”
  • Statistics/config/module.ini:omeka_version_constraint = “^3.1.0”
  • Thesauri/config/module.ini:omeka_version_constraint = “^3.0.0”
  • UniversalViewer/config/module.ini:omeka_version_constraint = “^3.0.0”
  • UriDereferencer/config/module.ini:omeka_version_constraint = “^3.0.0”
  • ValueSuggest/config/module.ini:omeka_version_constraint = “^3.2.0”
  • Wikidata/config/module.ini:omeka_version_constraint = “^3.0.0”
4

The documentation does mention that upgrades to modules may be required, but we can make it more explicit that users should check to make sure the modules they need are supported in the new version.

Normally this isn’t much of an issue, but with a new major version it can take some time for developers of modules to release updates.

5

O no, some latest versions of modules like FileSideload, Inverse Properties, Log, Mapping, NumericDataTypes, Persistent Identifiers, Sitemaps and UriDerefercer don’t work in 3.x anymore, only 4…

This all makes upgrading not really a smooth ride.

6

Modules can declare whatever compatibility they want, but in general they use the ^ type of constraint to work only within a major series. This way, developers can check for compatibility before updating the constraint, so users don’t end up with active but broken modules.

We aim to maintain compatibility across major versions when possible, but there’s a specific change related to translations in 4.0 which was outside our control and means that more modules than usual require the new version when updated. And obviously modules which take advantage of new core features will typically require the new version.

I’m not sure this really represents a significant upgrade problem, though. Whether updated modules do or do not continue to support the previous versions, the process of upgrading is the same: replace the module files and hit upgrade after the core upgrade is done.

7

Thanks.

I have now made a 4.0 install next to my (live) 3.2 instance and upgraded all modules in the new instance (with db copied from my live instance). Only 2 must-have modules are not yet v4 capable: ARK and Comment by @Daniel_KM He has already made a lot of his modules work for 4.0 so I’ll be patient.

8

Normally, Comment and Ark are upgraded. They are not tested under php 8 and there may be issue for ark (When enabling Noid, it creates a zero byte DB and is unable to continue (#2) · Issues · Daniel-KM / Omeka-S-module-Ark · GitLab), so check on a test server first.

9

On other point, i see some modules that seem interesting I don’t find on github or omeka.org. Can we find them somewhere ?

10

This topic was automatically closed 360 days after the last reply. New replies are no longer allowed.