Overview

What the Davix H2I WordPress Plugin Is #

Davix H2I is a WordPress plugin that adds media optimization, HTML-to-image generation, and image analysis workflows inside WordPress. In the plugin header and bootstrap, it is identified as Davix H2I, with version 1.0.1, text domain davix-h2i, minimum WordPress requirement 6.0, and minimum PHP requirement 7.4. The bootstrap file is davix-h2i.php, and the runtime loads feature modules from includes/.

The plugin is built around three main feature domains:

• Image workflows for previewing and generating processed image outputs
• H2I workflows for rendering HTML into image or PDF output
• Tools workflows for image analysis, specifically hash and similarity operations

In addition to those feature areas, the plugin also includes:

• optional upload-time auto-optimize
• a WordPress admin settings surface
• a logging system with a log viewer

Davix H2I is not documented as a local rendering or optimization engine. The plugin-side code prepares requests, sends them to PixLab, and then parses, downloads, and persists returned outputs back into WordPress media storage when generation mode is used.

Core capabilities #

Image workflows #

The plugin supports manual image optimization through two REST-backed flows:

• Preview runs through /davix-h2i/v1/image/preview and returns preview URLs without writing attachments.
• Generate runs through /davix-h2i/v1/image/generate and persists outputs into the Media Library by either replacing the existing attachment or creating a new attachment, depending on the selected output mode.

The image workflow uses a chip-based model. Supported chip groups are:

• smart
• format
• resize
• crop
• transform
• effects
• padding
• frame
• background
• watermark

Both the UI and the server-side processing filter image fields so that only fields associated with the selected chips are sent and accepted.

Image generate supports two output modes:

• replace, which updates the existing attachment
• copy, which inserts a new attachment

When copy mode is used, a suffix can be applied to the output filename. Bulk image processing is also supported through selected attachment ID arrays.

H2I workflows #

The H2I feature supports preview and generate for HTML-based rendering.

• Preview is exposed through /davix-h2i/v1/h2i/preview and returns either a single URL or bulk results, depending on the request shape.
• Generate is exposed through /davix-h2i/v1/h2i/generate and persists generated results into WordPress media storage. Like Image generate, H2I generate supports replace and copy output behavior.

The H2I handlers read HTML, CSS, width, height, format, attachment context, selected IDs, output mode, and suffix. The feature also supports token replacement before the outbound request is sent. Supported tokens are:

• {site_name}
• {site_logo_url}
• {selected_image_url}
• {author_name}
• {date}
• {post_title}

These tokens are replaced from runtime context before the final HTML and CSS payload is sent upstream.

Tools workflows #

The Tools tab supports image-analysis operations for hash and similarity.

Supported hash types are:

• phash
• md5
• sha1
• sha256

Supported similarity modes are:

• pairs
• tofirst

Similarity threshold input is accepted in the range documented by the plugin and is sanitized server-side. If similarity is selected with fewer than two images, the request is rejected. For exact limits and related errors, use the central Errors and Limits page.

Automatic optimization on upload #

The plugin can run automatic optimization during the wp_generate_attachment_metadata lifecycle. This behavior is attached to the wp_generate_attachment_metadata filter and is documented as replace-only, meaning the optimized result is written back over the existing attachment path instead of creating a copy in that flow.

The code-backed documentation also identifies several skip conditions, including disabled state, recursion-guard hits, already auto-optimized attachments, generated-image skip rules, non-image MIME types, missing files, and downstream processing failures.

The auto-optimize flow uses these metadata markers:

• _davix_h2i_generated
• _davix_h2i_auto_optimized

Logging and log viewing #

The plugin includes a logging subsystem controlled by the option davix_h2i_log_enabled. When enabled, logging writes to the uploads directory under:

davix-h2i/logs/davix-h2i-<token>.log

The plugin also hardens the log directory by creating:

• index.php
• .htaccess
• web.config

Log viewing is available through REST routes, AJAX refresh handlers, and an admin-post standalone viewer path.

Where the plugin appears in WordPress admin #

Davix H2I appears in WordPress admin in two main places: the settings area and media-related interfaces. The plugin registers:

