Building a Drupal Site With Solo and No Code: What the Admin Covers, and Where Code Starts

"No coding needed" is true of the Solo theme for a specific and knowable set of things, and false for everything outside it — and the useful skill is knowing which side of that line your requirement falls on before you start. Site builders lose whole days discovering the boundary by trial and error. This page draws it explicitly, from the theme's shipped settings, so you can decide in ten minutes whether your design is a configuration job or a development job.

What the admin genuinely covers

These are all settings. Nobody writes anything.

That last row is the one people miss. Solo has two custom-CSS fields in its settings, and they behave differently on purpose: the injector writes an inline <style> element into the page head for quick global tweaks, while the dynamic field writes to a real stylesheet under your public files directory so browsers can cache it. Between them, a surprising amount of "we need a developer for this" turns out to be four lines in a textarea.

If you have not seen those fields, the CSS injector walkthrough shows both.

Where code starts, and it is not a grey area

You have crossed the line the moment you need any of these:

• Different markup. Changing what elements are output, not how they look. That is a Twig template override, and it needs a sub-theme.
• A new variable in a template. Anything the theme does not already pass to Twig requires a preprocess function.
• A layout the region system cannot express. Twenty-four regions is a lot, but they are fixed positions. An overlapping hero, a bento grid, a sticky element that follows a scroll position — those are CSS you write.
• Conditional behaviour. "This colour on news articles but not on events" is not a colour setting. It needs either the Solo Utilities module's rule system or code.
• Integration with a contributed module's markup. The moment a third-party module's output has to match your design, someone is writing selectors.
• Accessibility remediation. Solo ships semantic markup, skip links and keyboard menu handling, but no theme guarantees conformance. Meeting WCAG or Section 508 on a real site is testing and fixing work, and it is nobody's default.

The three signals that you have crossed it without noticing

You are fighting the same rule twice

Adding !important to a snippet in the CSS injector is the classic tell. It means something in the theme is legitimately winning, and the correct fix is a properly scoped rule in a sub-theme stylesheet rather than a bigger hammer in a settings field.

You are using the hidden region as a workaround

Parking blocks in the hidden region because there is no right place for them means the layout you want is not one the region system offers. That is a signal to reach for a template, not to keep shuffling blocks.

Your settings no longer fit in your head

Solo's settings form is large. When you cannot remember which of thirty areas you set a colour on, you have passed the point where configuration is cheaper than a small, version-controlled stylesheet that a colleague can read.

The honest cost comparison

Configuration is free of code but not free of time, and it is not version controlled in the way a stylesheet is — theme settings live in configuration, so they move between environments through config export, and a colour someone changed in production is a config drift problem, not a git diff. A sub-theme with fifty lines of CSS is often easier to maintain than the equivalent expressed as forty admin settings, precisely because you can read it in one screen and review it in a pull request.

That is the real trade, and it is why "no coding needed" is a feature rather than a philosophy. Use the admin until the admin costs more than the code, then stop.

Common questions

Can I start without a sub-theme and add one later?

Yes, but plan for it. Theme settings are stored per theme, so switching your default from Solo to a sub-theme starts you from defaults and you will re-enter your configuration. Cheapest sequence: create the sub-theme first, set it as default, then configure once.

Does the site slow down if I only use settings?

Not meaningfully. Colour choices become CSS custom properties on the region wrapper, and the two custom-CSS fields add either one inline block or one cached file. If you have a performance problem on a Solo site it is far more likely to be images, uncached pages or a heavy contributed module than the theme's configuration.

What can I do without code that most themes make you code?

Two things stand out: per-content-type column ratios, which usually means Layout Builder or a second theme elsewhere, and per-region colour with hover states, which usually means a stylesheet.

How do I know if my design is a configuration job before I commit?

Take the design, and for every element write "setting" or "code" next to it using the two lists above. If more than about a fifth say code, budget for a themer from the start rather than discovering it in week three.

Deciding, and getting help

Do that audit before you build. It takes half an hour and it is the difference between a site that comes in on time and one that stalls at ninety percent. If you are still choosing a base theme, the six checks to run on any free Drupal theme come first; if you already have Solo installed and want to start configuring, the setup order matters more than you would expect.

And if the audit says code, that is fine — it is what a Drupal themer does. Send the design over with your list and request a quote; a scoped front-end build against a theme that already handles the boring 80% is a much smaller job than most people expect.