Download the PHP package tihloh/prefab-logs without Composer
On this page you can find all versions of the php package tihloh/prefab-logs. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download tihloh/prefab-logs
More information about tihloh/prefab-logs
Files in tihloh/prefab-logs
Package prefab-logs
Short Description Standalone, framework-independent structured activity and audit logging for Prefab PHP.
License MIT
Homepage https://github.com/tihloh/prefab-php
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package prefab-logs
Prefab Logs
Prefab Logs provides framework-independent structured activity and audit logging for PHP applications.
Store compact structured facts, then present them as a human-readable activity trail.
Installation
Quick start
Only fields whose values actually changed are stored. In this example email is omitted automatically.
The stored changes are compact and explicit:
Human-first activity
Prefab Logs is intended to produce activity that reads naturally to people, not just developers.
A presented log can read like:
Its details remain separate:
The presenter returns:
Each change detail contains:
Custom human sentence
Applications may supply a message when the generic actor/action/subject sentence is not enough:
When message is supplied, the human presenter uses it as the event sentence while the structured action, subject and actor remain available for technical use.
Update tracking
Use LogEntry::changes() whenever an operation has before and current values:
Fields may be excluded explicitly:
The rules are simple:
Manually supplied change arrays are also normalized. Prefab accepts the older old/new shape when encountered, but stores the current canonical before/now shape and removes unchanged pairs.
Actor and subject
Resolvers replace technical IDs with useful names. Without a resolver, Prefab falls back to values such as Someone #7 and user #25.
Typical human events include:
Sensitive fields
Sensitive values should never be shown as human change details. The presenter filters common fields including:
Applications should still avoid placing secrets in log metadata or changes in the first place.
Event and time are separate
Do not build timestamps into the human sentence.
Recommended UI:
Selecting a row can reveal only the changed details:
The application decides whether time is absolute, relative or hidden.
Technical view
The original structured records remain available:
Technical records retain the action, actor ID, subject type/ID, structured changes, metadata and timestamps.
Metadata
Project-specific context belongs in metadata:
Metadata is optional. Do not duplicate ordinary record contents into logs unnecessarily.
Storage
Prefab Logs uses database-backed persistence through LogRepositoryInterface. The built-in repository uses compatible shared database infrastructure while Logs remains responsible for its own log records.
A custom repository may still be supplied directly:
Or database configuration can be supplied:
Logs owns only its own audit/activity data. It does not own application user, permission or business tables.
Automatic Prefab activity
Compatible Prefab modules can emit structured activity when a logger capability is available:
Logs does not perform authentication, user management or permission decisions itself.
Diagnostics
Detailed trace:
Configuration resolution:
API quick reference
| API | Purpose |
|---|---|
record() |
Store a structured activity/audit event |
LogEntry::changes() |
Compare before/current values and keep only changed fields |
LogEntry::normalizeChanges() |
Normalize manual changes to before/now and remove unchanged values |
recent() |
Return recent technical records |
humanRecent() |
Return human-friendly presented records |
find() |
Find a record by ID |
forSubject() |
Activity affecting a subject |
forActor() |
Activity performed by an actor |
explain() |
Inspect resolved logging configuration |
Human presentation fields:
| Field | Purpose |
|---|---|
event |
Human-readable event sentence |
details |
Changed fields only, presented as before → now |
created_at |
Time the log record was created |
occurred_at |
Optional event/business occurrence time |
technical |
Original technical record |
summary |
Compatibility alias for event |
Design philosophy
The core principle is:
Store structured facts compactly. Show them like a person wrote the audit trail.
Immediate background persistence
Install Prefab Background when log persistence should leave the main request:
Configure Background in the application bootstrap and opt Logs in:
Application logging remains unchanged:
In background mode, the returned string is the Background instruction ID rather than the eventual database log ID.
Logs captures occurred_at before handing the instruction to Background. If Background must wait because its bounded journal is full, the stored event time still represents when the application activity actually happened. created_at continues to represent database persistence time.
Background mode is explicit. Installing Prefab Background alone does not silently change Logs from synchronous to background persistence.
