| 开发者 |
developersd
sudipdebnath |
|---|---|
| 更新时间 | 2026年8月20日 06:37 |
| PHP版本: | 8.1 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
manage_options)<script>, <style>, <iframe>, or PHP is ever permitted inside a templateon* event handlers, no style/src/href overridesdevelopersd_ to avoid naming collisions. The codebase follows WordPress Coding Standards and an OOP, single-responsibility architecture:
Developersd_Post_Types — CPT + taxonomy registration, meta boxes, savingDevelopersd_Template_Manager — data access, recursive sanitizationDevelopersd_Renderer — JSON → HTML rendering, template_include hookDevelopersd_Admin — settings screen, list table, plugin linksDevelopersd_Assets — scoped script/style enqueueingDevelopersd_Ajax — preview + duplicate endpointsDevelopersd_Database — prepared-query helpers, cache managementdevelopersd_allowed_tags — add/remove permitted HTML tagsdevelopersd_content_types — add new content type handlersdevelopersd_rendered_template — filter final template HTMLdevelopersd-custom-theme-templates folder to /wp-content/plugins/, or install the zip via Plugins → Add New → Upload Plugin.No. Templates are stored as JSON in the database and rendered at request time through a template_include hook. Nothing is ever written to your theme's directory.
Templates keep working, since your theme's get_header() and get_footer() are still used — only the main content area is generated by the plugin.
div, section, header, footer, article, aside, main, nav, h1–h6, p, span, and strong. Script tags, iframes, inline styles, and PHP are never allowed.
All templates, categories, and settings are permanently removed when the plugin is deleted from the Plugins screen (not on simple deactivation).
No. Once a template is assigned to a page/post (either explicitly, or as a post type's global default), the plugin takes over rendering as early as possible in the request — before other plugins' own template logic typically runs — and stops the request from continuing to any other template resolution. This is intentionally the highest-priority mechanism available to a normal WordPress plugin.
Yes. On a template's edit screen, under Template Assignment, check "Use as global default" next to a post type. Every post of that type will use it automatically unless that specific post explicitly picks a different template. Only one template can be the global default per post type at a time.
Set an element's Content Type to "Dynamic Featured Image", then choose Image Display: "Background Image" applies the current post's featured image as that element's CSS background (with Background Size/Position/Repeat, and a Min Height so it's actually visible — 150px by default if left blank) — check "Center content over this image" to vertically/horizontally position child elements (a title, text, a button) on top of it for a hero/banner section. "Normal Image" instead renders it as a plain, ordinary <img>, with an optional Image Fit control.
Yes. On a template's edit screen, the Sidebar metabox lets you enable a sidebar with its own drag-and-drop element tree (built exactly like the main content), choose which side it sits on, set its width as a percentage (main content automatically fills the rest), and set the screen width at and below which it stacks under the content as full width instead of sitting beside it.
<style> tag embedded directly in the page body, instead of through WordPress's proper style-enqueuing system. It's now attached via wp_add_inline_style() on wp_enqueue_scripts, so it's correctly present in <head> like any other stylesheet. (The admin builder's live preview, which renders inside a standalone iframe with no real page or wp_head to hook into, still uses an inline <style> tag — that's the correct approach for that isolated context specifically.)load_plugin_textdomain() call — translations are now auto-loaded by WordPress based on the plugin's headers.the_content filter (to apply standard content processing to dynamic content) is now documented in place rather than flagged as a new hook.<img>, with its own optional Image Fit control).exit() guard so nothing registered later in the request can override an assigned template.style attribute, which always wins the CSS cascade over stylesheet rules regardless of matching media queries. Desktop, Tablet, and Mobile are now all emitted as equal-specificity class rules in the same stylesheet, so each breakpoint correctly overrides the wider one as the viewport narrows.styles object (possible on templates created in earlier 1.0.x/1.1.0 testing) would throw a JavaScript error while rendering the builder, silently preventing that element's margin/padding/color/alignment fields — and in some cases all of its fields — from having their changes captured for saving. The builder now normalizes any loaded template data on open, and isolates rendering errors per-element so one bad node can never block the rest of the tree from working.manage_options check throughout, and moved the plugin to its own top-level admin menu.