The core and each module fire events (triggers) before and after major operations. Third-party modules hook into these to extend behavior without modifying the core.

How it works

• Most events fire twice, as a before and after pair.
• before: Before the operation runs. If a handler returns an error (a failed BaseObject), it can stop the operation.
• after: After the operation completes. The return value is generally ignored. Use it for follow-up work (sending notifications, refreshing caches, and so on).

Registering handlers

Declare them in module.xml, and they are registered when you run the module update.

<eventHandlers>
	<eventHandler before="document.insertDocument" class="Controllers\Trigger" method="beforeInsertDocument" />
	<eventHandler after="document.insertDocument" class="Controllers\Trigger" method="afterInsertDocument" />
</eventHandlers>

<?php

namespace Zittme\Modules\Mymodule\Controllers;

class Trigger extends Base
{
	// $obj 에 대상 데이터(문서 등)가 참조로 들어옵니다
	public function afterInsertDocument(&$obj)
	{
		try
		{
			// 예: 새 글 등록 시 외부 알림
		}
		catch (\Throwable $e)
		{
			// 전역 트리거에서 내 모듈 사정으로 코어를 죽이지 않는다
		}
	}
}

Key events

The full list is huge, so only representative events per category are listed here. The naming rule is module.action.

Request lifecycle

Documents and comments

document.insertDocument document.updateDocument document.deleteDocument document.moveDocumentToTrash document.getDocumentList / comment.insertComment comment.updateComment comment.deleteComment and more

Members

member.insertMember member.updateMember member.deleteMember member.doLogin member.doLogout member.addMemberToGroup and more

Files and others

file.insertFile file.deleteFile file.downloadFile / communication.sendMessage / point.setPoint / menu.getModuleListInSitemap (to list your module in the module list on the add-menu screen)

Finding the exact event

The code is more accurate than the documentation. Find where events fire directly in the core.

grep -rn "triggerCall('찾을이름" modules/ classes/

Looking at a ModuleHandler::triggerCall('name', 'before|after', $obj) call site shows you exactly what data is passed as $obj.

Writing rules

• Handlers run for every matching operation. Keep them light, and do heavy work only after narrowing the conditions.
• Do not throw exceptions outward. Core operations such as posting or logging in must not fail because of your module.
• Return an error only when stopping in before, and do not rely on return values in after.