PART 1: LOGGING IN — THE CUSTOM URL SECURITY MODEL

Every WordPress site installed by Proscris Agency uses a customized, non-guessable login path instead of the WordPress default. The default WordPress login — /wp-admin and /wp-login.php — is publicly known, documented across millions of tutorials, and the first thing every automated attack bot and brute-force tool targets. The Proscris deployment model eliminates this attack surface before it can be exploited.

How to Log In — Step by Step

Why /system — The Security Architecture Explained

This is not cosmetic. Changing the login URL from the default to a custom path is one of the most effective, zero-performance-cost security measures available for a WordPress deployment. Here is why it works and what it accomplishes:

Security Through Obscurity — As a Layer, Not a Strategy: The custom login URL is one layer of a multi-layered security approach — not a complete solution on its own. It is combined with a suite of premium security plugins, strong password enforcement, role-based access controls, and code-level protections within Bricks Builder. The URL change eliminates the lowest-effort attacks. The plugin suite handles the rest. Together they create a deployment hardened well beyond a standard WordPress install.

The Full Proscris Login Security Stack

PART 2: THE WORDPRESS DASHBOARD — BACKEND OVERVIEW

Upon logging in at /system, you arrive at the WordPress Dashboard. This is the administrative backend from which every aspect of the website is managed — pages, media, settings, users, and plugins. For Proscris deployments, most day-to-day work happens in two specific areas: the Media Library and the Pages section. Everything else is infrastructure that has been pre-configured and generally should not require ongoing adjustment.

WORDPRESS DASHBOARD — NAVIGATION MAP

Left Sidebar Menu:
  ├── Dashboard           ← Home screen after login. Widgets, activity, quick links.
  ├── Posts               ← Blog posts (not used for main page content on Proscris deployments)
  ├── Media               ← ALL image, video, and document assets live here ← FREQUENTLY USED
  ├── Pages               ← ALL main site pages (home, landing pages, etc.) ← PRIMARY WORK AREA
  ├── Comments            ← Visitor comments (disabled on most deployments)
  ├── Bricks              ← Bricks Builder settings, templates, and global configuration
  │     ├── Templates     ← Global headers, footers, 404 pages
  │     └── Settings      ← Code execution, security, breakpoints
  ├── Appearance          ← Theme settings (Bricks is set as the active theme)
  ├── Plugins             ← Premium plugin suite installed here ← READ ONLY — do not modify
  ├── Users               ← User accounts and role management
  ├── Settings            ← General site settings, URL structure, reading settings
  └── [Plugin-specific menus appear here based on installed plugins]

Admin Toolbar (appears at top of every page when logged in):
  ├── Site name → Links to frontend (your live website)
  ├── "Visit Site" → View the live frontend
  ├── New → Quick-add post, page, or media
  └── [Plugin toolbar items — notifications, cache clear, security alerts]
    

The Admin Toolbar on the Frontend: When you are logged in and visit the live website, a black toolbar appears at the top of the page — this is the WordPress Admin Bar. It is only visible to logged-in users and does not appear to regular visitors. It slightly shifts the page layout visually. This is normal. To see the page as a regular visitor sees it, either log out or view the site in a private/incognito browser window.

PART 3: THE PREMIUM PLUGIN SUITE — Infrastructure You Do Not Touch

Every Proscris deployment includes a curated suite of premium plugins. These are not suggestions or optional add-ons — they are the core infrastructure of how the site functions, how it stays secure, how it performs at speed, and how it ranks in search engines. They are pre-installed and pre-configured at the time of deployment. As a site manager or content contributor, you should be aware they exist but you should not install, deactivate, or modify plugin settings without specific instruction from Proscris.

Plugin Count Is a Performance Variable: Every installed plugin adds execution overhead. The Proscris plugin suite is kept lean and purposeful — every plugin on the list has a specific, non-replaceable function. No redundant plugins. No "nice to have" plugins that duplicate functionality. This discipline is part of why Proscris sites load fast. Adding unofficial plugins without approval can degrade performance, create security vulnerabilities, and cause compatibility conflicts with Bricks Builder.

