Plugins often need to run tasks on a schedule — clean up old data, sync with an API, send digest emails, or refresh a cache. WordPress handles that with WP-Cron: pseudo-cron events stored in the database and triggered on page loads (or by a real system cron hitting wp-cron.php). Setting up a scheduled task means…
Interactive admin screens, front-end forms, and live search often need background requests without a full page reload. In WordPress, that usually means AJAX through admin-ajax.php and the wp_ajax_* action hooks. Each handler needs a registered action, nonce verification, capability checks, sanitized input, and a JSON response via wp_send_json_success() or wp_send_json_error(). This guide covers the pattern…
Not every plugin screen is a Settings API options page. Sometimes you need a dedicated admin area — a reports dashboard, import tool, onboarding wizard, or documentation hub. WordPress registers those with the admin menu API: add_menu_page() for top-level items and helper functions like add_options_page() or add_management_page() for submenus. Hand-coding menu registration, capability checks, render…
Headless front ends, mobile apps, Gutenberg blocks, and admin dashboards all lean on the WordPress REST API. When your plugin needs custom data or actions beyond core endpoints, you register your own routes with register_rest_route(). That means choosing a namespace, defining the path, wiring HTTP methods, setting a permission callback, and writing handlers that return…
The WordPress dashboard is the first screen many users see after login. Plugins often add a dashboard widget there — quick stats, onboarding checklists, support links, or a snapshot of plugin activity. Registering a widget means hooking wp_dashboard_setup, calling wp_add_dashboard_widget(), and writing a render callback. It is not hard, but the same boilerplate shows up…
Every plugin eventually needs to talk to site owners in wp-admin — onboarding tips, upgrade prompts, configuration reminders, or warnings when something is misconfigured. WordPress handles that with admin notices: the colored banners you see at the top of dashboard screens. Hand-writing notice code is repetitive: hook into admin_notices, output the right CSS classes, check…
When something breaks in WordPress, debug.log is often the fastest source of truth — PHP notices, fatal errors, and plugin warnings. The pain is getting to the file: FTP, SFTP, cPanel File Manager, or hunting the path on every host. Here’s how to enable logging properly, and how the Debug Log Viewer in Zelvigo Dev…
WordPress runs on hooks: actions and filters. When a plugin changes output unexpectedly, fires too early, or fights another plugin, the question is always the same — what is registered on this hook, and who owns it? This post explains how to think about hooks while debugging, and how Hook Explorer in Zelvigo Dev Studio…
Starting a WordPress plugin from zero is mostly ceremony: folder name, main file, plugin headers, text domain, requires PHP/WP, and wiring includes. Starting from an old project is worse — you inherit dead code and forgotten renames. A better approach: generate the modules you need, then export a clean installable ZIP with Zelvigo’s Plugin Boilerplate….
Almost every serious WordPress plugin needs a settings page — API keys, defaults, feature toggles, display options. The Settings API is the WordPress way to do that safely (options, capabilities, and admin UI). This guide explains the moving parts, why hand-coding settings pages feels slow, and how the Settings API Generator in Zelvigo Dev Studio…