I was rebuilding the homepage of a client site on a custom WordPress theme. The hero was full-screen, min-height: 100vh, with a video drifting slowly behind the headline. On localhost everything looked clean. Then I cloned the site to staging with the WP Staging plugin, opened the URL, and there was a line. A 1px line, perfectly straight, running edge to edge across the viewport about 70 percent of the way down. Faint, a gold and tan tint. And the unsettling part: it cut straight through the subject in the hero video. No natural video has a horizon that level and that flat.
What made it worse: the line only showed up on staging. On localhost it was clean, admin bar or not. Same code, cloned database, yet one render was clean and the other had a phantom line in the exact same spot on every reload.
A string of dead ends
Because the color was gold and tan and only 1px thin, my first guess was obvious: a border. I hunted every border-top inside the hero and killed them one by one. The line stayed. I suspected a layout push from the WP admin bar, since its height shifts content down. I disabled it, the line stayed. I chased .hp-hero::before, a dark vignette overlay on the video, in case its gradient had a hard edge. Not it.
Then I turned on the video itself. It had a mask-image for a fade at the bottom, so maybe the mask edge rendered as a line. I removed it, the line stayed. It also had a transform: scale(1.18) to crop the framing, so I zeroed that. The line stayed. I even chased the usual body.admin-bar height compensation WordPress applies. All nothing.
Ruling out cache and CDN first
Since the bug lived only on staging, the next suspect was CSS mutated in transit: a minifier, cache, or CDN rewriting the stylesheet before it reached the browser. This site ran LiteSpeed and Cloudflare, plenty of layers that could inject something. Rather than guess, I wrote a small read-only debug script to compare what was served against what was on disk:
$served = md5( wp_remote_retrieve_body( wp_remote_get( $css_url ) ) );
$disk = md5( file_get_contents( $css_path ) );
error_log( "[hero-debug] served={$served} disk={$disk}" );The MD5s matched. The CSS reaching the browser was identical to what was on disk, so no minifier or CDN was inserting a line. To be thorough I widened the script: audit every inline <style> tag in the served HTML, scan LiteSpeed options like css_min, css_comb, and css_inline, then check Cloudflare fingerprints like cf-cache-status and the Rocket Loader data-cfasync attribute. All clean. The line was not a build artifact. It was deterministic, born from CSS I had written myself.
The root cause
Once cache and CDN were off the suspect list, I reread the stylesheet with fresh eyes, and there was the culprit. Three decorative rules drew a thin dashed stitch line at the top of several sections below the hero:
.hp-story::before,
.hp-coll::before,
.hp-stores::before {
content: "";
position: absolute;
top: 0;
left: 0;
right: 0;
height: 1px;
background: repeating-linear-gradient(
90deg,
var(--hp-mist) 0,
var(--hp-mist) 6px,
transparent 6px,
transparent 12px
);
}
/* --hp-mist: #CEC3B4; */The value of --hp-mist was #CEC3B4, exactly the gold and tan tint I was seeing. The line was the top edge of the first section after the hero. On localhost, the 100vh hero ended right at the fold, so the next section stitch line sat just below the fold and was never visible.
The second half was the shifter. WP Staging injects an orange status banner on every staging clone: an inline <style id="wpstg-admin-bar"> block with #wpadminbar { background: #ff8d00 !important }. That banner pushes all content down by roughly 32 to 40px. The hero stays 100vh in document coordinates, but that shift was enough to lift the section boundary line, previously flush with the fold, to about 95 percent of the visible viewport. The result: a line that should have hidden below the hero now appeared to run inside it. Localhost had no such banner, so the line stayed below the fold and out of sight.
The fix
The three ::before rules were purely decorative, a subtle stitch between sections, not structural elements holding the layout together. So the fix was simple: delete all three from style.css.
/* Removed: decorative stitch lines leaking into the hero on staging.
.hp-story::before,
.hp-coll::before,
.hp-stores::before { ... }
*/After removing them, I reloaded staging: clean hero, no line, at every viewport size. Localhost stayed clean too. The tempting first move was to compensate for the banner shift by adding padding to the hero, but that only patches the symptom at one screen height and breaks on another. Dropping the unnecessary decorative line was far cleaner than chasing the banner shift around.
The takeaway
- If a visual bug shows up only on staging and never local, suspect what the staging environment injects, not your code. WP Staging drops an orange banner that shifts the layout by tens of pixels.
- Rule out CSS mutation from cache, minifier, and CDN first. Compare the MD5 of served versus on-disk CSS before you blame your own stylesheet.
- A tinted 1px line is often a
repeating-linear-gradientor aborder, not part of an image or video. Match the line color to a custom property in your CSS;#CEC3B4pointed straight at the culprit. - Decorative elements sitting exactly on the
100vhboundary are fragile: any small shift can pull them into or out of the fold. Do not rest an aesthetic on the fold position. - If a rule is only decoration and not load-bearing, deleting it beats patching the shift that exposed it.