No — this action fires as notification, not permission. It can't stop the delete from proceeding.

Not yet — metadata generation happens afterward. Hook wp_generate_attachment_metadata if you need sizes or EXIF data.

Yes — hook wp_logout (or the logout_redirect filter for more control over the target URL) and call wp_safe_redirect() followed by exit.

Yes, that's a very common pattern — check current_user_can() and wp_redirect() + exit if the check fails, being careful to allow admin-ajax.php requests through.

Yes, but it's primarily meant for themes. Plugins usually use plugins_loaded or init instead.

Return an empty string from the filter — WordPress will render the footer area with no text.

Yes — search $classes with array_search() and unset() the key, then return the array.

Only if something still links to it directly. This filter changes what wp_login_url() outputs; it doesn't disable the real wp-login.php endpoint.

No — this fires before wp_insert_attachment() creates the post, so there's no attachment ID available yet.

It helps, but deliverability mainly depends on SPF/DKIM/DMARC records and your mail sending method — this filter alone won't fix a misconfigured domain.

No. Elementor is optional. The Gutenberg block and [forwp_booking] shortcode work on any block theme without page builders.

No. Clinic Cards is a third-party service by Cliniccards Corp. 4WP Booking is an independent product by 4wp.dev that communicates with Clinic Cards via their documented API.

Clinic Cards is a cloud CRM for dental clinics — interactive schedule, patient cards, visual treatment plans, finances, inventory, online booking, and eHealth integration. 4WP Booking connects your WordPress site to their public API.

When a visitor submits the booking form: name, phone, email, optional comment, selected service, date, and time. Data is sent only on submit, not during browsing.

In WordPress options on your server. The key is never included in front-end HTML or JavaScript — all API requests are server-side HTTPS calls to cliniccards.com/api.

Yes, drafts are also scanned and shown as sources. Status is visible in the “Used in” list on FAQ Cards when sources are enabled.

List and Categories share include/exclude even when they sit in different columns. Two categories on the List → the same two in the nav. More on the nav → the List includes those too. Empty include on one side inherits the other; empty on both means all categories. All categories always shows that synced set, not a different universe of questions.

It scans all posts looking for forwp/faq wrapper. Inside, it takes Accordion items/Details blocks and extracts: question, answer, post_id, post_type, and permalink.

Complete registry setup, run a rescan, then in the Site Editor add 4WP FAQ Categories (sidebar) and 4WP FAQ List (main column). Optionally add a core Search block and turn on 4WP FAQ → Filter 4WP FAQ List. Questions stay on the real pages; the hub only reads the registry.

Add core Accordion (or item) → Click “Convert to FAQ” → Plugin wraps it in forwp/faq without changing appearance.

Not yet. Apple Health has no web OAuth flow. A future release may add an iOS bridge or third-party aggregator through the provider registry.

No. Samples are stored in your WordPress database on your server. The plugin does not phone home to 4wp.dev.

Google OAuth for authorization and the Google Fitness API for activity datasets — steps, distance, calories, and exercise sessions — only after the user consents and an admin saves valid OAuth credentials.

A WordPress plugin that lets logged-in users connect Google Health / Fitness data — with admin charts, Gutenberg metric blocks, REST endpoints, and a provider registry for future sources.

Clone or download from GitHub. Part of the 4WP Bundle ecosystem.

Yes. Choose the custom SVG option in the icon library when Lucide does not include your mark — useful for logos and client-specific assets.

Yes. Toolbar controls add icons to Button, Heading, Paragraph, List, and Quote blocks in addition to the standalone 4WP Icon block.

No. Icons render as inline SVG on the server. Visitors do not load a Lucide React runtime — keeping pages lightweight.

A Gutenberg block plugin that brings the Lucide icon set (1000+ icons) into WordPress with a searchable picker, custom SVG support, links, and inline icons for selected core blocks.

Source and releases are on GitHub. It powers iconography across 4WP.dev and ships as part of the 4WP Bundle ecosystem.

No. Templates keep base slugs like header. You create locale-specific template parts (header-en, footer-de, etc.) or map custom slugs in the admin table.

Swapping runs on the front end (and is suspended during admin/REST). Editors still manage all parts in the Site Editor; admin tabs help map, clone, and audit coverage.

Version 0.2 adds pattern language scope and filters the block pattern inserter via REST so editors see patterns relevant to the active language.

It resolves base FSE template part slugs (header, footer, and custom parts) to language-specific versions on the front end, based on the active Polylang or WPML locale.

The resolver falls back to the base slug so the site keeps working. The Design System tab highlights missing variants so you can clone them in one click.

MVP includes ICS feed export and per-item “Add to Google Calendar” links. Two-way Google OAuth sync is on the roadmap — see GOOGLE-SETUP.md in the repository for current setup notes.

No. Planning only — no automated actions. 4WP Planner helps you organize work and due dates; it does not post to WordPress, social networks, or deploy plugins on your behalf.

Not yet. Install from the GitHub repository. An official directory listing has not been submitted.

No — early-stage development. The plugin is actively evolving (currently v0.3.0). APIs, admin screens, and calendar sync may change between releases. Use on staging or internal installs until we publish a stable roadmap.

Yes — namespace fwpp/v1 with routes for projects, plans, items, calendars, insights, and meta. Useful for future dashboards or internal tooling; treat endpoints as unstable during early development.

Yes. Presets use named utility classes; arbitrary values use a has-forwp-*-custom class with a CSS variable (for example --forwp-padding-top-mobile: 150px) instead of inline styles.

