A new version of the Monitor plugin for Geeklog is now available.
Monitor 1.5.0 continues the modernization work started with version 1.4.0, with a strong focus on reliability, diagnostics, safer administration, plugin compatibility checks and multilingual support.
The new version is available from the official Geeklog Plugins repository:
https://github.com/Geeklog-Plugins/monitor
Monitor is evolving into a dedicated site-health and diagnostic plugin rather than a collection of unrelated administration tools.
Its guiding principle remains simple:
Observe -> Diagnose -> Alert -> Recommend -> Act only when explicitly requested
By default, Monitor is read-only. It reports problems, provides context and recommends actions without silently changing site configuration, plugin code or security state.
The administration interface focuses on four main areas:
Monitor 1.5.0 targets:
Several compatibility improvements have been made around Geeklog's native Configuration system.
Monitor now uses the expected Geeklog configuration structure, provides native configuration help tooltips and can repair malformed configuration metadata from earlier development builds without requiring an artificial version increase.
Existing administrator values are preserved during these repairs.
One of the most visible improvements in Monitor 1.5.0 concerns plugin monitoring.
The plugin catalog now provides clearer information about:
The Discover plugins list is now sorted alphabetically, making larger plugin repositories easier to browse.
Monitor also distinguishes between the newest release available upstream and the newest release that can actually be installed on the current site.
This is particularly useful for administrators maintaining older Geeklog installations.
Monitor uses GitHub metadata to discover plugin versions and compatibility information.
Version metadata caching has been refined in 1.5.0:
An optional read-only GitHub token can therefore provide both a larger API quota and fresher version information.
The log tools have also received significant improvements.
Monitor provides bounded and escaped log viewing, explicit CSRF-protected log clearing and daily log archiving.
Archives are kept outside the public web directory and active logs are truncated only after the archive copy has been successfully created.
The archive interface provides sortable lists and dedicated previews without exposing raw filesystem paths.
Monitor can create lightweight snapshots of the current site state and compare them over time.
The comparison can highlight changes such as:
This provides administrators with a quick way to understand what changed between two checks.
Monitor 1.5.0 also continues the removal of old or risky mechanisms inherited from historical releases.
Among the changes introduced during the 1.4/1.5 modernization work are:
sleep(60) request blocking;Monitor is not intended to replace the dedicated Geeklog Ban plugin.
Instead, Monitor observes suspicious activity and reports security information while Ban remains responsible for persistent blocking rules and enforcement when installed.
Monitor 1.5.0 also introduces a clearer interoperability model.
It exposes read-only capabilities such as:
monitor.healthmonitor.diagnosticsmonitor.logs.summarymonitor.plugins.statusdashboard.summaryOther Geeklog components such as Agent, Eclipse or Hub can consume these services without directly accessing Monitor's internal files or storage.
This keeps Monitor responsible for calculating and owning its diagnostic data while allowing other plugins and themes to reuse it safely.
This release also greatly expands Monitor's multilingual support.
Monitor 1.5.0 now includes UTF-8 translations for:
English remains the canonical language file.
Automated CI checks now verify that translated files contain the same keys and compatible placeholders such as %s and %d, helping
MediaGallery 1.9.0 is now available from the official Geeklog Plugins repository.
This new version continues the modernization work started with MediaGallery 1.8.0 while keeping an important goal intact: existing Geeklog websites should be able to adopt the improved plugin without being forced to upgrade their entire CMS stack first.
MediaGallery 1.9.0 therefore continues to support Geeklog 2.1.1 and newer, including Geeklog 2.2.2, while keeping PHP 5.6-compatible syntax and being validated against PHP 5.6, 7.4, 8.1 and 8.3.
The source code and installable package are available here:
https://github.com/Geeklog-Plugins/mediagallery
One of the main goals of MediaGallery 1.9.0 is to complete the remaining PHP 8 runtime hardening.
Older MediaGallery installations may contain records created by previous releases, imports or migrations where some optional media metadata is not present. Newer PHP versions are much less forgiving when code accesses missing array keys.
MediaGallery 1.9.0 now normalizes optional media metadata before it reaches the rendering layer. This includes values related to media resolution, display resolution, remote media and remote URLs.
This prevents PHP 8 warnings when older or imported media records are displayed and completes the remaining compatibility work associated with issue #11 in the MediaGallery issue tracker.
The release branch is automatically checked against PHP 5.6, PHP 7.4, PHP 8.1 and PHP 8.3.
MediaGallery 1.9.0 also expands the SEO work introduced during the previous modernization cycle.
Album pages can now expose Schema.org CollectionPage structured data together with an ItemList representing the media displayed on the current page.
Individual media pages continue to expose content-specific structured data using appropriate Schema.org types such as:
ImageObjectVideoObjectAudioObjectMedia URLs used in structured data are normalized into absolute public URLs where appropriate.
Albums and individual media pages also receive improved meta-description fallbacks. When a dedicated description exists, MediaGallery can provide content-specific metadata instead of relying only on the generic site description.
The result is cleaner metadata for search engines and other consumers without changing the editorial workflow for site administrators.
MediaGallery can now cooperate with the OGP plugin when it is installed.
If an active OGP plugin exposes the expected social metadata API, MediaGallery can delegate Open Graph and Twitter/X metadata to it.
Albums can provide their title, description, canonical URL and a representative image. Individual media pages can provide similar information together with media-specific metadata.
This integration remains optional.
MediaGallery does not require OGP, and websites without the plugin continue to receive standalone Open Graph and Twitter/X metadata generated by MediaGallery itself.
MediaGallery also remains authoritative for its canonical URLs, descriptions and Schema.org structured data.
A major part of the recent MediaGallery modernization has been making the plugin easier for the rest of the Geeklog ecosystem to work with.
Historically, another plugin wanting information about MediaGallery albums or media could be tempted to query MediaGallery's private database tables directly. That creates tight coupling between plugins and makes future changes more difficult.
MediaGallery instead exposes bounded services and standard Geeklog Plugin API information.
For example, other Geeklog components can request a permission-filtered album tree through PLG_invokeService() instead of knowing anything about MediaGallery's internal mg_* tables.
MediaGallery also reports album and media changes through Geeklog's normal lifecycle mechanisms.
This allows plugins and services such as IndexNow, XML Sitemap, Hub and future integrations to react to MediaGallery content without MediaGallery containing consumer-specific code.
The same interoperability work makes MediaGallery more suitable for newer Geeklog tools such as Agent, Hub and modern administration dashboards.
MediaGallery continues to use the persistent storage architecture introduced with version 1.8.0.
User media is stored outside the replaceable public_html/mediagallery/ plugin directory and instead uses Geeklog's configured image storage location.
This is particularly important when updating a plugin through Geeklog's ZIP installer because plugin files can safely be replaced without treating user media as part of the application code.
The storage paths are derived from Geeklog configuration rather than hard-coded locations, which also makes the design suitable for shared-code multisite installations.
Each site can keep its own MediaGallery content even when several Geeklog sites share the same plugin source files.
MediaGallery 1.9.0 carries forward the security improvements introduced during the 1.8 modernization.
These include protections around:
Image processing also checks that the configured Geeklog image backend is actually available before attempting resize, conversion, rotation or watermark operations.
Supported configurations include GD, ImageMagick and NetPBM according to the Geeklog site configuration.
The maintained MediaGallery interface has also moved away from several technologies and assumptions inherited from much older web applications.
The current templates provide responsive album and media layouts, improved semantic markup and accessibility, modern lightbox and slideshow behavior, and HTML5 audio/video playback.
Legacy Flash and ActiveX playback paths are no longer part of the active playback experience.
Album thumbnails and portrait-image rendering have also received improvements, including the use of better source images when generating visual representations.
MediaGallery 1.9.0 significantly expands its maintained language coverage.
The current English files are used as the structural reference, and the release includes updated or newly synchronized UTF-8 translations for:
The language files follow the same functional key structure as the English reference and are included directly in the MediaGallery 1.9.0 distribution.
This should make the plugin much easier to deploy on multilingual Geeklog sites and within the international Geeklog community.
MediaGallery 1.9.0 also improves how the plugin identifies itself to Geeklog.
Release and minimum Geeklog compatibility information are now centralized in a canonical version.php file.
The plugin runtime, installer and upgrade logic therefore share the same authoritative release metadata.
The static plugin.json manifest remains available for repository and administration tools, and the distribution workflow validates that its compatibility information remains synchronized with the installer metadata.
This avoids situations where the version reported by the running plugin, the installer and the package metadata can accidentally diverge.
MediaGallery 1.9.0 supports:
Automated syntax validation currently covers PHP 5.6, 7.4, 8.1 and 8.3.
Keeping Geeklog 2.1.1 compatibility is deliberate. It gives administrators the option to modernize important plugins before, during or after a staged migration of the Geeklog core itself.
Existing MediaGallery 1.8.0 installations can upgrade directly to MediaGallery 1.9.0.
No additional database schema migration is required beyond the existing 1.8.0 state.
As always, administrators should keep a current database and media backup before updating a production website.
Sites still running MediaGallery 1.7.x require one additional precaution.
Those installations may still store user media inside:
public_html/mediagallery/mediaobjects/
Because Geeklog's plugin ZIP updater replaces the plugin public directory, legacy media must first be migrated to the persistent storage location introduced with MediaGallery 1.8.0.
MediaGallery includes a migration tool for this purpose. The tool copies and verifies the media while deliberately leaving the original source files untouched.
Administrators upgrading from 1.7.x should complete this migration successfully before replacing the plugin through the Geeklog ZIP installer.
MediaGallery 1.9.0 source code, documentation and the validated installable archive are available from the official Geeklog Plugins repository:
https://github.com/Geeklog-Plugins/mediagallery
The installable package is:
mediagallery_1.9.0_2.1.1.zip
MediaGallery 1.9.0 is another step toward keeping one of Geeklog's long-standing content plugins useful on both existing and modernized Geeklog installations, with stronger PHP compatibility, cleaner interoperability, improved SEO and much broader language coverage.
Posted October 4, 2026 | 7:11 pmIf you are still running an old glFusion, WordPress, or legacy Geeklog website, moving to a clean and modern Geeklog installation can now be much easier.
The new Migrator 1.0.0 plugin has been created specifically to help recover content from legacy CMS database dumps and import it into a fresh Geeklog 2.2.2 installation.
Migrator is available here:
https://github.com/Geeklog-Plugins/migrator
Rather than trying to upgrade an aging installation through years of intermediate versions, Migrator takes a different approach: start with a clean Geeklog installation and bring your valuable content with you.
Maintaining a Geeklog website that has been online for many years can become increasingly difficult.
The site may have gone through several PHP versions, database upgrades, theme changes, plugin updates, and server migrations. In some cases, the installation may be so old that performing a traditional step-by-step upgrade is no longer practical.
Migrator provides another option.
You can install a completely fresh copy of Geeklog 2.2.2, install the current versions of the plugins you need, and then use Migrator to recover compatible content from the database of the old website.
Depending on the source installation, Migrator can recover core content such as:
Where possible, existing IDs are preserved so relationships between imported content remain intact.
This approach can be particularly useful when moving from a very old Geeklog installation to a clean server with a current PHP and database environment.
glFusion originated as a fork of Geeklog, which means that many of its core database structures remain closely related to Geeklog.
That makes glFusion an especially interesting migration source.
Migrator can recover compatible glFusion core content and also includes dedicated support for some of the most important glFusion plugins.
Migrator can recover compatible Forum data including:
One of the more difficult areas of a CMS migration is dealing with old Forum attachments.
Migrator can convert legacy glFusion Forum attachment records into MediaGallery downloadable media items. Migrated Forum posts can then reference those files through MediaGallery download autotags.
This provides a practical bridge between an old glFusion Forum installation and the current Geeklog plugin ecosystem.
Migrator also supports migration of compatible glFusion MediaGallery data.
This includes information such as:
Some compatibility differences between old glFusion versions and current MediaGallery releases are handled automatically during migration.
Physical media files themselves are deliberately not copied automatically. Migrator instead reports the paths required for the administrator to copy them manually.
This keeps the database migration safe and predictable while avoiding potentially dangerous automatic manipulation of large media directories.
Migrator is not limited to Geeklog-derived platforms.
It also provides a migration path from WordPress to Geeklog.
A WordPress migration can currently recover several important types of content.
WordPress categories are converted into Geeklog topics, posts become Geeklog stories, and pages can be imported as Static Pages.
Migrator also handles:
This makes Migrator particularly useful for website owners who want to leave WordPress but keep their existing editorial content.
There are intentionally some limitations.
WordPress plugin-specific content is not migrated, and WordPress password hashes are not imported. Migrated WordPress users therefore need to set a new Geeklog password.
Tags, featured-image metadata, pingbacks, trackbacks, and some attachment metadata are also outside the current migration scope.
The objective is not to reproduce every internal WordPress feature. The goal is to recover the important content needed to rebuild the website cleanly in Geeklog.
One of the most important design decisions behind Migrator is that it does not need to work directly against your production database.
Instead, you export the source database and upload the resulting SQL dump to Migrator.
The plugin currently accepts:
.sql;.sql.gz;.zip containing a single SQL file.Migrator then recreates the source tables using isolated staging table names.
This means the source database structure can be inspected and analyzed without executing its original table names against the Geeklog destination database.
The workflow is deliberately cautious.
First the database is staged. Then Migrator detects the source CMS and analyzes the available content. The administrator can review the results and perform a dry run before starting the actual migration.
Migrator is not intended to merge arbitrary websites into an already populated Geeklog site.
It deliberately expects a fresh Geeklog 2.2.2 installation.
Before writing content, the plugin checks the destination installation and refuses the migration if it no longer resembles the expected fresh-install baseline.
This restriction is intentional.
Content migration becomes much safer when the destination is predictable. It also reduces the risk of overwriting users, articles, topics, or other existing content.
A typical migration therefore looks like this:
A migration is also a good opportunity to reconsider everything that has accumulated over the years.
Instead of carrying old PHP files, abandoned plugins, obsolete themes, outdated configuration entries, and years of technical debt into another upgrade, a clean Geeklog installation gives you a much simpler starting point.
You can install only the plugins you still use, deploy a current theme, review permissions, reorganize topics, and remove content that no longer needs to be published.
Migrator focuses on recovering the data that matters while allowing the new Geeklog installation itself to remain clean.
Database records and physical files are intentionally treated separately.
For MediaGallery migrations and recovered Forum attachments, Migrator creates the required database records and reports where the corresponding files must be placed.
With MediaGallery 1.9.0 on a standard Geeklog 2.2.2 installation, persistent media storage is located under:
public_html/images/mediagallery/
Administrators using customized image paths can use their configured MediaGallery storage location instead.
This separation is particularly useful when migrating large websites, because files can be transferred independently using SSH, SCP, rsync, FTP, or another server-side method.
Migrating an old CMS database is inherently sensitive, so Migrator includes several safeguards.
Uploaded SQL dumps are stored outside the public web root. Source tables are staged under isolated names. Potentially dangerous or unrelated SQL statements are not executed as part of the migration workflow.
Migrator also keeps migration jobs, ID mappings, and logs so that administrators can understand what happened during the import.
There is also a reset mechanism for imported database content when a migration needs to be restarted.
As with any CMS migration, however, you should always keep complete backups of both the source website and the destination environment.
Migrator 1.0.0 is the first public release of this new migration tool.
It currently targets Geeklog 2.2.2 and supports three important migration scenarios:
Legacy Geeklog → Geeklog 2.2.2
A practical way to rebuild a very old Geeklog website on a completely fresh installation.
glFusion → Geeklog 2.2.2
Including compatible Forum and MediaGallery data.
WordPress → Geeklog 2.2.2
For site owners who want to move their editorial content away from WordPress and into Geeklog.
Migrator is available from the Geeklog Plugins organization on GitHub:
https://github.com/Geeklog-Plugins/migrator
If you still maintain an old Geeklog, glFusion, or WordPress website, this may be a good time to give that content a fresh start with Geeklog.
Posted October 4, 2026 | 6:50 pmGeeklog language files are receiving a significant update, covering both the core CMS and several bundled plugins.
Over the past few weeks, I have been reviewing the existing translations, completing missing strings, adding missing language files, fixing placeholders, and improving consistency between languages.
The goal is simple: provide a more complete and reliable multilingual experience for Geeklog users and make future language maintenance easier.
A first series of pull requests has been submitted to the official Geeklog repository for the main Geeklog language files.
The work currently covers:
The updates focus on missing or untranslated strings, wording consistency, UTF-8 support, and compatibility with the current Geeklog language structure.
Each language is handled separately so that changes can be reviewed and merged independently.
The same work is now being applied to the plugins distributed with Geeklog.
Pull requests have already been submitted for:
For these plugins, the language packs are being aligned with the same set of languages whenever possible.
This includes not only updating existing translations, but also adding language files that were previously missing.
This work is not limited to translating strings.
I have also been using automated checks to detect common problems such as:
%s and %d;This makes it possible to validate a language pack before submitting it upstream and reduces the risk of introducing broken interface strings.
For the most recently completed plugins, the objective is to reach full coverage with no missing keys, placeholder errors, or remaining translation review items.
The pull requests are currently being reviewed in the official Geeklog repository.
If accepted, these updated translations should become part of Geeklog and be available directly in a future update.
There is no need to wait for the merges if you want to test them today.
The current development versions of the language files are available from the lang branch of my hostellerie/geeklog-2.2.2 repository on GitHub.
This branch contains the ongoing language modernization work before the changes are separated into individual pull requests for the official Geeklog repository.
Automated checks can detect structural problems, but they cannot replace native speakers.
If you use Geeklog in one of these languages, feedback is particularly useful for:
The objective is not simply to translate every English string, but to provide language files that are practical and comfortable to use on real Geeklog websites.
More plugin language updates are planned as this work continues.
Posted October 1, 2026 | 5:07 pmEclipse 1.2.0 is now available for Geeklog.
This release is an important milestone for the project. Eclipse started as a modern, responsive child theme based on Denim, but version 1.2.0 goes much further. It improves the administration experience, strengthens compatibility with Geeklog 2.2.2, introduces better interoperability with plugins, expands Menu integration and makes theme updates safer.
The project is available on GitHub:
https://github.com/hostellerie/eclipse
The stable 1.2.0 release is available here:
https://github.com/hostellerie/eclipse/releases/tag/v1.2.0
One of the main goals of Eclipse is to improve the daily experience of managing a Geeklog site without replacing Geeklog's own permission and plugin systems.
Eclipse 1.2.0 continues this work with a more complete Modern workspace, while still keeping the Classic Eclipse administration interface available.
The administration dashboard can now receive structured information from plugins through declared capabilities.
For example, a plugin can expose:
Eclipse displays this information without directly querying the plugin's private database tables.
This is important because it keeps responsibilities clearly separated: the plugin owns its data and business logic, while Eclipse is responsible for presentation.
Documents and Videos are already reference implementations of this approach, and other plugins can follow the same model.
Navigation has also received significant improvements.
Eclipse 1.2.0 can now work with independent Menu plugin locations for:
This gives site administrators much more freedom when building the structure of a site.
The theme also handles administration and public navigation separately. Secondary public navigation is no longer injected into administration pages, while the traditional primary navigation remains available when using Classic
Posted October 1, 2026 | 9:00 amFor many years, WordPress has been the obvious choice for a huge number of websites.
Its ecosystem is enormous. There are plugins, themes and integrations for almost everything. It is easy to understand why many people who once used Geeklog eventually moved to WordPress.
I considered that path too.
But today, I am increasingly glad that I stayed with Geeklog.
Some of my Geeklog websites have now been online for 21 years.
That changes the way I look at a CMS.
When a website survives for more than two decades, priorities change.
You start caring less about trends and more about stability, maintainability and control.
A CMS is no longer just a tool used to publish a few pages.
It becomes infrastructure.
Over the years, Geeklog has given me something that I value more and more: a relatively stable foundation that I can understand, maintain and extend.
Of course, Geeklog has not always moved as quickly as other platforms.
Its ecosystem is smaller.
Some plugins needed modernization.
Some interfaces clearly came from another generation of the web.
But the foundation remained usable.
And that matters.
Recently, my view of Geeklog has changed again.
I no longer see it simply as a CMS.
I increasingly see it as the foundation of a platform.
Forum, MediaGallery, Maps, Forms, Documents, Store, SEO tools and other plugins can become parts of a coherent ecosystem.
Existing plugins can be modernized.
Old code can be cleaned up.
Interfaces can be improved.
Plugins can share conventions and work together more closely.
New services can then be built on top of that foundation.
This is where things become interesting.
WordPress has thousands of solutions for almost every problem.
That is a major strength.
But it can also mean assembling many independent products, each with its own interface, dependencies, roadmap and sometimes its own commercial model.
Geeklog offers another possibility.
Instead of having hundreds of choices, we can focus on a smaller number of useful components and make them work well together.
For people who want to control their stack, this approach can be very attractive.
The goal is not to reproduce the WordPress ecosystem.
It is to build something smaller, understandable and dependable.
Geeklog has often evolved slowly.
In the past, that could easily be seen as a weakness.
Today, I see more nuance.
A stable core can be valuable when the ecosystem around it continues to improve.
The important thing is not to change everything constantly.
It is to modernize what needs modernization without destroying what already works.
That means supporting current PHP versions, improving interfaces, revisiting older plugins, improving interoperability and making development and maintenance easier.
This kind of evolution may be less spectacular than replacing an entire platform every few years.
But for long-lived websites, it can be much more useful.
Some people reading this probably used Geeklog years ago.
Maybe you eventually moved to WordPress.
Maybe you simply stopped following the project.
That is understandable.
But I think Geeklog deserves another look.
Not necessarily because you should migrate your current sites back.
Simply because interesting things are happening again.
Plugins are being reviewed and modernized.
New ideas are being explored.
Developers are improving existing components instead of starting from zero.
And the ecosystem has the potential to become more coherent.
Install Geeklog on a test site.
Explore the current plugins.
Look at the GitHub repositories.
Follow what is being developed.
You may be surprised.
It is also worth remembering that Geeklog is still here because people have kept it alive over the years.
Tom deserves a special mention for continuing to maintain and guide the CMS for so long.
Keeping an open-source project alive across many years, PHP generations and changes in the web ecosystem is not a small task.
For those of us who still run Geeklog sites today, that continuity has real value.
So thank you, Tom, for keeping the foundation in place and allowing the rest of us to continue building on it.
After more than two decades, some of my Geeklog sites are still running.
That alone makes me happy that I persisted.
But what excites me most is not the past.
It is what Geeklog could become next.
Not a competitor trying to beat WordPress at its own game.
Something different.
A stable, open and understandable foundation on which we can continue building.
And after 21 years, I am still curious to see how far we can take it.
Posted September 28, 2026 | 1:55 amA new major version of the Open Graph Protocol plugin for Geeklog is now available.
OGP 2.0.0 is a substantial modernization of the plugin, with a much clearer focus: generating reliable social metadata for Geeklog pages and for compatible content plugins.
The new version is available from the official Geeklog Plugins repository:
https://github.com/Geeklog-Plugins/ogp
Previous versions of OGP had accumulated several features related to Facebook integration, including Like buttons, Facebook Comments, SDK loading, autotags and configuration options.
Those features are now obsolete and have been removed in OGP 2.0.0.
The plugin now concentrates on one responsibility: providing the metadata that social platforms read when a Geeklog page is shared.
This includes:
Sharing buttons themselves are intentionally outside the scope of OGP. A theme such as Eclipse, or another dedicated component, can provide Facebook, X/Twitter or LinkedIn sharing buttons while OGP supplies the metadata read by those services.
One of the most important additions in OGP 2.0.0 is the new optional provider API:
OGP_registerSocialMetadata()
This allows a content plugin to register authoritative metadata for the page it owns before Geeklog renders the final document header.
A plugin can provide information such as:
This means plugins such as document, video, map or media plugins can expose richer social previews without OGP needing plugin-specific SQL queries or hard-coded dependencies.
The first provider that successfully registers metadata owns the social metadata for that request.
The provider API is optional.
If no content plugin registers metadata, OGP continues to use its traditional Geeklog page-detection system.
This legacy path has also been significantly improved in version 2.0.0.
For articles, OGP now prefers the dedicated page_title when available and falls back to the normal article title.
For Static Pages, sp_page_title is preferred with sp_title retained as the fallback.
Topic archive pages now use the more appropriate Open Graph type:
website
Configured SEO meta descriptions are also reused whenever possible.
Twitter/X Cards are now generated alongside Open Graph metadata, including when the historical Geeklog page-detection path is being used.
This gives older Geeklog content much more consistent social previews without requiring every content type to implement a dedicated integration.
Social networks generally expect relatively large preview images.
OGP 2.0.0 therefore improves image handling considerably.
Local image dimensions can now be detected and included in the generated metadata.
Very small images are rejected as social preview candidates and OGP instead falls back to the configured default social image.
The plugin now ships with a default social image sized at:
1200 × 628 pixels
This provides a more suitable fallback for modern Open Graph and Twitter/X previews.
The new provider contract can also expose richer metadata such as:
og:image:alt;og:video;og:video:secure_url;og:video:type;This is particularly useful for video and media-oriented plugins.
OGP 2.0.0 also fixes an issue in the historical autotag parser.
Modern content can contain CSS selectors using square brackets, for example:
input[type=text]
Older parsing behavior could mistakenly interpret this kind of syntax as a Geeklog autotag.
Unknown bracket syntax is now ignored safely, preventing CSS embedded in content from triggering OGP parsing errors.
OGP 2.0.0 removes the old Facebook-specific widget system entirely.
Removed components include:
[ogp:like] autotags;[ogp:comments] autotags;Old installation documentation referring to these features has also been removed or updated.
OGP 2.0.0 keeps a broad compatibility range:
The release pipeline validates the plugin using:
Article page_title support is only used on Geeklog 1.7.0 or newer, allowing the plugin to retain its Geeklog 1.6.0 minimum.
The backward-compatible metadata path has also been manually tested with Geeklog 2.1.1 for articles, topics and Static Pages, as well as with Geeklog 2.2.2.
The development process has also been modernized.
The release workflow now validates:
Successful builds produce an installable archive:
ogp_2.0.0_1.6.0.zip
together with a SHA-256 checksum.
The architecture of OGP 2.0.0 follows a simple principle:
OGP owns social metadata, while content plugins own their content.
Content plugins remain responsible for their canonical URLs and Schema.org structured data.
OGP does not contain hard-coded dependencies on optional plugins. Instead, integrations use the generic provider API.
This makes OGP useful on traditional Geeklog sites while also giving newer plugins a clean way to expose richer metadata.
OGP 2.0.0 is available now from the official Geeklog Plugins repository:
https://github.com/Geeklog-Plugins/ogp
If you maintain a Geeklog site that uses Open Graph metadata, this release is a significant upgrade and provides a much cleaner foundation for modern social sharing.
Posted September 26, 2026 | 2:37 amA substantial modernization effort has been completed on the Geeklog PayPal plugin in preparation for version 1.7.0.
This release focuses on making the existing plugin safer and more reliable on current environments while preserving compatibility with older Geeklog installations.
The target range is now Geeklog 2.1.1 through 2.2.2 and PHP 5.6 through PHP 8.x.
Among the most important changes are improved PHP 8 compatibility, safer install/upgrade/uninstall handling, a reorganized configuration interface with contextual help, modernized administration pages, improved cart persistence, cleaner checkout pages, dynamic Geeklog blocks, and better handling of PayPal Sandbox and merchant settings.
The cart and checkout experience has also received significant attention. Empty cart blocks are handled correctly, the checkout process is clearer and more responsive, shipping and payment methods are easier to understand, and buyers are better informed that card payment may be available through PayPal without requiring a PayPal account.
The historical PayPal autotags are preserved, and the new [paypal:count] autotag implements the long-standing request to display the current number of items in the visitor's cart.
This work also addresses existing issues from the PayPal repository, including the PHP compatibility problem reported in issue #3 and the cart-count autotag requested in issue #1.
PayPal 1.7.0 deliberately keeps the existing Website Payments Standard, IPN and NVP/SOAP payment architecture so existing sites can upgrade without a disruptive payment migration. A future major version can then focus on the current PayPal Checkout and REST APIs.
The plugin is available from the official Geeklog Plugins repository:
https://github.com/Geeklog-Plugins/paypal
The objective of this release is simple: provide Geeklog administrators with a stable and modernized PayPal plugin while preserving a safe upgrade path for existing installations.
Posted September 22, 2026 | 6:22 pmMediaGallery 1.8.0 is now available, and calling this release a simple update would seriously underestimate the amount of work that went into it.
MediaGallery has been one of the most complete media-management solutions available for Geeklog for many years. It can manage images, audio, video, files, albums, member galleries, moderation, RSS feeds, slideshows, EXIF/IPTC information, batch operations and much more.
But maintaining such a mature plugin also means dealing with years of changes in PHP, browsers, web security, Geeklog itself and the way modern websites store and expose media.
MediaGallery 1.8.0 tackles that technical debt head-on.
The objective was not to rewrite MediaGallery and risk losing its mature feature set. Instead, the goal was to preserve what already works while modernizing the foundations underneath it.
The result is probably one of the largest MediaGallery maintenance and modernization efforts undertaken in years.
One of the main challenges was compatibility.
MediaGallery 1.8.0 supports Geeklog 2.1.1 and newer, including Geeklog 2.2.2.
At the same time, the source remains compatible with PHP 5.6 syntax for sites that still need to complete their transition from older Geeklog installations.
The same code has also been checked against PHP 7.4, PHP 8.1 and PHP 8.3.
This required much more than simply fixing a few PHP warnings.
Configuration values that may not yet exist when Geeklog enables the plugin had to be safely initialized. Template variables and media playback paths were reviewed for PHP 8 behavior. Administrative scripts and maintenance routines were audited, and historical assumptions that PHP tolerated more easily had to be removed.
This work also incorporates or supersedes several issues reported through the official MediaGallery issue tracker, including PHP 8 compatibility problems, upload-size parsing, thumbnail filenames, comment permissions and Remote Media warnings.
One of the most important architectural changes in MediaGallery 1.8.0 concerns storage.
Historically, media could live below:
public_html/mediagallery/mediaobjects/
That becomes dangerous when a plugin is upgraded by replacing its public directory.
MediaGallery 1.8.0 moves user-generated media into persistent storage derived from Geeklog's configured image directory.
A typical installation now uses a location such as:
public_html/images/mediagallery/
This separation between plugin code and user data makes upgrades significantly safer.
It also works naturally with shared-code multisite installations. Each Geeklog site can have its own path_images, images_url and data directory while sharing the same MediaGallery code.
A migration tool is included for existing 1.7.x installations. It copies and verifies legacy media before the plugin ZIP is replaced and deliberately leaves the original files untouched.
This was extensively tested with upgrades from MediaGallery 1.7.3 and 1.7.0.
A media gallery lives or dies by reliable image handling, so a substantial part of the 1.8 development cycle focused on thumbnails, display images and originals.
Several long-standing or newly discovered edge cases were corrected.
MediaGallery can now reliably rebuild missing display images and thumbnails without unexpectedly modifying originals.
Maintenance batch processing was repaired so operations start correctly and report failures instead of ending on blank pages.
Attached thumbnails are no longer assumed to always be JPEG files. JPEG, PNG, GIF and BMP thumbnails can now be resolved using their real format.
Another important correction concerns DNC behavior. When an uploaded source image must be converted to JPEG, the conversion now takes place before display and thumbnail derivatives are generated. This keeps the files on disk and the MIME/extension information stored in the database consistent.
These may sound like small implementation details, but they make a significant difference on galleries containing thousands or tens of thousands of historical media files.
A plugin capable of accepting files from browsers, FTP directories, ZIP archives, command-line imports and remote URLs has a large security surface.
MediaGallery 1.8.0 reviews all of these paths.
The new version includes stronger filename validation, executable-extension rejection, MIME/extension consistency checks, FTP path confinement, ZIP traversal protection, symlink rejection and bounded HTTP(S) Remote Media retrieval.
Temporary files are cleaned more safely, and destructive operations revalidate album and media relationships before modifying data.
Batch processing also received special attention.
Geeklog 2.1.1 uses one-time, referer-bound security tokens. That behavior does not work naturally with a multi-request batch process.
MediaGallery now keeps normal Geeklog CSRF protection when the administrator starts an operation, while subsequent internal batch requests use POST requests, server-generated session IDs and ownership validation.
That provides compatibility with Geeklog 2.1.1 without making the batch interface publicly callable.
The moderation queue was another area that received a full review.
Queued uploads are now correctly kept separate until approval. Approval validates the queued media and album relationship before promoting the item into the live tables, while rejection removes both database entries and generated files.
MediaGallery also no longer needs its historical private mail implementation for these workflows.
Moderator notifications and approval messages now use Geeklog's own COM_mail() backend.
Both HTML and plaintext email templates are supplied.
This means MediaGallery benefits automatically from the mail configuration already maintained by the Geeklog site administrator.
MediaGallery has existed long enough to have supported technologies such as Flash, ActiveX, QuickTime browser plugins and MMS streaming.
Modern browsers have moved on.
MediaGallery 1.8.0 removes active Flash and ActiveX playback from maintained output and uses HTML5 audio and video where the browser supports the media type.
Formats such as MP4, MPEG and MOV can use modern browser playback, while obsolete formats such as FLV and SWF receive safe download or fallback behavior rather than attempting to launch unsupported browser plugins.
Historical media records therefore remain usable without forcing the plugin to preserve obsolete execution technologies.
The work is not limited to PHP and storage.
Public and administrative templates have been modernized using responsive CSS Grid and Flexbox layouts.
Album and media displays received accessibility improvements, semantic headings, better navigation landmarks and clearer form controls.
MediaGallery also now provides better canonical URLs, pagination-aware metadata, editorial meta descriptions where available and conservative structured data for image, audio and eligible video content.
Thumbnail rendering has also been improved, especially for portrait images where unnecessary scaling could previously reduce visual quality.
One of the most important changes for the future of the Geeklog ecosystem is the new interoperability layer.
Until now, another plugin wanting to work with MediaGallery albums often needed knowledge of internal mg_* database tables or MediaGallery PHP classes.
MediaGallery 1.8.0 provides a cleaner alternative.
Through Geeklog's native service mechanism, other plugins can request permission-filtered album trees, individual albums, media collections and individual media records.
Available services include album_list, album_read, media_list, media_read and dashboard_summary.
This work was designed around a consumer-neutral capability model.
Agent, Eclipse and the future Hub can discover and consume MediaGallery information, but MediaGallery does not depend directly on any of them.
The plugin also emits normal Geeklog lifecycle notifications when albums or media are created, modified, moved or deleted.
That means plugins such as IndexNow, XML Sitemap, Hub and future services can react to MediaGallery content changes without knowing its database schema.
This is a significant step toward making Geeklog plugins cooperate through stable APIs instead of private implementation details.
The objective throughout the 1.8 work was modernization without throwing away the features that made MediaGallery useful in the first place.
Albums, nested albums, member galleries, uploads, categories, EXIF/IPTC support, RSS, comments, ratings, slideshow functionality, random-media blocks, quotas, watermarks, batch maintenance and MediaGallery autotags remain part of the plugin.
A large administrator guide has also been retained and reorganized so administrators can access current documentation from the protected administration interface rather than relying on obsolete public documentation from older releases.
MediaGallery 1.8.0 has been tested on both ends of its intended Geeklog transition range.
Testing included Geeklog 2.1.1 and Geeklog 2.2.2, upgrades from MediaGallery 1.7.3 and 1.7.0, media-storage migration, image uploads, derivative generation, thumbnail rebuilding, display-image resizing, batch security, moderation, email delivery, representative audio/video playback, multisite operation and the new interoperability services.
Automated PHP syntax validation covers PHP 5.6, 7.4, 8.1 and 8.3.
The installable archive is generated and validated automatically from the release source.
If you are upgrading an existing MediaGallery 1.7.x installation, do not simply upload the new ZIP over the old plugin.
Legacy media stored inside:
public_html/mediagallery/mediaobjects/
must first be migrated to the new persistent storage location.
MediaGallery 1.8.0 includes tools/migrate-media-storage.php for this purpose.
The migration process copies and verifies the media while preserving the existing source files as a safety measure.
Read the included UPGRADE documentation before updating a production gallery, and always keep complete database and media backups.
MediaGallery 1.8.0 is not a cosmetic version bump.
It represents a substantial effort to take a mature and extremely capable Geeklog plugin, preserve its existing strengths and rebuild many of the foundations required for modern PHP, modern browsers, safer upgrades, better security, multisite environments and plugin interoperability.
For existing MediaGallery users, the release provides a much safer path toward current Geeklog and PHP versions.
For developers, it provides new services and lifecycle APIs that make MediaGallery much easier to integrate with other Geeklog components.
And for visitors, the result is a faster, cleaner and more modern media experience without abandoning years of existing content.
MediaGallery 1.8.0 is available from the official Geeklog Plugins repository:
https://github.com/Geeklog-Plugins/mediagallery
Posted September 22, 2026 | 5:30 pmMost websites need forms sooner or later.
A contact form. A quote request. Event registration. Feedback. Support requests. Surveys. Consent forms.
Until now, Geeklog site owners often had to rely on older solutions, custom code or external services for these common needs.
The first stable release of Forms 1.0.0 changes that.
Forms is an independent form builder designed specifically for Geeklog. It provides a simple way to create, publish and manage forms directly from the Geeklog administration interface.
For many sites, this is likely to become one of those plugins that simply makes sense to install.
Forms lets administrators create and manage multiple forms without depending on nexForm, nexPro or an external form service.
A form can contain common field types such as:
Fields can be reordered and configured with labels, placeholders, help text and required status.
This makes Forms suitable for everything from a simple contact page to more structured registration or request forms.
Starting from a blank form is not always necessary.
Forms 1.0.0 includes starter templates for common use cases:
These templates provide a useful starting point and can then be adapted to the needs of each site.
Forms does not create an unnecessary public catalogue of every form on the site.
Instead, each active form can be accessed through its own URL or embedded into existing Geeklog content with the autotag:
[forms:slug]
This makes it easy to place a form inside an article, Static Page or other content supporting Geeklog autotags.
A site can therefore integrate forms naturally into its existing structure instead of forcing visitors through a separate form directory.
Each form can be configured to store submissions in the Geeklog database.
Administrators can then review submitted data from the Forms administration interface and export stored submissions as CSV when needed.
Email notifications are also supported.
This allows Forms to cover both common workflows:
Database storage can also be disabled when it is not required.
Public forms inevitably attract automated submissions, so Forms 1.0.0 includes several protections.
Submissions use Geeklog CSRF protection, along with a honeypot field and minimum-fill-time checks.
When Spam-X is available, Forms can also integrate with it.
Anonymous submissions can be allowed or disabled independently for each form.
The plugin also keeps sensitive submission information separate from its interoperability services. Stored field values, recipients, IP hashes and user-agent information are not exposed through the public capability interface.
Forms 1.0.0 is not only a form builder.
It has also been designed to participate in the growing interoperability layer between modern Geeklog plugins.
The plugin exposes a standard capability declaration and provides these services:
forms.listforms.schema.readdashboard.summaryThis means other Geeklog components can discover what Forms provides without accessing its private database tables directly.
Agent and the future Hub can discover active forms and their schemas, while compatible administration interfaces such as Eclipse can retrieve Forms dashboard information through the shared service contract.
This approach keeps each plugin responsible for its own data while making the overall Geeklog ecosystem easier to integrate and extend.
Forms fills a very practical gap.
Almost every type of website eventually needs to collect information from visitors, members or customers.
A community site may need registration or feedback forms.
A business website may need quote requests.
An association may need event registrations.
A support-oriented site may need structured requests.
A content site may simply need a better contact form.
Instead of creating a separate solution for each use case, Forms provides one reusable foundation directly inside Geeklog.
That is what makes this first stable release particularly useful: it is not a niche feature. Forms can become a basic building block for a large number of Geeklog installations.
Forms 1.0.0 supports the current transition range used by many existing Geeklog sites:
Existing 0.x installations can use Geeklog's normal plugin upgrade mechanism.
Forms 1.0.0 is available from the Geeklog-Plugins repository on GitHub:
https://github.com/Geeklog-Plugins/forms
Download the installable archive, install it from Geeklog's Plugins administration page, then open Command and Control > Forms to create your first form.
For many Geeklog sites, Forms 1.0.0 should quickly become one of the essential plugins to have installed.
Posted September 19, 2026 | 10:30 pm