Plugin Categories in Every Proscris Deployment

PART 4: THE MEDIA LIBRARY — Asset Management

The Media Library (accessible from the left sidebar: Media → Library) is the centralized storage hub for all image, video, and document assets used on the website. Every image that appears on any page of the site — hero images, blog thumbnails, social media post previews, ad creative — is hosted here and accessed via a permanent URL tied to the domain.

Why Host Everything Here: When you upload an asset to the WordPress Media Library, it receives a permanent URL on your domain (e.g., nexumsystems.net/wp-content/uploads/2026/01/image-name.jpg). This URL never changes. It can be referenced in ad creative, social media posts, email campaigns, and third-party platforms without worrying about broken links. The site becomes the single source of truth for all brand assets — nothing is scattered across Google Drive, Dropbox, or device desktops.

Media Library Navigation

The Folder Organization System

The native WordPress Media Library has no folder support — every uploaded file lands in a flat, chronologically sorted pool. The premium media plugin installed on all Proscris deployments adds a full folder system to the library. All uploads should be organized into the correct folder immediately upon upload — not retroactively after a backlog accumulates.

RECOMMENDED MEDIA LIBRARY FOLDER STRUCTURE

Media Library/
  ├── Brand Assets/
  │     ├── Logos/          ← SVG, PNG versions of logo in all variants
  │     ├── Color Palette/  ← Reference swatches and brand color files
  │     └── Typography/     ← Font specimens and reference images
  ├── Photography/
  │     ├── Hero Images/    ← Full-width banner and header images
  │     ├── Team/           ← Headshots and team photos
  │     └── Stock/          ← Licensed stock images
  ├── Social Media/
  │     ├── Instagram/      ← Square and portrait formatted posts
  │     ├── Facebook/       ← Facebook post and cover image dimensions
  │     └── LinkedIn/       ← LinkedIn-specific formatted assets
  ├── Ad Creative/
  │     ├── Meta Ads/       ← Facebook and Instagram ad image sets
  │     └── Campaign Assets/← Campaign-specific image variations
  ├── Documents/            ← PDFs, downloadable resources
  └── Video/                ← MP4 files, thumbnail frames
    

File Naming Conventions — Before You Upload

File names are indexed by search engines and determine how easy it is to find assets within the library. Rename files before uploading — not after (WordPress generates the URL at upload time from the filename, and renaming after upload breaks any existing references).

PART 5: BRICKS BUILDER — THE PAGE CONSTRUCTION SYSTEM

Bricks Builder is the premium WordPress page builder used across all Proscris deployments. It is selected over alternatives (Elementor, Divi, WPBakery) for one decisive reason: it outputs exceptionally clean, minimal HTML — and it allows pages to be built entirely from raw HTML, CSS, and JavaScript without any of the visual builder's markup wrapping or inflating the code. This matters enormously for page speed, SEO technical compliance, and long-term code maintainability.

Launching Bricks for a Page

1. In the WordPress Dashboard, navigate to Pages in the left sidebar.
2. Hover over the page you want to edit. A row of options appears beneath the page title.
3. Click "Edit with Bricks" — not "Edit" (which opens the default WordPress block editor, which is not used on these deployments).
4. The Bricks Builder interface loads — a full-screen visual editor with the page preview in the center, element controls on the left panel, and the Structure Panel on the right.

The Bricks Interface — Three Panels

PART 6: THE RAW CODE PHILOSOPHY — Why Pages Are Built in HTML, CSS & JS

This is the defining architectural decision of the Proscris build methodology. Where most WordPress page builders encourage assembling pages from pre-styled visual widgets, Proscris builds pages using raw HTML, CSS, and JavaScript placed directly inside Bricks Builder's Code Element. This is a deliberate, principled choice with compounding advantages across performance, design precision, maintainability, and AI-assisted editing.

