WordPress has changed a lot since the Block Editor became the default editing experience. Developers can now build custom blocks, create interactive layouts, and give users more control over page content without requiring them to understand shortcodes or edit code.
This shift raises an important question: is classic WordPress plugin development becoming obsolete, or does it still have a place in modern websites?
After looking at how plugins work across different WordPress setups, the Block Editor has changed how developers build certain features, but traditional plugin development remains widely used.
How the Block Editor Changed WordPress Development
Before the Block Editor arrived, many WordPress plugins relied on shortcodes, widgets, custom fields, and settings pages to deliver functionality. Users often had to copy a shortcode, paste it into the editor, and preview the page to see the final result.
The Block Editor introduced a more visual approach. Instead of remembering shortcode syntax, users can insert blocks, adjust settings, and arrange content directly within the editing interface.
This change has made content creation easier for non-technical users. It has also encouraged developers to build features that integrate directly with the editing experience.
For example, a testimonial plugin can provide a dedicated block with controls for the layout, colors, image placement, and number of testimonials displayed. A user can configure these options without writing code or leaving the editor.
However, a better editing experience does not mean every plugin needs to be rebuilt around blocks.
What Classic WordPress Plugin Development Still Does Well
Classic plugin development includes more than shortcodes. It also involves PHP, WordPress hooks and filters, database queries, REST API integrations, scheduled tasks, permissions, and server-side rendering.
Many of these techniques remain essential in modern WordPress development.
Consider a membership plugin that manages subscriptions, checks user permissions, processes payments, and restricts access to premium content. Most of its important work happens behind the scenes. A block-based interface might help users display membership information, but the underlying business logic still depends on PHP, database operations, authentication, and WordPress APIs.
The same applies to booking systems, inventory tools, analytics integrations, and custom administration dashboards. These plugins need reliable server-side functionality regardless of which editor a website uses.
This is also why businesses sometimes turn to professional WordPress plugin customization services to extend existing functionality, resolve compatibility issues, or adapt a plugin to a specific workflow. Replacing the entire plugin architecture with blocks would rarely solve the underlying problem.
Classic development techniques remain useful wherever a plugin needs to process data, enforce rules, connect services, or perform tasks outside the content editor.
Where Block-Based Plugin Development Makes More Sense
Although classic development remains relevant, the Block Editor offers clear advantages for features that directly affect page content.
Blocks make it easier to create reusable, configurable components that users can place wherever they need them. They also provide a more predictable editing experience because users can see a closer representation of the final layout while working.
Block-based development is particularly useful for:
- Content layouts: Custom sections, cards, testimonials, pricing tables, and call-to-action areas.
- Reusable components: Design elements that editors can insert across multiple pages.
- Visual customization: Controls for spacing, alignment, colors, typography, and layout.
- Editor-friendly workflows: Features that content teams can manage without repeatedly switching between settings pages and the front end.
- Theme integration: Components that work naturally with modern block themes and site editing tools.
For example, a restaurant website might use a custom menu block that allows staff to update dishes, prices, and descriptions from the editor. The block provides the interface, while the plugin’s underlying code handles data validation, storage, and any additional business rules.
This separation makes the feature easier to use without requiring developers to abandon established WordPress development practices.
Does Every Classic Plugin Need to Be Rebuilt?
No. Rebuilding a working plugin solely to make it block-based can introduce unnecessary costs and risks.
Before changing an existing plugin, developers should identify the problem they are trying to solve. If users struggle with a shortcode because they cannot easily preview its output, adding a block interface may be worthwhile. If the plugin already performs a background task reliably, changing its architecture may offer little practical benefit.
A useful approach is to evaluate the plugin feature by feature.
- Keep the existing implementation when it works well: PHP functions, hooks, filters, scheduled tasks, and integrations can continue operating without a block interface.
- Add blocks where they improve the user experience: If a feature controls visible page content, a dedicated block may make it easier to configure and maintain.
- Modernize outdated components when necessary: Older plugins may need updates for current WordPress APIs, accessibility, security, performance, or compatibility with modern themes and plugins. These improvements matter more than adopting blocks to follow a trend.
- Test backward compatibility: Some websites rely on classic editor workflows, existing shortcodes, or older content structures. A major update should not unexpectedly break those sites.
The goal is not to choose between classic development and blocks. It is to use the right approach for each part of the plugin.
How Developers Can Modernize Existing Classic Plugins
Modernizing a plugin does not have to mean starting from scratch. A gradual process can preserve reliable functionality while introducing improvements where they provide real value.
1. Review the Existing Architecture
Start by examining the plugin’s PHP code, hooks, database interactions, dependencies, and user-facing features. Identify outdated functions, security concerns, and compatibility problems before changing the interface.
2. Separate Business Logic From Presentation
A well-structured plugin keeps its core functionality separate from the way content appears in the editor or on the front end. This makes it easier to introduce a block interface without duplicating important logic.
For example, a product display plugin can retain its existing product retrieval and validation functions while adding a block that lets users select products and adjust their presentation.
3. Introduce Blocks for the Features That Need Them
Choose features that would genuinely benefit from visual editing. Build a block for those features instead of converting every shortcode or settings page without a clear reason.
The block should provide understandable controls, sensible defaults, and clear validation. Its output should also remain consistent with the website’s theme and accessibility requirements.
4. Preserve Existing Shortcodes and Workflows
When possible, maintain support for existing shortcodes and saved content. Websites may contain hundreds of published pages that depend on the original implementation.
Backward compatibility reduces disruption for site owners and gives them time to adopt newer features at their own pace.
5. Test Security, Performance, and Compatibility
A plugin can look modern in the editor and still have serious technical problems. Test permission checks, input validation, data sanitization, database queries, REST API endpoints, and front-end performance.
Also check how the plugin behaves with different themes, caching systems, and other common plugins. A modernization effort should improve reliability, not just change the interface.
Classic Plugins and the Block Editor Can Work Together
One of the biggest misconceptions about modern WordPress development is that developers must choose either classic plugin architecture or block-based development.
In reality, the two approaches solve different problems.
A plugin can use PHP for core functionality, REST API endpoints to exchange data, and JavaScript to provide an interactive block interface. The Block Editor becomes the presentation and configuration layer, not a replacement for the entire plugin.
This hybrid approach is useful for WordPress plugins that need both complex backend behavior and a flexible editing experience.
Imagine an event management plugin. Its backend might manage event records, registrations, capacity limits, and email notifications. A block could allow an editor to display upcoming events on a landing page and choose between a grid or list layout.
The backend still handles the rules and data. The block gives content editors a simpler way to control what visitors see.
This structure also makes future improvements easier because developers can update the interface without rewriting the plugin’s core functionality.
What This Means for WordPress Developers
The Block Editor has changed the skills developers need, but it has not removed the need for traditional WordPress knowledge.
PHP, WordPress hooks, database design, security practices, and API integrations remain important. At the same time, developers working on modern plugins may need to understand JavaScript, React, block registration, editor components, and the WordPress data and component APIs.
The most useful skill is knowing when to apply each approach.
A developer who understands only classic plugin development may miss opportunities to create a better editing experience. A developer who focuses exclusively on blocks may struggle with complex backend requirements.
Understanding both makes it easier to build plugins that are practical for site owners, maintainable for developers, and compatible with different WordPress environments.
Final Thoughts
Traditional plugin development still handles essential tasks such as data processing, permissions, integrations, scheduled operations, and business logic. Block-based development improves how users create and manage content within the editor.
Instead of replacing one approach with the other, developers should combine them when it makes sense. Keep reliable backend functionality, introduce blocks where they improve the editing experience, and prioritize security, usability, performance, and compatibility.
The future of WordPress plugin development is not about abandoning classic techniques. It is about using established foundations to build better experiences for modern WordPress users.
Frequently Asked Questions
Is classic WordPress plugin development obsolete?
No. Classic development remains essential for backend logic, database operations, API integrations, permissions, scheduled tasks, and other functionality that does not depend on the content editor.
Do WordPress plugins need to support the Block Editor?
Not every plugin needs a block interface. Plugins that control visible page content may benefit from blocks, while backend-focused plugins can continue working without them.
Can classic WordPress plugins work with the Block Editor?
Yes. Classic plugins can continue using PHP, hooks, filters, and shortcodes while adding block-based interfaces for selected features. The implementation depends on the plugin’s architecture and requirements.
Should developers convert shortcodes into blocks?
They should consider converting shortcodes when a block would make the feature easier to insert, configure, or preview. If a shortcode already works well and meets users’ needs, conversion may not be necessary.
What skills are useful for modern WordPress plugin development?
PHP, WordPress APIs, database management, security, and debugging remain important. JavaScript, React, block development, and editor integration are also valuable for developers building modern editing experiences.
Top comments (2)
The “blocks vs. classic” framing is a false choice, and the hybrid model you describe is how most production plugins end up. PHP owns the rules and data, and the block is just the configuration layer on top.
The point about separating business logic from presentation is what makes that work in practice. When a plugin keeps its retrieval and validation in one place, adding a block later is mostly wiring. When the logic is tangled into shortcode callbacks, “modernizing” becomes a rewrite, and that’s where the risk comes from.
I’d add one thing on backward compatibility: keeping old shortcodes working is easy to underrate. Sites with hundreds of published pages can’t afford a plugin update that breaks them silently. A shortcode-to-block transform lets editors migrate at their own pace without forcing it.
Curious where you draw the line on dynamic blocks (server-side render) vs. static ones for plugin features. Do you default to
render_callbackso the PHP stays the source of truth?Thanks, glad the hybrid point came through. Your note on backward compatibility is a good addition. Shortcode-to-block transforms are underused, and they let site owners migrate page by page instead of all at once.
On your question: yes, I default to dynamic blocks whenever the output depends on data. Events, products, membership status and anything pulled from the database all fit that. With
render_callback(orrender.phpviablock.json), PHP stays the source of truth. The output updates without anyone re-saving posts, and you avoid block validation errors when the markup changes later.I keep static blocks for purely presentational content, like a pricing card layout or a CTA section, where the saved HTML is the content and nothing server-side needs to run.
Do you lean the same way, or have you hit cases where static blocks were the better call for data-driven features?