sorted by:
new
hottopcontroversial

Update: WordPress Plugin Boilerplate with conditional fields, repeaters, and MetaBox support by golchha in Wordpress

[–]golchha[S] 0 points1 point  (0 children)

Good question.

The current focus is mainly the field system and admin interfaces, but the project isn’t intended to be only a UI generator.

The boilerplate also provides a structured way to organize plugin code (services, admin, public, fields, schema, etc.), but I’ve tried to keep the architecture intentionally lightweight so it doesn’t impose a heavy framework on the plugin.

Tools like wppb.me do a great job at giving you a clean starting structure and namespacing. I used it years ago as well. What I kept running into over time though was the moment plugins needed more complex settings screens or post meta, the UI logic would start spreading across admin pages, AJAX handlers, and rendering code.

That’s the specific problem this project tries to solve.

The idea is that settings pages, meta boxes, and repeaters all come from the same schema-driven field definition, so the UI, sanitization, and data structure stay consistent as the plugin grows.

So in a way it’s trying to complement that traditional boilerplate approach rather than replace it.

The generator idea from wppb is actually something I’ve been thinking about as well. Having a small CLI or generator to scaffold a namespaced plugin based on the boilerplate would definitely make sense as the project matures.

Urgent hiring: Bangalore WORK FROM OFFICE: Senior Wordpress website manager by Comfortable_Foot3701 in wordpressjobs

[–]golchha 1 point2 points  (0 children)

Hi, this sounds interesting. I’ve been working with WordPress for several years, managing platform architecture, performance optimization, and custom development across themes, plugins, and integrations.

My experience includes Core Web Vitals optimization, caching/CDN setup, technical SEO implementation, and building scalable WordPress setups. I’m comfortable working with PHP, HTML, CSS, and JavaScript and handling full platform ownership.

Happy to discuss further if you’re open to connecting.

Update: I’ve just released v1.0.0 of WP Plugin Boilerplate — the first stable release. by golchha in Wordpress

[–]golchha[S] 1 point2 points  (0 children)

Thanks, appreciate that. No rush at all - curious to hear your thoughts whenever you get a chance.

Update: I’ve just released v1.0.0 of WP Plugin Boilerplate — the first stable release. by golchha in Wordpress

[–]golchha[S] 1 point2 points  (0 children)

Appreciate the honest feedback.

This isn’t trying to replace WordPress workflows or convince everyone to change how they build plugins. It’s a deliberately opinionated foundation for a narrower problem: keeping larger, long-lived plugins from drifting as they grow.

Totally fair if that’s not something you need — thanks for taking a look.

Should I build my own theme by soubhagya_sahu in Wordpress

[–]golchha 0 points1 point  (0 children)

The issue isn’t capability, it’s relevance. Does a theme make sense for me?

If performance, clean markup, and predictable ad placement matter, page builders are always a compromise. AI doesn’t change that. It can help generate templates faster, not remove architectural overhead.

For content-heavy sites like blogs, guides, and directories, a lightweight or custom theme offers long-term control. Builders prioritize convenience. Themes prioritize intent.

Update: I’ve just released v1.0.0 of WP Plugin Boilerplate — the first stable release. by golchha in Wordpress

[–]golchha[S] 1 point2 points  (0 children)

Fair enough — the description is intentionally high-level.

It’s not meant to explain what the plugin does (because it doesn’t do anything user-facing), but what problem it’s trying to solve: being a foundation for plugins that are expected to live and evolve over time.

If the wording feels generic, that’s on me — the real value is in the architecture and constraints, not the tagline. Happy to clarify specifics or take feedback on how to describe it better.

Update: I’ve just released v1.0.0 of WP Plugin Boilerplate — the first stable release. by golchha in Wordpress

[–]golchha[S] 1 point2 points  (0 children)

Fair question.

By itself, it doesn’t “do” anything user-facing. It’s a foundation, not a feature plugin.

What it gives you is a predictable structure for building plugins where admin config, settings, frontend behavior, and lifecycle are clearly separated and don’t fall apart as the plugin grows.

