Installation and Setup

Installing the Plugin #

Davix H2I is a standard WordPress plugin with bootstrap file davix-h2i.php. The loaded source-backed documentation describes it as being installed into WordPress using normal WordPress plugin installation methods and then activated in wp-admin. The installation documentation does not describe any custom installer, migration wizard, CLI installer, or database-setup step beyond standard WordPress plugin installation.

The plugin header declares these platform requirements:

• WordPress 6.0
• PHP 7.4

The plugin runtime is loaded from davix-h2i.php, which includes supporting modules from includes/, including helpers, settings, debug, image, H2I, tools, upload automation, and API client files.

Activating the Plugin #

Activation is handled by a registered activation hook:

register_activation_hook( DAVIX_H2I_PLUGIN_FILE, 'davix_h2i_on_activate' )

The activation callback is davix_h2i_on_activate(). Based on the loaded plugin documentation, activation performs one confirmed setup action: it ensures the API key option exists and is stored with autoload disabled. It does not create custom database tables, run schema migrations, register cron jobs, or initialize a custom filesystem structure during activation.

The documented activation behavior is:

• check whether option davix_h2i_api_key exists
• if it does not exist, create it with an empty value and autoload disabled
• if it already exists, rewrite the current value with autoload disabled

The current repository-backed docs also confirm that no deactivation hook is implemented.

Opening the Plugin Settings Page #

After activation, the plugin appears in wp-admin as a top-level admin menu titled Davix H2I. The main settings page slug is davix-h2i-settings. The settings submenu uses the same slug. A hidden log viewer page is also registered with slug davix-h2i-log-viewer, but it is not the primary setup entry point.

The settings form is rendered by includes/views/settings-page.php. The source-backed UI documentation confirms these main tabs:

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

It also confirms these subtabs:

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

The settings surface requires the manage_options capability.

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

Connecting Your API Key #

The plugin stores the API key in option davix_h2i_api_key, represented by constant DAVIX_H2I_OPTION_API_KEY. This is the credential value used when building outbound requests to PixLab.

The General settings area includes the API key field. The loaded installation and setup documentation confirms that connecting the plugin involves saving the API key in this settings surface.

The API key sanitization behavior is specifically documented:

• input is sanitized with sanitize_text_field( wp_unslash( $value ) )
• if the submitted sanitized value is empty, the sanitizer returns the existing stored value
• a non-empty submitted value replaces the stored value

That means submitting a blank value does not clear an already saved API key.

The outbound request client reads this stored option when building request headers. The loaded security and integration documentation confirms that the API key is used either as X-Api-Key or as a Bearer token depending on the configured auth mode.

[Image placeholder — Plugin settings page showing the API key field in the General tab]

Choosing the Authentication Mode #

The plugin stores authentication mode in option davix_h2i_auth_mode, represented by constant DAVIX_H2I_OPTION_AUTH_MODE. The documented authentication behavior is:

• if auth mode is bearer, outbound requests use Authorization: Bearer <api_key>
• otherwise, outbound requests use X-Api-Key: <api_key>

The source-backed documentation also confirms that the default and fallback auth mode is x-api-key when no value is set.

For installation and setup, this means the General settings page is where the user saves both:

• the API key
• the authentication mode used for outbound PixLab requests

The loaded docs do not describe any OAuth flow, token exchange, login popup, or separate credential wizard. The supported setup model is API-key-based configuration inside plugin settings.

Base URL and Connection Behavior #

The plugin defines the default PixLab base URL constant as:

DAVIX_H2I_PIXLAB_BASE_URL = https://pixlab.davix.dev/

Runtime resolution is handled by davix_h2i_get_base_url(), which applies the davix_h2i_base_url filter and then normalizes the result by trimming, removing a trailing slash, and removing a trailing /v1 when present.

The documented service allowlist is limited to:

• image
• h2i
• tools

These are turned into outbound endpoints under the normalized base:

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

All feature wrappers use POST requests.

The connection model also has security restrictions that matter during setup:

• the base URL must resolve to HTTPS
• if the base URL is not HTTPS, requests fail with davix_h2i_insecure_base_url
• download URLs for generated results are also restricted to HTTPS and to the configured base host

A working installation therefore requires an HTTPS PixLab endpoint and outbound HTTPS access from the WordPress environment.

What Activation Does and Does Not Prepare #

The loaded admin-operations and changelog documentation make the activation scope clear.

What activation prepares

Activation prepares only the API key option state:

• ensures the API key option exists
• ensures it is stored with autoload disabled

What activation does not prepare

The source-backed docs explicitly say activation does not do the following:

• no database schema migrations
• no custom database tables
• no scheduled task or cron registration
• no filesystem initialization routine
• no option migration routine beyond current option usage and sanitization/default getters

This matters for setup because the plugin becomes usable through settings configuration rather than through a one-time installation wizard or backend provisioning routine.

Capability and Access Requirements During Setup #

The loaded docs distinguish between setup access and runtime media-operation access.

Settings access

To open the settings page and manage plugin configuration, the user must have manage_options. That same capability is also used for the log viewer.

Runtime media-operation access

The plugin’s REST feature routes for Image, H2I, and Tools require:

• a valid REST nonce in header x_wp_nonce
• nonce action wp_rest
• the upload_files capability

Handlers then apply per-attachment permission checks using current_user_can( 'edit_post', $attachment_id ).

For setup documentation, that means:

• an administrator or equivalent capability holder is needed to configure the plugin
• users performing media operations must also satisfy the documented runtime capability checks

Filesystem and Environment Requirements #

A successful installation also depends on the WordPress environment meeting the plugin’s runtime filesystem and network expectations.

Uploads directory and writable storage

The plugin writes to uploads-backed storage for several runtime actions:

• log files under the uploads path
• sideloaded and generated result files
• temporary files created during binary handling
• media replacement or copy-output persistence

The source-backed docs also confirm the log directory is hardened by creating:

• index.php
• .htaccess
• web.config

Outbound HTTPS access

The plugin uses wp_remote_request() to send outbound HTTPS requests to PixLab service endpoints. The documentation confirms that outbound HTTPS connectivity must be allowed for normal operation.

Existing media files for media workflows

Image, H2I, and Tools handlers all rely on attachment resolution and file existence checks for media workflows. If attached files are missing on disk, those operations can fail with documented missing-file errors.

Logging Setup During Installation #

Logging is optional, but the plugin provides a defined logging setup path during configuration.

The option key is davix_h2i_log_enabled, also referred to by constant DAVIX_H2I_LOG_OPTION. When this option changes, the plugin calls davix_h2i_toggle_log() through the update hook update_option_davix_h2i_log_enabled.

The documented side effects are:

When logging is enabled

• the log directory is created or hardened
• the active tokenized log file is created or truncated

When logging is disabled

• matching davix-h2i*.log* files are deleted if present

During initial setup, enabling logs is therefore an explicit configuration choice rather than an always-on default.

Setup Flow Summary #

The fully source-backed installation and setup flow is:

1. Install Davix H2I as a standard WordPress plugin.
2. Activate the plugin. Activation only ensures the API key option exists and is stored with autoload disabled.
3. Open the Davix H2I settings page in wp-admin using the top-level menu slug davix-h2i-settings.
4. Save the API key in the General settings section.
5. Choose the authentication mode: x-api-key or bearer.
6. Ensure the environment can reach the HTTPS PixLab base URL and that uploads storage is writable.
7. Optionally enable logging if operational troubleshooting is needed.