WordPress & Gutenberg FAQ

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.

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, 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.

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.

Yes, and it is recommended for automated pipelines. The –minor flag restricts updates to the current major branch (e.g. 6.x → 6.x patch), skipping major version jumps.

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.

No. Step 4 accepts both git pull and tar -xzf. If the server has Git, pull the branch. If not, upload a tar archive via SFTP and extract it. All other steps are identical.

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.