Translations
Info
All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

Ja:T3Doc/doc core inside/Versioning in TYPO3

From TYPO3Wiki
Jump to: navigation, search

<< Back to Inside TYPO3

TYPO3におけるバージョン管理

TYPO3はデータベースに保存されたエレメントのバージョン管理機能を備えています。この機能により現在のコンテンツに影響を与えることなく未来のバージョンを準備することができます。コンテンツの作成、編集、レビュー、発行(ここで下書きバージョンが現在のライブバージョンと差し替えられます)といったプロセスのワークフローを実現するのに利用されます。

バージョン管理はコアAPIとしてデフォルトで利用可能ですが、管理ツールにアクセスするには、「versioning」のようなsystem extensionをインストールする必要があります。

バージョン管理には様々なシナリオに対応できるよう、3つのタイプがあります:

  1. エレメント: バージョン管理が可能なテーブルであればデータベース上のどんなレコードでも元のエレメントの新しいバージョンとしてコピーし加工できます。カラーコードは薄緑です。
  2. ページ: 一つのページレコードがコピーされ、同時にそのページ上に存在する他のコンテンツ(tables with “versioning_followPages” set in [ctrl])が一緒にコピーされます。カラーコードは水色です。
  3. ブランチ: 一つのページレコードがコピーされ、同時にそのページのサブページが指定された階層の深さまで一緒にコピーされます。カラーコードはピンクです。

最大限柔軟性をかなえる為にはなぜ3つのタイプが必要なのか説明します:

「エレメント」バージョンはもっとも基本的な形で一番単純でもあります。その単純さゆえに、私は可能な場合はこのタイプをもっとも好んで使います。しかしながら、「エレメント」バージョンは簡単にはその環境を考慮にいれることができません(??)。しかし最近の開発(TYPO3 4.2以降)により、エレメントやページの移動が可能になったので、今では改善されています。

例えばページコンテンツを再構築する場合、ページ上のコンテンツエレメントの並び順を変えることは非常によくあります。それゆえに「ページ」タイプのバージョンはページとともにその上の幾つかのコンテンツも一緒にコピーされるので、自由に配置し直すことが可能になることを意味します。その上、このバージョン作成はページに対して1度行うだけでよく、そのページ上の変更されるエレメント毎に行う必要がありません。この方法の欠点は、不必要なコンテンツまでコピーされること、そして新しいページバージョンに差し替えられる際、ページ上の新しいコンテンツエレメントは以前とは違ったUIDを持つことになることです(以前のページのコンテンツエレメントを参照しているアンカー付きリンクやInsert Record”/TemplaVoilaの参照が切れてしまいます)。「ページ」バージョンタイプはcolumns-basedのウェブサイトで便利です。一方TemplaVoilaをベースにするサイトではエレメントベースのバージョン管理でより恩恵を受けることができます。特にバージョン作成が目に見えない形で行われるワークスペースの環境に於いては。「エレメント」バージョンの移動に関する最近の発達により、「ページ」バージョンはあまり用いられず、推奨されていません!

最後に「ブランチ」バージョンタイプはサイトのページツリーのブランチを丸ごと作り変えたい場合に用いられます。これにより、エレメントを自由に追加したり削除したり移動したりすることが可能になります。しかしその一方で「ページ」バージョンでリンクや他のID参照が壊れたのと同様の問題を抱えることになります。複製されたルートポイントのページ下にぶら下がるすべてのページコンテンツは、元のコンテンツへの参照を持たない、元のコンテンツとは全く別のコピーとなります。アンカーポイントの参照だけではなく、ページIDへの参照さえ切れることになります! 今では新しいセクションの作成や、このような結果がを受け入れられるほどの大規模な再構築の際には便利だと考えています。人々がそれらを利用しようとする本来の使用目的も見受けられますが。「エレメント」バージョンの移動に関する最近の発達により、「ブランチ」バージョンはあまり用いられず、推奨されていません!

「ページ」や「ブランチ」バージョン管理を使わず、代わりに「エレメント」バージョン管理を使うように推奨されています。

技術的な詳細

Versioning must be enabled on a per-table basis in the [ctrl] section of the $TCA array entry for a table. In addition a fixed set of fields has to exist for the management of versions. All of these technical details are specified in the document “TYPO3 Core API” where you will also find other in-depth information.

Future and past versions of records in TYPO3 remain in the same table as the live version. However, all “offline” versions will have a pid value of “-1” which identifies them as “offline”. Further they have a field, “t3ver_oid” which points to their live (“online”) version.