• a top-level admin menu called Davix H2I
• a settings submenu using the same slug, davix-h2i-settings
• a hidden log viewer page with slug davix-h2i-log-viewer

The settings page is rendered by includes/views/settings-page.php and exposes these top-level tabs:

• General
• Image
• H2I
• Tools
• Debug Log
• Help

Documented subtabs include:

• Image: Defaults, Auto-Optimize
• Help: About, Support

In media workflows, the plugin injects modal UI templates into:

• upload.php for the Media Library
• post.php for the attachment edit screen, but only when the current post type is attachment

The modal template is includes/views/modal.php, and the plugin localizes client-side runtime data through the DavixH2IData object. That object includes the REST base URL, REST nonce, settings URL, log viewer URL, tooltips, documentation URLs, and default settings data used by the UI.

The Media Library list view also gets a bulk action labeled Edit with Davix H2I, using action key davix_h2i_edit.

[Image placeholder — WordPress admin settings page showing the Davix H2I top-level menu and tabs: General, Image, H2I, Tools, Debug Log, and Help]

[Image placeholder — Media Library screen showing the Davix H2I modal opened from selected attachments]

How the plugin connects to the H2I engine (PixLab) #

The plugin connects WordPress to PixLab through a shared HTTP client layer. The default PixLab base URL constant is DAVIX_H2I_PIXLAB_BASE_URL, with default value:

https://pixlab.davix.dev

Runtime URL resolution is handled by davix_h2i_get_base_url(), which can apply the davix_h2i_base_url filter and then normalize the final value.

The documented service URLs are built under the normalized base as:

• <base>/v1/image
• <base>/v1/h2i
• <base>/v1/tools

Feature-specific wrappers send requests through the shared client, which handles URL normalization, header construction, optional idempotency headers, timeout, retry count, and response checks.

Authentication is configured in plugin settings through the stored API key and auth mode:

• API key option: davix_h2i_api_key
• auth mode option: davix_h2i_auth_mode

The documented auth modes are:

• x-api-key
• bearer

When auth mode is bearer, the plugin sends Authorization: Bearer <api_key>. Otherwise, it sends X-Api-Key: <api_key>. The documented default and fallback mode is x-api-key.

The source-backed installation and troubleshooting documentation also confirms that outbound base URLs must use HTTPS, and downloaded result URLs are restricted to HTTPS and the configured base host.

Supported workflows #

At a high level, the plugin supports these user-facing workflows:

• Manual image workflows: choose chips and fields, preview output, then generate a result that either replaces the attachment or creates a copy
• Manual H2I workflows: provide HTML and optional CSS, choose output settings, preview the render, then generate a saved media result
• Tools analysis workflows: analyze selected images with hash and similarity operations and receive structured results
• Upload-time auto-optimize workflows: automatically run optimization during attachment metadata generation when enabled
• Log viewing workflows: allow administrators with the required capability to review plugin logs

Requirements and access model #

Platform requirements #

The plugin header declares:

• WordPress 6.0+
• PHP 7.4+

Capability requirements #

The documented access model distinguishes between configuration and log access, and feature execution access.

• Settings pages and log viewer paths require manage_options
• Feature REST routes for Image, H2I, and Tools require a valid REST nonce and the upload_files capability
• Handlers also apply per-attachment permission checks using current_user_can( 'edit_post', $attachment_id ) for selected attachments

Nonce and authenticated request model #

Feature REST requests are protected by the plugin’s REST permission callback, which validates x_wp_nonce for the wp_rest action before checking capabilities. Log routes use a separate log permission callback with manage_options.

Filesystem requirements #

Writable uploads storage is required for normal operation because the plugin:

• writes logs into the uploads path
• creates log hardening files
• uses download, sideload, and temp-file flows
• updates or inserts attachments and regenerates attachment metadata during generate flows

External service dependency #

PixLab is a required dependency for processing in the documented Image, H2I, and Tools flows. The plugin-side code builds and sends requests, then receives and persists returned artifacts. The loaded documentation does not describe local fallback processing for those feature areas.