The Core Principle: A page built in raw HTML/CSS/JS inside a Code Element is — from the browser's perspective — identical to a hand-coded static website. It carries zero framework overhead, zero builder-injected markup, zero style conflicts from pre-baked component CSS, and zero dependency on a builder's update cycle for visual stability. The only thing WordPress and Bricks contribute is delivery infrastructure. The actual page content is pure, clean, portable code.

Raw Code vs. Visual Builder Components — The Performance Case

The Code Element — Three Fields

When a Code Element is added to a Bricks page, it presents three distinct input areas. Pages may use some or all of these fields depending on the complexity of the section being built.

PART 7: PAGE STRUCTURE — MONOLITHIC VS. MODULAR BUILDS

Across Proscris deployments you will encounter pages built in two structural styles. Both are valid approaches — understanding them is essential for knowing how to navigate, edit, and troubleshoot any given page.

THE PROSCRIS MODULAR PAGE BUILD STANDARD

STRUCTURE PANEL (top to bottom):
  [HEAD ELEMENT]
    CSS Field:
      :root { --primary: #3858e9; --accent: #c8a96e; ... }  ← CSS variables
      *, *::before, *::after { box-sizing: border-box; }    ← reset
      body { font-family: 'Inter', sans-serif; margin: 0; } ← base styles
      .is-admin-bar-showing { margin-top: 32px; }           ← admin bar offset
    HTML Field:
      <!-- SEO / head meta injected here -->               ← canonical, OG tags

  [HERO SECTION]
    HTML Field:   <section id="hero" class="hero">...</section>
    CSS Field:    .hero { ... } .hero__headline { ... }

  [FEATURES SECTION]
    HTML Field:   <section id="features" class="features">...</section>
    CSS Field:    .features { ... } .feature-card { ... }

  [PRICING SECTION]
    HTML Field:   <section id="pricing" class="pricing">...</section>
    CSS Field:    .pricing { ... } .plan { ... }

  [JAVASCRIPT — GLOBAL]
    JS Field only:
      // All interactive behavior: modal, jump nav, theme toggle, swipe
      // Runs after all DOM elements are rendered

LLM EDITING WORKFLOW (Modular):
  1. In the Structure Panel, select ALL elements (top to bottom)
  2. Copy all code → paste into the LLM as full page context
  3. Instruct the LLM: "Work with me only on the [PRICING] section.
     Provide back only the updated HTML and CSS for that section."
  4. Paste the returned code back into only that section's Code Element
  5. Sign the code (see Part 8) → Save
    

PART 8: CODE SIGNING — THE BRICKS SECURITY PROTOCOL

Code Signing is Bricks Builder's built-in security system for validating that executable code — PHP and JavaScript — has been deliberately reviewed and authorized by a trusted administrator before it runs on the live site. It is not optional. Unsigned code will display a red indicator in the builder and will not render or execute on the frontend.

Why This Exists — The Threat It Prevents: Bricks Builder allows JavaScript and PHP to execute directly on the server from within page elements. This is powerful — but it also means that if an attacker were to gain access to the site's database (through a plugin vulnerability, for example), they could inject malicious code into a Bricks element. Without Code Signing, that injected code would execute immediately the next time anyone loaded the page. With Code Signing, injected code remains unsigned — and unsigned code does not execute. The attacker's malicious code is inert until a user with full admin access manually reviews and signs it.

How Code Signing Works — The Technical Mechanism

When you sign a Code Element, Bricks generates a cryptographic hash of the code content using WordPress's wp_hash() function — which incorporates the site's unique secret keys (WordPress "salts") stored in wp-config.php. This hash is stored alongside the code in the database. Before any Code Element executes, Bricks re-hashes the current code and compares it against the stored signature. If they match — the code is authentic and executes. If they do not match — Bricks blocks execution. Any modification to the code after signing, however small, invalidates the signature and requires re-signing.

CODE SIGNING PROCESS — WHAT HAPPENS STEP BY STEP

INSIDE THE BRICKS BUILDER:

1. CODE IS ADDED OR MODIFIED
   └── A Code Element with new or changed code appears highlighted IN RED
         in the Structure Panel. A red fingerprint icon appears at the
         top of the Structure Panel indicating unsigned code exists.

2. REVIEW THE CODE
   └── Confirm the code is what you intend. This is the manual checkpoint
         that protects against injected malicious code. If you did not write
         this code, verify it before signing. Do not sign code you do not
         recognize or did not author.

3. SIGN THE CODE
   Option A: Click the "Sign Code" button directly above the code input field.
   Option B: Place cursor inside the code editor → use CMD+R (Mac) or CTRL+R (PC).
   Option C: Click the red fingerprint icon at the top of the Structure Panel
              to view and sign ALL unsigned elements on the page at once.

4. CONFIRMATION
   └── The element's red highlight turns to normal (no highlight).
         The Structure Panel's fingerprint icon disappears.
         A "Code signed" confirmation message appears briefly.

5. SAVE THE PAGE
   └── Click the Save button (top right of the Bricks Builder interface).
         Signed code is now stored in the database with its valid signature.
         The change is live on the frontend.

AFTER SITE MIGRATION OR SALT CHANGE:
   └── All existing signatures become invalid (salts have changed).
         Go to: WordPress Dashboard → Bricks → Settings → Custom Code
         → Code Signature → click "Regenerate Code Signatures."
         This must be done after any migration or server environment change.
    

Code Signing Reference — When to Sign

PART 9: GLOBAL TEMPLATES & DISPLAY CONDITIONS

Bricks Builder's Template system allows you to design a page component once — a header, footer, sidebar, or any section — and apply it automatically across multiple pages based on configurable display conditions. This is what enables a consistent site header to appear on every page without copying and pasting code into every individual page. Change the template once — the change propagates everywhere it applies.

Templates Are Bricks Elements, Not Pages: A Bricks Template is not a full page — it is a component that renders within a page. The Bricks rendering engine determines which templates apply to a given page, stacks them in order (header template → page content → footer template), and outputs the final combined HTML. The conditions system is what tells Bricks which templates to apply where.

Current Template Architecture — All Proscris Deployments

Display Conditions — The Rules System

Conditions are the logic layer that determines where a template appears. Each template can have one or multiple conditions — using AND/OR logic to build precise display rules.

TEMPLATE CONDITIONS — AVAILABLE RULE TYPES

BROAD CONDITIONS (entire site or post type):
  ├── Entire Website           ← Template appears on all pages, posts, and archives
  ├── Front Page               ← Only the homepage
  ├── All Posts                ← Every blog post, regardless of category
  ├── All Pages                ← Every WordPress page
  └── Post Type: [custom]      ← Any custom post type (services, testimonials, etc.)

GRANULAR CONDITIONS (specific pages or content):
  ├── Specific Page            ← Only page ID 42 (e.g., "About" page)
  ├── Specific Post            ← Only one specific blog post
  ├── Category: [name]         ← All posts in "Case Studies" category
  ├── Tag: [name]              ← All posts tagged "Featured"
  └── Author: [user]           ← Content by a specific author

ARCHIVE / DYNAMIC CONDITIONS:
  ├── Blog Archive             ← The paginated list of all posts
  ├── Search Results           ← What appears on search result pages
  ├── Date Archive             ← Monthly or yearly post archives
  └── WooCommerce pages        ← Shop, product, cart, checkout (if ecommerce)

CONDITION LOGIC:
  └── Templates are selected by Bricks in specificity order.
        A condition for "Specific Page: About" overrides
        "All Pages" — more specific conditions win.
        Multiple templates can apply simultaneously
        (a header template + a footer template + page content).

EXAMPLE — Landing Page Without Global Header:
  ├── Site Header template: Condition = "Entire Website" EXCEPT [page slug: lp-dental]
  └── Landing Page Header: Condition = "Specific Page: lp-dental"
        → The dental landing page gets its own dedicated header
          while every other page gets the site-wide header.
    

Managing Templates

1. In the WordPress Dashboard, navigate to Bricks → Templates in the left sidebar.
2. Click on any template name to open it in the Bricks Builder editor — it edits exactly like a regular page.
3. To view or modify display conditions, click the Template Settings button (gear icon) within the Bricks Builder while editing the template.
4. Add, remove, or adjust conditions. Conditions take effect immediately when the template is saved — no page-level changes required.

PART 10: RESPONSIVE BREAKPOINTS — DESIGNING FOR ALL DEVICES

Every page built in Bricks can be previewed and adjusted at four device breakpoints directly within the builder — without leaving the editor or needing a separate mobile testing device. This is a non-negotiable step in the Proscris workflow before any page goes live. The majority of website traffic arrives on mobile devices, and a page that looks excellent on desktop but breaks at 375px wide is a broken page.

Mobile-First Reality: Across most Proscris client demographics, 55–70% of website visitors arrive on a mobile device. A landing page optimized exclusively for desktop is optimized for the minority of traffic. Every page must be verified functional and visually correct at portrait phone width before being marked complete.

The Four Breakpoints

Breakpoint CSS Cascade — How Changes Propagate

Practical Rule: Design desktop first, then progressively override for smaller screens. Do not make desktop changes at the tablet breakpoint — this is the most common mistake and produces unexpected results where a desktop fix accidentally breaks tablet layout. Always confirm which breakpoint you are in before making any CSS or layout change by checking the active icon in the top toolbar of the Bricks editor.

PART 11: INTERACTIVE UI PATTERNS — THE PROSCRIS DESIGN STANDARD

Every page built under the Proscris methodology implements a consistent set of interactive interface patterns. These are not decorative choices — they are functional design decisions based on how users navigate long-form content on mobile devices, how to reduce friction in the conversion path, and how to communicate value to a non-technical audience efficiently. Each pattern is coded directly into the page's JavaScript and CSS, not dependent on a plugin or third-party widget.

PART 12: THE LLM-ASSISTED EDITING WORKFLOW

Because all pages are built in raw HTML, CSS, and JavaScript, AI language models (GPT-4, Claude, Gemini) can be used to write, edit, debug, and refactor page code with high accuracy. This is one of the most significant compounding advantages of the raw code methodology — it turns every edit into a human + AI collaboration that dramatically reduces the time to produce high-quality, functional page sections.

THE PROSCRIS LLM EDITING WORKFLOW — STEP BY STEP

STEP 1: GATHER FULL CONTEXT
  ├── Open the page in Bricks Builder
  ├── In the Structure Panel, select all Code Elements (top to bottom)
  ├── Copy the complete code of all sections
  └── Paste into the LLM prompt as the "full page context"

STEP 2: PROVIDE CONTEXT INSTRUCTION
  "Below is the full code for [page name]. I am sharing this so you
   have complete context of the page's CSS variables, class naming
   conventions, and JavaScript architecture. Do NOT rewrite anything
   yet. Confirm you have read and understood the page structure."

STEP 3: SCOPE THE EDIT REQUEST
  "Working only on the [PRICING SECTION], please:
   - Update the pricing tier labels from X to Y
   - Add a third column for an 'Enterprise' plan
   - Ensure the new column matches the existing card styling
   Return ONLY the updated HTML and CSS for the Pricing section.
   Do not return any other sections."

STEP 4: REVIEW THE RETURNED CODE
  ├── Read the returned code before pasting
  ├── Verify it uses the correct CSS class naming from your page
  ├── Verify it uses the CSS variables defined in your :root
  └── Verify no external dependencies were introduced without intent

STEP 5: PASTE AND SIGN
  ├── Open the target Code Element in Bricks Builder
  ├── Replace the existing code with the returned code
  ├── Sign the code (CMD+R or click Sign Code button)
  └── Save the page → preview on frontend to confirm

STEP 6: TEST ALL BREAKPOINTS
  ├── Desktop → Tablet → Mobile Landscape → Mobile Portrait
  ├── Verify the new section renders correctly at each size
  └── Test any interactive elements added (new CTAs, modals, etc.)
    

Why This Works So Well: Large language models are trained on enormous volumes of HTML, CSS, and JavaScript. They understand semantic markup, CSS specificity, Flexbox, Grid, responsive media queries, and vanilla JavaScript patterns at an expert level. When you provide clean, well-structured raw code as context, the model can reason about it accurately — returning code that integrates correctly with the existing page architecture. This is categorically different from trying to use an AI to work with a visual builder's proprietary format or a framework's abstraction layer.

PART 13: MASTER CHECKLIST — SITE MANAGEMENT OPERATIONS

Logging In

• ☐ Navigate to yourdomain.com/system — not /wp-admin or /wp-login.php
• ☐ Enter username and password → click Log In
• ☐ Verify you land on the WordPress Dashboard (not a 404 or error page)

Uploading Media Assets

• ☐ Rename the file using lowercase, hyphens, descriptive keywords before uploading
• ☐ Navigate to Media → Library → select the correct folder from the left panel
• ☐ Upload the file — confirm it lands in the correct folder
• ☐ Click the uploaded file → copy the File URL for use in ads, emails, or social posts

Editing a Page

• ☐ Navigate to Pages → hover the page name → click "Edit with Bricks"
• ☐ Identify whether the page is monolithic (one element) or modular (multiple elements) using the Structure Panel
• ☐ For modular pages: select the specific section element to edit — do not edit other sections
• ☐ Make the required change in the appropriate field (HTML, CSS, or JS)
• ☐ Sign the code: click Sign Code button or use CMD+R / CTRL+R
• ☐ Confirm the red highlight on the element clears and the fingerprint icon disappears
• ☐ Click Save (top right)
• ☐ Clear site cache if caching plugin is active (admin toolbar or plugin settings)
• ☐ Preview the frontend — verify the change is live and correct

Responsive Testing — Before Any Page Goes Live

• ☐ Switch to Tablet breakpoint in Bricks toolbar → verify layout and readability
• ☐ Switch to Mobile Landscape → verify no horizontal overflow
• ☐ Switch to Mobile Portrait → verify single-column layout, tap targets, text size
• ☐ Test swipe navigation on mobile portrait → verify it advances to correct sections
• ☐ Test jump navigation → verify smooth scroll to all anchors works
• ☐ Test lead capture modal on mobile → verify it fits viewport, form submits correctly

Adding a New Page

• ☐ Pages → Add New → give the page a clear title and slug (URL path)
• ☐ Under "Page Attributes" or Bricks settings, confirm Bricks is set as the page template
• ☐ Click "Edit with Bricks" to open the builder
• ☐ Begin with a HEAD element containing the page's CSS variables and SEO meta
• ☐ Build sections as individual Code Elements (modular structure)
• ☐ Sign all Code Elements before saving
• ☐ Fill in SEO plugin fields (title, description, canonical) before publishing
• ☐ Test all four breakpoints before setting page status to Published

Managing Templates

• ☐ To edit the sitewide header or footer: Bricks → Templates → find and edit the relevant template
• ☐ Sign any code changes in the template → save
• ☐ Verify the change appears correctly across multiple different page types (home, interior page, landing page)
• ☐ For a page that needs a different header: edit that page's template condition or add a page-specific exception condition to the global header template

INTERESTING FINDINGS

• 🔴 The /wp-admin Attack Rate Is Staggering — And Almost Nobody Defends Against It Properly: Research and real-world logging from WPMU DEV's Defender plugin shows that average WordPress sites with default login URLs receive approximately 24 malicious login attempts per day — one every 60 minutes — concentrated in sudden bursts of hundreds to thousands of attempts over short periods. The overwhelming majority of these attacks are automated bots using pre-compiled dictionaries of username/password combinations against the known path. Changing the login URL to a non-guessable slug like /system reduces successful bot attempts to effectively zero — not because the password is harder to guess, but because the bots cannot find the door to knock on. This is one of the highest-ROI security measures available per minute of implementation time.
• 🔐 Bricks Code Signing Uses WordPress Salts — Which Means Signatures Are Cryptographically Tied to the Specific Installation: The code signing mechanism uses WordPress's wp_hash() function, which incorporates the site's unique secret keys (AUTH_KEY, SECURE_AUTH_KEY, etc.) stored in wp-config.php. This means a signed Code Element's signature is literally unique to one WordPress installation. The same code pasted into a different site will appear unsigned — because the site's salts are different. This is by design and is what makes the security guarantee meaningful: database-level code injection cannot be "signed" by the attacker unless they also have access to the server's wp-config.php file. Two separate compromises required. For Bricks 1.11.1 and above, production environments can lock signature generation entirely using a PHP constant, making it impossible for any new code to be signed — even by admins — until the lock is removed.
• 🏗️ The "Div Soup" Problem of Visual Page Builders Is Not Cosmetic — It Has Measurable Performance Impact: Independent analysis of popular WordPress page builders found that a simple hero section built in Elementor generates 8–15 wrapping div elements around each content piece before the actual HTML content begins. This inflated DOM (Document Object Model) has three direct consequences: (1) browsers must parse and render more nodes per page load, increasing time-to-interactive; (2) Google's crawlers must process more markup per piece of meaningful content, diluting content signal density; and (3) the builder's own CSS framework (~200–400KB) loads on every page regardless of which elements are used. A comparable section built with a single raw Code Element in Bricks outputs exactly the HTML written — no wrappers, no framework CSS, no performance penalty.
• 📱 Horizontal Swipe Navigation Is a Documented Response to Mobile Attention Patterns: The swipe-to-section pattern used in Proscris landing pages is a direct design response to research showing that mobile users increasingly dislike infinite vertical scrolling — particularly on content-heavy landing pages. Swipe-to-section (also called "full-page scroll" or "section snap") presents one content unit at full viewport height at a time, eliminating the visual overwhelm of a long scrolling page. Combined with the jump navigation sidebar, it gives users two navigation modes simultaneously: passive (swipe through in order) and active (jump directly to the section they care about). This design pattern originated in presentation software (PowerPoint, Keynote, PDF documents) and maps to how non-technical audiences already consume structured information.
• 🤖 Raw HTML/CSS/JS Is the Native Language of Every AI Code Model — Making LLM-Assisted Editing Dramatically More Reliable: Large language models (GPT-4, Claude, Gemini) are trained on the open web — which is composed almost entirely of HTML, CSS, and JavaScript. Their understanding of these languages is deep, tested, and highly accurate. By contrast, the proprietary data formats of visual page builders (Elementor's JSON element trees, Divi's shortcode format, WPBakery's bracket syntax) are niche formats with minimal training data. When you provide a raw HTML/CSS/JS Code Element to an LLM for editing, you are working in the language the model knows best. The result is significantly more accurate code output with fewer hallucinations, incorrect property values, or structurally broken HTML than when asking an AI to reason about a visual builder's abstraction layer.

Sources

• WPMU DEV — How to Easily Hide Your WordPress Login Page From Hackers
• WordPress.org — WPS Hide Login Plugin
• WPMarmite — WPS Hide Login: All You Need to Know
• BigScoots — Harden WordPress Login Security Without Performance Loss
• Hide My WP Ghost — Brute Force Protection Documentation
• Bricks Academy — Code Signatures (Official Documentation)
• Bricks Academy — Custom Code in Bricks (Official Documentation)
• Bricks Builder — Version 1.9.7 Changelog: Code Execution, Review & Signatures
• Bricks Builder — Official Product Page
• Bricks Community Forum — WPS Hide Login with Bricks Builder Custom Auth Pages
• WagePirate — Bricks Builder Review: Code Output and Performance Analysis
• FatLab Web Support — The Developer's Page Builder That's Changing the Game
• GlobalSpex — Essential WordPress Plugins for Business Sites (2025 Guide)
• SEOJuice — Essential WordPress Plugins (2026): The Minimum Viable Stack
• Patchstack — Critical RCE Patched in Bricks Builder Theme (CVE-2024-25600 Context)
• Snicco — Unauthenticated RCE in Bricks 1.9.6 (Why Code Signing Was Introduced)