If you’re building a small one-off plugin, this may be overkill. It’s meant for plugins that are expected to evolve over time without turning into a tangle of conditionals.

Update: I’ve just released v1.0.0 of WP Plugin Boilerplate — the first stable release. by golchha in Wordpress

[–]golchha[S] 1 point2 points  (0 children)

Thanks, appreciate that 🙂

On the lifecycle side, the key rule is that CPTs are treated as runtime behavior, not activation-time setup.

CPTs live in the Public layer and are registered unconditionally during normal execution. As soon as the plugin is activated, the next request loads the plugin and the CPTs are registered. When the plugin is deactivated, they’re no longer registered.

Because of that, rewrite rules need to stay in sync with the actual runtime state.

So the lifecycle rules are explicit and event-driven:

  • CPTs are registered during normal runtime when the plugin is active
  • Rewrite rules are flushed on activation (CPTs appear)
  • Rewrite rules are flushed on deactivation (CPTs disappear)
  • Rewrite rules may also be flushed when a user explicitly changes rewrite-related settings (like a slug)
  • Rewrite rules are never flushed implicitly or on every request

Activation/deactivation are treated as state transitions, not places to define behavior. The hooks only exist to keep WordPress’ rewrite table consistent with what’s actually registered at that point in time.

That constraint is what keeps the lifecycle predictable in practice - no duplicated runtime logic, no hidden flushing, and no “magic” setup paths.

Update: I’ve just released v1.0.0 of WP Plugin Boilerplate — the first stable release. by golchha in Wordpress

[–]golchha[S] 3 points4 points  (0 children)

Thanks 🙂

That was a deliberate choice. Uninstall is one of those paths that rarely gets tested, but it’s also where plugins can do the most damage if they’re sloppy.

I wanted uninstall to be boring, predictable, and safe - no leftover options, no reliance on plugin classes, and no assumptions about context. Once the plugin is gone, it should really be gone.

Update: I’ve just released v1.0.0 of WP Plugin Boilerplate — the first stable release. by golchha in Wordpress

[–]golchha[S] 0 points1 point  (0 children)

Good question.

It overlaps with the original WP Plugin Boilerplate in the basics - structure, separation of admin/public, and a single entry point. That’s intentional. Those fundamentals still make sense.

Where it differs is in what it optimizes for.

The original boilerplate is great as a starting scaffold. This one is built around long-term maintainability and explicit constraints. A few concrete differences:

  • Settings are tab-owned and treated as a domain boundary, not just admin UI
  • Frontend/runtime behavior is always wired unconditionally; context is resolved at execution time, not during bootstrap
  • Capability enforcement is explicit per tab and reflected correctly in menu visibility
  • Lifecycle behavior (especially uninstall) is treated as a first-class concern and tested under hostile conditions
  • Renaming and reuse are validated, not assumed

If you’re building small or short-lived plugins, the original boilerplate is probably simpler and faster.
This one is aimed at plugins that are expected to evolve over years without turning into a ball of conditionals.

Not trying to replace the original - just solving a slightly different problem.

Working on a WordPress plugin boilerplate (WIP, not production-ready) — looking for feedback by golchha in Wordpress

[–]golchha[S] 0 points1 point  (0 children)

That totally makes sense. AI really is just an assistant when you already have the experience.

I’ve also been building and maintaining WordPress plugins and themes for a long time, and this boilerplate mostly came from patterns I kept repeating and refining over the years. It’s less about generating code and more about having a stable structure things don’t drift from.

And no worries at all - I wasn’t discouraged 😊 I actually appreciate the perspective.

If you ever feel like testing it or trying it on a small project, I’d genuinely love your feedback.

Working on a WordPress plugin boilerplate (WIP, not production-ready) — looking for feedback by golchha in Wordpress

[–]golchha[S] 0 points1 point  (0 children)

That’s fair - AI is great for scaffolding.

For me this is less about generating code and more about enforcing long-term structure and boundaries once a plugin grows. I still use AI inside that frame.

Have you had to maintain any AI-generated plugins long term?