Monitor 1.4.0 for Geeklog: a clearer view of site health, logs, security and plugin compatibilit

Managing a Geeklog website often means checking several different areas: PHP and Geeklog versions, plugins, logs, disk space, configuration changes, security events and available updates.

Monitor 1.4.0 brings these operational checks together in one administration plugin. Its purpose is not to replace Geeklog's native administration tools, but to give administrators a clearer picture of the current state of their site and highlight situations that may require attention.

The plugin follows a simple principle:

Observe → Diagnose → Alert → Recommend

Monitor remains read-only by default. It reports what it finds and leaves important changes under the administrator's control.

The project is available from the Geeklog-Plugins Monitor repository. The current 1.4.0 work targets Geeklog 2.1.1 through 2.2.2 and PHP 5.6 through 8.1. Source: Monitor README

A dashboard focused on useful administration information

Monitor 1.4.0 reorganizes its administration interface around four main areas:

Overview provides a quick health check of the Geeklog installation. It can report the state of the runtime, important paths, logs, storage and Monitor itself.

Logs gives administrators a safer way to inspect Geeklog log files and archived logs.

Security presents Monitor's operational security observations and the state of its integration with the Ban plugin.

Plugins provides a read-only view of installed plugins, their versions and their compatibility with the current Geeklog installation.

The goal is to reduce the amount of information an administrator has to collect manually from several different screens.

Better visibility into plugin versions

One of the most useful changes in Monitor 1.4.0 is the redesigned plugin catalog.

Monitor compares locally installed plugins with their public repositories under the configured GitHub organization.

For each installed plugin, an administrator can quickly see its current state, for example:

• Up to date
• Update available
• Installed version newer
• Up to date for this Geeklog
• Available with Geeklog update

The distinction between these states is important.

A newer release on GitHub does not necessarily mean that it can be installed on the current website.

Finding the latest version that is actually compatible

Monitor now distinguishes between the latest published release and the latest release compatible with the current Geeklog and PHP runtime.

Consider the Ban plugin.

Ban 2.0.5 requires Geeklog 2.2.1 or later, while Ban 2.0.2 remains suitable for Geeklog 2.1.1.

On a Geeklog 2.1.1 site already running Ban 2.0.2, Monitor can therefore report:

Up to date for this Geeklog

instead of incorrectly presenting Ban 2.0.5 as an actionable update.

Monitor can still tell the administrator that a newer release exists:

Newer release 2.0.5 · requires Geeklog 2.2.1

This provides much more useful information than simply displaying "update available" or "not compatible".

Monitor checks release compatibility using structured information when available. It can look at the release plugin.json, autoinstall.php, GitHub release metadata and, as a last resort, version information embedded in release asset filenames. The search is bounded to avoid excessive GitHub requests. Source: Monitor services documentation

Discover plugins that can actually run on the site

The Discover plugins section applies the same compatibility logic to plugins that are not yet installed.

Instead of simply listing repositories, Monitor can indicate whether a plugin can run on the current site.

Possible states include:

• Compatible with this site
• Not compatible with this site
• Requirements not declared
• Metadata unavailable

When the latest release requires a newer runtime but an older release remains compatible, Monitor can display both pieces of information:

Latest compatible version 2.0.2 · Geeklog 2.1.1+
Newer release 2.0.5 · requires Geeklog 2.2.1

This makes the Discover section useful as a compatibility advisor rather than just a repository browser.

Monitor deliberately avoids guessing compatibility from README text. Missing metadata remains visible as missing metadata.

Geeklog Core plugins are handled differently

Not every official Geeklog plugin has its own repository in the Geeklog-Plugins organization.

Plugins such as Calendar, Links, Polls, reCAPTCHA, Spam-X, Static Pages and XML Sitemap are distributed directly with Geeklog Core.

Monitor now recognizes these as Core plugins.

They remain in the normal Installed plugins list, but Monitor does not treat them as independent third-party updates.

For example, a Core plugin may display:

Core plugin · Up to date
Version 1.1.9 · Geeklog 2.2.2

If a newer version is available only as part of a newer Geeklog release, Monitor reports:

Available with Geeklog update

This avoids suggesting that administrators download and replace Core plugins independently when the correct update path is a Geeklog Core upgrade.

Safer log monitoring

Logs are another important part of the 1.4.0 modernization.

Monitor provides bounded and escaped log viewing rather than loading unlimited log data into an administration page.

Daily log archives can be stored privately and reviewed from a sortable Geeklog administrative list.

Administrators can sort archives by date, log name or size and open individual archive views without exposing private filesystem paths.

The plugin can also summarize archived logs and identify recurring error patterns while keeping the amount of data processed under control. Source: Monitor 1.4.0 release notes

Monitoring without destructive automation

Monitor 1.4.0 also removes several historical behaviors that no longer fit its role.

The plugin no longer tries to become an installer or deployment system for other plugins.

It also removes obsolete TimThumb code, historical third-party telemetry, artificial request delays and old automatic banning behavior.

Monitor's responsibility is now clearer:

Monitor detects and reports. Specialized plugins perform specialized actions.

For example, Monitor does not try to replace the Ban plugin. Monitor can identify suspicious conditions and report Ban integration status, while Ban remains responsible for persistent allow/deny rules and enforcement.

Configuration and operational diagnostics

Monitor can also help identify configuration issues.

Its configuration audit compares important runtime and persisted settings while deliberately avoiding disclosure of sensitive values through its service interface.

The plugin also supports multisite/shared-files installations, with upgrade logic designed to remain safe when multiple Geeklog sites share plugin files but maintain separate databases and configuration states.

This is particularly useful for administrators maintaining several Geeklog installations from one common codebase.

Ready for Agent, Eclipse and Hub

Monitor 1.4.0 is also becoming an operational data provider for other Geeklog components.

It exposes read-only capabilities including:

• monitor.health
• monitor.diagnostics
• monitor.logs.summary
• monitor.plugins.status
• dashboard.summary

These capabilities can be consumed by tools such as Agent, the Eclipse administration dashboard and the future Hub plugin.

The important architectural point is that Monitor remains the owner of its diagnostic logic.

Other plugins do not need to duplicate Monitor's checks or directly inspect its tables and files. They can request structured information through Geeklog's service system instead. Source: Monitor services documentation

Security and privacy remain part of the design

Monitor services require administrative permissions, and the configuration audit maintains an even stricter Root-only boundary.

The service layer deliberately avoids exposing:

• private filesystem paths;
• raw configuration values;
• generated SQL;
• private log archive locations.

Actions that modify state remain explicit, permission checked and CSRF protected.

Monitor also supports an optional GitHub API token for metadata requests. The MONITOR_GITHUB_TOKEN environment variable can be used when administrators prefer not to store the token in Geeklog configuration.

A monitoring tool rather than another administration framework

The most important change in Monitor 1.4.0 is probably not a single feature.

It is the clearer definition of what the plugin is supposed to do.

Monitor is becoming the place where a Geeklog administrator can answer questions such as:

• Is my Geeklog environment healthy?
• What changed recently?
• Are there recurring log errors?
• Which plugins need attention?
• Is a plugin update actually compatible with my site?
• Is a newer plugin version only available after upgrading Geeklog?
• Are my Core plugins aligned with my current Geeklog release?
• Is another Geeklog component reporting operational information that needs attention?

And, just as importantly, Monitor does not automatically make potentially destructive decisions on behalf of the administrator.

That makes Monitor 1.4.0 a useful operational companion for both small Geeklog sites and more complex multisite installations.

The source code, documentation and releases are available from:

Geeklog-Plugins/monitor on GitHub