コンテンツにスキップ

Omeka S の新機能

バージョン 4.0.0 の変更点

構成可能なリソースページブロック

バージョン 4.0.0 から、テーマは Omeka S の大きな新機能である構成可能なリソースページブロックを利用できるようになりました。アイテム、アイテムセット、メディアのリソース「表示」ページのコンテンツは、もはやテーマの作者（またはデフォルトのコアビューファイル）によって一元的に設定されるのではなく、ユーザーによって構成可能です。また、ページは複数の領域に分割することができるため、サイドバーといった構造をハードコーディングせずに実現できます。

モジュールはこのシステムに新たなブロックを追加できるため、「before」や「after」イベントのみを使用してページの上部や下部に追加されていた追加コンテンツを、ユーザーが構成し、特定の位置に配置したり、完全に削除したりすることができるようになります。

特にテーマ制作者向けの詳細情報は、構成可能なリソースページブロックページで利用できます。

API の更新

バージョン 4.0.0 において、API にはいくつかの改善と新機能が追加されました。

新しい検索クエリオプション

ほとんどのリソースによって受け入れられる id クエリは、ID を PHP 配列 (id[]=1&id[]=2 など REST API のクエリ文字列の例）としてのみではなく、単一のカンマ区切り文字列 (1,2,3) でも渡すことができるようになりました。

アイテム、メディア、アイテムセットの検索では以下が受け入れられるようになりました：

  • modified_before、modified_after、created_before、created_after を使用して修正日と作成日による検索
  • property クエリにおいて新しいタイプ sw (starts with) と ew (ends with)

アイテムの検索では以下が受け入れられるようになりました：

  • not_item_set_id を使用して指定されたセットにないアイテムのみを返す
  • has_media を使用して少なくとも１つのメディアを持つアイテムだけを返す

プロパティとリソースクラスの検索では以下が受け入れられるようになりました：

  • site_id を使用して指定されたサイトに添付されたアイテムを少なくとも１つ使用するリソースだけを返す

API 経由でリソース値に自動的にプロパティ ID を設定

API を通じて Omeka S リソース（アイテム、アイテムセット、メディア）を作成する際、値のproperty_idは文字列autoに設定することができ、Omeka S は値が提供された JSON キーの用語からプロパティ ID を調べて値を作成します。以前の API バージョンでは、これらのキーは入力時に常に無視されていました。

たとえば、次のようなペイロードでは

{
    "dcterms:title": [
        {
            "type": "literal",
            "property_id": "auto",
            "property_label": "Title",
            "is_public": true,
            "@value": "Example First Title"
        },
    ]
}

property_idの"auto"はdcterms:titleの用語に適切なプロパティ ID を調べます。これにより、プロパティとその ID のリストを事前に知るか、余分な API クエリを送信することなく値を作成できます。

フォームの要素グループ

バージョン 4.0.0 では新しい「要素グループ」システムが導入されました。これは、Laminas「fieldset」要素を使わずに、フォーム要素のセットを視覚的にグルーピングし、ラベリングすることができます。フォームの「フラット」な構造を維持しつつ、ユーザーに対して要素の論理的なグルーピングを提示する際に便利です。

admin のグローバル設定、サイト設定、ユーザー設定フォームは、このシステムを使用するように変更されているため、これらのフォームに要素を追加していたモジュールは、そのコードを更新する必要があります。

フォーム内では、すべてのグループのリストはフォームオプションelement_groupsに格納されています。オプションの値は、内部識別子がキー、グループの人間が読めるラベルが値（これらは翻訳可能な文字列です）である配列です。各要素には、その要素が属するグループの内部識別子を参照するelement_groupオプションがあります。これらのオプションは、フォームに要素を追加するために使用される既存のイベントを使用して設定および変更することができます。

要素グループシステムを自身のフォームで使用したいモジュール制作者は、ヘルパーformCollectionElementGroupsを使用してフォームをレンダリングすることが必要です。

テーマ INI ファイルで提供されるテーマ設定もこのグループ化機能にアクセスできるようになり、テーマ作者は管理者がテーマを設定するためのオプションにグループを提供できるようになります。

ビューヘルパー

Omeka S 4.0.0 はいくつかのビューヘルパーを追加しています：

  • ブラウズは、現在構成可能な、ソートや管理ページのブラウズテーブルの具体的なコンテンツなど、ブラウズページのレンダリングの側面を扱います。
  • currentSiteは、現在のサイトの表現オブジェクトを返します。
  • iiifViewerは、IIIF 用の Mirador ビューアを埋め込んでレンダリングします。
  • lightGalleryOutputは、lightGallery を使用してメディアのギャラリーをレンダリングします。以前は Omeka チームが別途提供していたいくつかのテーマにこの機能が含まれていましたが、4.0.0 以降はコアに統合され、リソースページブロックシステムを使用して利用できるようになりました。
  • resourcePageBlocksは、テーマで構成可能なリソースページブロックをレンダリングおよび扱うためのものです。
  • sortMediaは、一連のメディアをソートするためのものです：lightGallery ディスプレイに対応するセットとそうでないものとを分けます。

PHP イベント

新しいイベント

  • iiif_viewer.mirador_configは、IIIF Presentation API メディアを表示するときに Mirador に渡す設定データを変更することができます。
  • sort-configは、新しいブラウズヘルパーおよびユーザーとサイトの構成で利用可能なデフォルトのソートオプションを使って、ソートセレクターを提示するためのソートオプションのセットを変更することができます。

変更されたイベント

  • view.sort-selectorは、現在sortConfig引数をsortByではなく渡し、配列の構造は API で使用される内部ソートキーがキーであり、値が人間が読めるラベルである単純な一次元配列に変更されます。

バージョン 3.0.0 の変更点

Zend Framework から Laminas への切り替え

Omeka S の多くの部分に基づいている Zend Framework ライブラリは、今後Laminasという名前に変更されました。この変更は、すべての Zend Framework クラスの名前に影響を与えるため、ほとんどのモジュールを更新する必要があります。

ほとんどのモジュールにとって、このプロセスは簡単です：モジュールのコード全体をZend\からLaminas\に変更するだけです。この置き換えにより、use文にほぼ影響があり、実際のコードはほとんど変わらないでしょう。"Zend"名を参照していた設定キーも変更される一般的な場所です。

この変更を行うと、モジュールは Omeka S 3.0.0 以降のバージョンでのみ互換性があるようになり、それより古いバージョンでは互換性がなくなります。したがって、config/module.ini 内のomeka_version_constraintは^3.0.0に設定されるべきです。

リソーステンプレートが 1 つのプロパティに複数のデータタイプを格納

バージョン 3.0.0 では、リソーステンプレートが複数のデータタイプを設定できる機能が追加され、ユーザーはリソースを追加または編集する際にそれらの間で選択できるようになりました。

これは、ResourceTemplateProperty エンティティのdata_type列とdataTypeプロパティが単純な文字列ではなく配列になっていることを意味し、複数のタイプを扱うために ResourceTemplatePropertyRepresentation クラスに新しいメソッドdataTypesとdataTypeLabelsが追加されました。以前の「単数」バージョンのメソッドは引き続き使用可能ですが、非推奨になっています：複数設定されている場合、最初のデータタイプを返します。

イベントの変更

サーバーサイドイベントsite_settings.formは削除されました。通常のform.add_elementsおよびform.add_input_filtersイベントは、サイト設定フォームと既に推奨されているオプションで動作します。

新しいセットのサーバーサイドイベントが追加され、リソースフォームの新しい「高度な」タブに直接要素を追加するためのモジュールにとってより簡単になります。view.$action.form.advanced（$actionはaddまたはedit)はアイテム、アイテムセット、メディアフォームで使用できます。

新しいプロパティがフォームに追加されるたびにトリガーされるリソースフォームの新しいクライアントサイドイベントがあります。o:property-addedは、プロパティが初期ロード、テンプレートの選択、またはユーザーが明示的にプロパティを追加することを選んだときに発火します。

新しい Gulp タスク

プロジェクトのコード標準に合わせることを容易にするために、新しい Gulp タスクが追加されました。test:module:csはモジュールのコード標準に対してチェックし、既存のtest:csと結合してコアをチェックするために使用されました。ほかの:moduleタスクと同様に、モジュールのフォルダ内でこのタスクを実行するか、--module-nameで明示的にモジュール名を渡して実行できます。

コアとモジュールの両方について、新しいfix:csおよびfix:module:csタスクも追加されています。これらのタスクは、単にコード標準に従ってチェックするのではなく、コードベースに必要な変更を行い、標準に沿った状態にします。