Why WordPress Settings Matter
Bricks is a WordPress theme. That single fact decides where the real setup happens: half in the Bricks editor, half in the WordPress admin screens you already know. People install Bricks, open the builder, and start dragging elements — then wonder why image templates look blurry, why the blog index ignores their design, or why a permalink change broke every internal link.
None of those problems come from Bricks. They come from settings in the WordPress backend that Bricks reads at build time. This guide walks through nine decisions that change how Bricks behaves. Each one takes under a minute. Do them once, on every new site, before you build anything.
Permalinks
Path: Settings → Permalinks → “Post name”.
The permalink structure sets the URL pattern for every post, page, and custom post type. Post name produces URLs like /your-page-slug — short, readable, and the structure SEO tools and visitors expect.
Why it matters to Bricks: dynamic links. Query loops, “read more” buttons, and archive links are generated from this structure at render time. If you change it later, WordPress writes new URLs and every old URL starts 301-redirecting — workable, but risky: cached pages, saved templates, and external links can point at the old pattern for weeks. Set Post name on day one and forget it. Skip category or date prefixes; they add noise to the URL and dilute keyword relevance.
Reading & Search Visibility
Path: Settings → Reading.
Two options here affect you directly. First, “Discourage search engines from indexing this site” should stay unchecked unless you’re staging. It adds a noindex meta tag to every page. Developers often tick it during the build and forget to untick it at launch — a site-wide noindex on a live Bricks site that took weeks to build.
Second, decide between “Your latest posts” and “A static page”. With a static front page, you point the homepage at a page built entirely in Bricks — full control of the hero, sections, and layout. “Your latest posts” hands the front page to the built-in blog index template, which ignores your Bricks homepage design. Most Bricks sites use a static page and run the blog from a separate page with a query loop.
Discussion & Comments
Path: Settings → Discussion.
A default WordPress install allows comments on every new post. For most Bricks sites — B2B pages, portfolios, marketing sites — comments add moderation work, spam traffic, and database writes without a payoff.
If you don’t need comments, uncheck “Allow people to submit comments on new posts” under Default post settings. New content then ships with comments closed. Also disable pingbacks and trackbacks; they are a spam vector with no real benefit. If you do want engagement, leave comments on but enable moderation and an anti-spam plugin such as Akismet. Bricks renders a comment area only where you add the comments element, so closing comments never breaks your layout.
Media Settings
Path: Settings → Media.
WordPress generates thumbnail, medium, and large sizes when you upload an image. Bricks’ image element exposes an image size selector that reads these registered sizes directly. If you build a template with “Medium” and the default medium size is 300 px wide, your design shows a soft, upscaled image.
Set practical defaults: large at 1920 px (covers most full-width sections), medium around 768 px, and a thumbnail small enough to stay fast. Also consider unticking “Organize my uploads into month- and year-based folders” if you prefer a flat media library. Either way, pick one convention and stay consistent, so template image sizes behave predictably across the whole site.
Permissions & Users
Path: Users → Add New / Edit Profile.
WordPress roles decide who can open the Bricks editor. By default, any user who can edit pages — editors, for example — can use Bricks to edit the content they have access to. That’s convenient for clients who should restyle pages without touching the rest of the site.
What you usually want to lock down is Bricks itself: Theme Styles, template management, and global settings should stay with administrators. If a client needs to edit pages but not site-wide settings, give them the Editor role, not Administrator. For tighter control, a user-role plugin can expose granular capabilities per user. The rule of thumb: assign the minimum role that lets someone do their job, and keep at least one Administrator account with a strong password and two-factor authentication.
Site Health & PHP Version
Path: Tools → Site Health → Status.
Bricks is lightweight, but it runs on PHP and WordPress. Site Health reports your PHP version, memory limit, and failing components in one screen. Check it on every new site before you build.
Bricks requires PHP 7.4 or newer; 8.1+ is the practical target for speed and security. If your host runs an older version, ask them to upgrade — older PHP slows Bricks’ template rendering, and unpatched versions are a security risk. For local development, set WP_DEBUG to true in wp-config.php so PHP notices surface while you build. On production, leave it false; debug output on a live site leaks file paths and slows pages.
Updates Strategy
Path: Dashboard → Updates.
WordPress auto-updates can be set per component: security and minor releases, major versions, plugins, and themes. A sane policy for a Bricks site: security updates automatic, major WordPress versions manual — wait a week or two and watch for compatibility reports before upgrading.
Bricks itself releases updates frequently. Don’t install a new Bricks version the hour it drops. Check the changelog, wait one to two weeks, and watch the community (the official Facebook group and support forum) for breakage reports. Take a backup before any theme update. Bricks stores templates in the database, so an update that touches template structure deserves a rollback path.
The Checklist Recap
Nine decisions, one pass:
- Permalinks → Post name, set once
- Reading → search engines allowed, static front page
- Discussion → comments and pingbacks off by default
- Media → large at 1920 px, medium at 768 px
- Users → Editor for clients, Administrator for owners
- Site Health → PHP 8.1+, no critical issues
- Debug →
WP_DEBUGon locally, off in production - Updates → automatic for security, manual and patient for majors
For the full 15-point setup, see the Bricks Setup Checklist. If terms like query loop or theme styles still sound fuzzy, the Bricks Terminology Glossary covers them.