No. The plugin extends blocks that already support spacing, typography, and alignment — such as Heading, Paragraph, Group, and List — via sidebar controls.

No. Output is limited to utility CSS classes and CSS variables. A single generated stylesheet handles responsive rules — no front-end script dependency.

Spacing and font-size presets are read from the active theme’s theme.json. Breakpoints can be defined in settings.custom.breakpoints; when present, they override plugin defaults and lock conflicting admin fields.

Not yet. The plugin has not been submitted to the official WordPress.org directory. Install and review the source from the GitHub repository.

No. Each 4WP plugin works standalone. Bundle is recommended when you run several 4WP plugins and want one dashboard, catalog sync with GitHub, and shared addon blocks in the editor.

Go to 4WP Bundle → Addons, check or uncheck each addon, and click Save. Disabled addons are not registered on init, so they disappear from the block inserter.

Download the zip from github.com/4wpdev/4wp-bundle, upload via Plugins → Add New, or use the Bundle dashboard to install sibling plugins from the catalog. Activate under Plugins.

Under 4WP Bundle → Blocks, the UI lists every installed 4wp-* plugin and compares versions against the remote plugins.json manifest from GitHub. You can install missing plugins via download URL, activate or deactivate, update when a newer release exists, and open README or documentation links.

Yes — GPL v2 or later. Source on GitHub, maintained by 4WP.dev. Not on WordPress.org yet; install from GitHub or via the ecosystem dashboard.

Yes. Pass the full URL including the path to wp core install –url=. Download and config steps stay the same; only the site URL changes.

No. WordPress needs database credentials in wp-config.php before installation. Without config, WP-CLI cannot connect to MySQL and the install will fail.

Only when the database named in wp-config.php does not exist yet. On shared hosting the database is often pre-created — then skip this step. On local dev, create it with WP-CLI.

For most installs, use the latest stable release without –version. Pin a version only when you intentionally need parity with production or a legacy environment.

Use an empty directory for a fresh site. WP-CLI downloads core files into the current working directory. Mixing with existing files can leave stale plugins or themes from an old project.

Yes. WP-CLI runs the .sql file against the current database, which typically begins with DROP TABLE IF EXISTS statements for each table. The result is a clean replacement of the existing data, not a merge. This is why the export step before import is critical — anything not in the backup file will not exist after the import.

Run grep 'siteurl' backup.sql | head -5 before importing. The siteurl value in the dump shows which site and domain the backup came from. If it shows a localhost or staging URL, you will need to run wp search-replace after the import to fix all domain references.

WP-CLI reads the database host, name, user, and password directly from wp-config.php. You do not need to pass credentials on the command line. This is why wp db import backup.sql works without any additional flags.

The database may be in a partially restored state. First, check the error message — it usually points to a specific table or SQL statement. If the import file is valid, try running it again (WP-CLI’s import is generally idempotent for standard WordPress dumps because each table is dropped before recreating). If the file itself is corrupted, you need an earlier backup.

wp db export is a thin wrapper around mysqldump that reads credentials from wp-config.php automatically. The resulting .sql file is compatible with wp db import and standard MySQL import tools. The main advantage over raw mysqldump is that you do not need to manually pass host, user, password, and database name on the command line.

Yes. 4WP.dev offers subcontract and direct hire for block libraries, editor UX, plugin MVPs, and production hardening. Review the plugin portfolio first, then request a conversation.

Yes — common requests include Gutenberg migration, security hardening, test coverage, REST API cleanup, and SOLID restructuring without breaking live sites.

Yes. Full Site Editing themes, reusable block patterns, theme.json design systems, and editor-only block addons for agency design systems are core strengths.

Yes. Engagements can run under your agency brand with direct technical communication, clear handoff docs, and Git-based delivery your team can maintain.

Audit open-source repos on GitHub, read architecture docs, inspect release cadence on WordPress.org, and review plugin singles on 4wp.dev — all public proof of how code is structured and shipped.

Most are open source (GPL v2+) and free to install. Some are on WordPress.org; others install from GitHub, including via 4WP Bundle. There are no hidden license traps.

Yes. They are built as a suite. 4WP Bundle helps install, activate, and update when you run more than one.

No. Install from the plugin page or WordPress.org, activate in wp-admin, then follow the short setup on each product page. Settings and blocks live in the WordPress admin and editor.

Check the latest release on WordPress.org or GitHub, read the product page, and skim the matching article when one exists. Public repos and release notes are the audit trail.

Start with the product documentation, then contact 4WP.dev for guided setup or a small configuration adjustment.

Yes. 4WP Bundle exposes 4wp/v1 REST endpoints; MCP Abilities connects AI agents to WordPress via the Abilities API — both with public source on GitHub.

Yes, under GPL v2+. Fork, adapt, and ship — respect the license and attribution. Many patterns (block wrappers, REST controllers, inventory tables) are reusable starting points for commercial work.

Yes — block.json, InnerBlocks, block variations, Interactivity API, block bindings, Query Loop extensions, and editor sidebar plugins appear across the suite (FAQ, Advanced Code, QL Blocks, SEO Helper, MCP Abilities).

Study plugin singles under /plugin/, clone repos, and follow guides on hooks, blocks, inner blocks, Interactivity API, and block bindings. Each plugin is a case study — not a toy demo.

Content is anchored in shipped plugins — real settings screens, edge cases, release history, and SEO/GSC workflows. You learn from code that runs in production, not isolated snippets.