When a future/past version is swapped with the live version it is done by swapping all field values except the uid and pid fields (and of course versioning related fields are manipulated according to their function). It means that online content is always identified by the same id as before and therefore all references are kept intact (except content inside “Page” and “Branch” versioning, see above).

Versioning is easy for existing elements. However, moving, creating and deleting poses other problems. This is solved the following way:

Deleting elements is done by actually creating a new version of the element and setting a flag in the new version (t3ver_state=2) that indicates the live element must be deleted upon swapping the versions. Thus deletion is “scheduled” to happen when the versions are swapped.

Creating elements is done by first creating a placeholder element which is in fact live but carrying a flag (t3ver_state=1) that makes it invisible online. Then a new version of this placeholder is made which is what is modified until published.

Moving elements is done by first creating a placeholder element which is in fact live but carrying a flag (t3ver_state=3) that makes it invisible online. It also has a field, “t3ver_move_id”, holding the uid of the record to move (source record). In addition, a new version of the source record is made and has “t3ver_state” = 4 (move-to pointer). This version is simply necessary in order for the versioning system to have something to publish for the move operation. So in summary, two records are created for a move operation in a workspace: The placeholder (online, with state=3 and t3ver_move_id set) and a new version (state=4) of the online source record (the one being moved).

ユニークフィールド

Unique fields like a page alias or user name are tricky in a versioning scenario because the publication process must perform a check if the field is unique in the “Live” situation. The implications of implementing this means that we have chosen a solution where unique fields are simply not swapped at all! It means that publication of a new version of a page cannot and will not alter the alias of the live version. The “Live” unique value will remain until changed in the live version.

You can hide fields with the “unique” keyword when they are offline versions. This is done with the display condition:

'displayCond' => 'VERSION:IS:false',

ライフサイクル

When a new version of an element is created, its publishing counter (t3ver_count) is set to zero. This means its life cycle state is interpreted as “Draft”; the element is in the pipeline to be published. When the element is published the life cycle state is “Live” and when it is swapped out again the publishing counter will be incremented and the life cycle is interpreted as “Archive”. Yet, the element can be continously published and unpublished and for each time the publishing counter will be incremented, telling how many times an element has been online.

パーミッション

This is an overview of how permissions are handled in relation to versioning:

Display

Read permissions are evaluated based on the live version of pages (as the basic rule). The read permissions of the offline page version in a workspace is not observed. (Reason: When for example the page tree is generated TYPO3 selects all live records and then looks for versioned overlays).

Read permissions for new page versions of “branch” type is observed in eg. Web > List module. This is due to the fact that the real ID of a “branch” type page is what the backend uses in the Web>List module while for “page” and “Element” type versions the ID of the live record is used in which case the live records display-permissions is what gets evaluated.

Versioning records

To create a new version the user must have read permission to the live record he requests to version

A new version of a page will inherit the owner user, group and permission settings from the live record

To create a "Page" or "Branch" version of a page requires read permission to all subpages. All records that should be copied along with "Page" and "Branch" versions will be so regardless of the users table-modify permissions.

Publishing version

To publish, a user must have general publishing permission in the workspace, for instance be the owner of it or have access to the Live workspace.

In addition, the user must have read and edit access to the offline version being published plus edit access to the live version that a publishing action will substitute!

The permissions of a new version of a page follows the page when published.

Editing records

For all editing it is required that the stage of the versioned record (or root point) allows editing.

Page records:

Permission to edit is always evaluated based on the pages own permission settings and not the live records.

Records from non-pages tables:

"Element" versions: Always based on the live parent page.

Live records inside a "Branch" or "Page" versioning type immediately under the root point depends on permissions of the root point offline version.

New records

When new records are created with a version and live place holder the permissions depend on the live page under which the record is created.

Moving records

Records can be moved as long as the source and destination root points has a stage that allows it.

New records created with a place holder element can be moved freely around except into other "Page" and "Branch" versions.

Generally, the stage of a moved record has to allow for editing plus regular permissions for moving are observed.

Deleting records

If the record is inside a "Page" or "Branch" type version of a page, then it can be readily deleted if other permissions allow, including stage of the root point.

If a record is outside a versioned branch and supports versioning it will be marked for deletion if all usual requirements are fulfilled at the time of the delete request: Delete access to record, that no subpages are found if not recursive deletion is enabled and no disallowed table records are found. As soon as the record is marked for deletion any change to the record and subpages that would otherwise prevent deletion for the user will not be effective: The record will be deleted upon publication!

If you try to delete a Live record for which a version is found in the workspace, that version is deleted instead.

Detaching versions from a workspace and raising stage of versions can be done as long as the user has edit permission to the record.