The Layer Model: Presentation vs Functionality
Think of a WordPress site in two layers. The theme is the presentation layer: template files decide how posts, pages and archives render, and stylesheets set layout and colour. Plugins are the functionality layer — modules that add or change what the site can do. WordPress keeps its core small and lets these two layers extend it, which is why the boundary matters.
| Factor | Theme | Plugin |
|---|---|---|
| Role | Templates, styles, layout | Capabilities and features |
| Examples | Block themes, classics | SEO, security, caching, forms |
| Survives theme switch | — | Yes — plugins keep working |
| Dies on switch | Its functions.php features | Only its own deactivation |
| Content impact | Display only | Can store data in database |
| Best practice | Lean, presentation only | Carry all real features |
That fourth row is the horror story: features coded inside a theme vanish the moment it deactivates. Keep functionality in plugins — the WordPress web design service builds sites on exactly this separation, and best free WordPress themes lists lean starting points.
What a Theme Should (and Shouldn't) Do
A theme owns everything a visitor sees: template files, header and footer, menus, colours, typography. Only one theme is active at a time — switching it replaces the entire presentation layer in one click, with no code changes needed when the theme is doing its proper job.
What a theme should not carry is features. Contact forms, SEO controls, security, custom post types — anything the business needs to work — belong in a plugin, because they have to survive the next redesign. A theme's functions.php may hold small presentation helpers, but nothing the site depends on.
What Plugins Are For
Plugins add or change behaviour: SEO metadata, firewalls, caching, checkout, forms, backups. Several run at once — the limits are practical, not technical — and each registers through hooks, so it modifies core behaviour without touching template files.
The deciding property is persistence. A plugin's features and data live independently of the theme: switch the theme and a form plugin still collects submissions, an SEO plugin still prints metadata. Choose plugins on maintenance activity and support, not feature count.
Why Features Die With Theme Switches
When a theme deactivates, WordPress stops loading it — functions.php included. Anything registered there stops existing: custom post types, shortcodes, menu locations. The switch is one click; the loss is silent, with no warning screen naming what just disappeared.
The classic case is a portfolio coded into the theme. Change the theme six months later and the portfolio is gone — the data usually survives in the database, but nothing renders it. Rebuilding means re-registering the feature, which is exactly why features belong in plugins from day one.
functions.php: The Gray Zone
functions.php is the theme's code file, and it is where the boundary blurs. It legitimately holds presentation support: enqueueing styles and scripts, registering menus and widget areas, small template tweaks that shape how content displays.
It should not hold features. Functionality coded there creates a hidden dependency on one theme file — a dependency nobody sees until the theme changes. If code must live outside a plugin, put it in a child theme or a site-specific snippet plugin, never the parent theme's functions.php, where an update can erase it.
Shortcodes and Content That Outlives Themes
Where a shortcode is registered decides whether it survives a redesign. Plugin shortcodes keep working after a theme switch; theme shortcodes break, leaving literal [tag] text in every post that used them.
Content behaves the same way. Posts, pages and plugin data live in the database and outlast any theme; what dies is the theme's rendering of them. That is the safe pattern in one line: content and capability in plugins, appearance in the theme.
Planning a Site: Theme, Plugins, Custom Code
Architecture rules that prevent the classic rebuild-avoidable mess. Start with a lean, well-maintained theme matched to your design language — block themes for new builds — and resist multipurpose giants bundling features you will never use. Put every capability into plugins: SEO, security, forms, commerce — chosen for maintenance activity, not feature count.
Custom code goes in a site-specific plugin or a child theme, never the parent theme's functions.php, so it survives every future redesign. Shortcodes defined by plugins stay safe across switches; shortcodes defined by the theme break silently. Document the map — theme, plugin list, custom code — so the next developer inherits structure, not archaeology. The WordPress web design service team architects sites this way from day one.
Frequently Asked Questions
What is the difference between a WordPress theme and a plugin?
A theme controls how the site looks — templates, layout, colours — and only one is active at a time. Plugins control what the site does — forms, SEO, security, commerce — and several run together. Features in a theme vanish when it switches; features in plugins survive.
Can plugins change how my website looks?
They can — page builders and style plugins ship their own CSS and editor blocks. The convention still holds: a plugin may adjust presentation, but a theme's job is presentation and a plugin's job is function.
Why did my features vanish after switching themes?
They were registered inside the old theme, most often in its functions.php. Switching themes stops loading that file, so shortcodes, custom post types and menus it defined disappear. Move feature code into a plugin so it survives redesigns.
Should functionality be added in a theme or plugin?
In a plugin whenever the feature must survive a theme change — which is almost always. functions.php and child themes are for presentation support only; core capabilities belong in plugins.
What is functions.php used for?
Presentation support: loading stylesheets and scripts, registering menus and widget areas, small template tweaks. It is the wrong place for business features, because a theme update or switch can remove it silently.
How many plugins is too many?
There is no number — quality decides. A dozen well-maintained plugins from active developers beat three abandoned ones. Remove anything unused, and avoid two plugins that duplicate the same job.
Is WebJi® an Indian company?
Yes. WebJi® is headquartered in Jaipur, Rajasthan and has operated since 2005. Billing, support and governance all run from India.
Do you provide GST invoices?
Every purchase and renewal gets a GST invoice with our GSTIN, and hosting prices are quoted exclusive of 18% GST. Claim input credit as applicable.