Do you ask for passwords in the form?

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

CSS Changes Do Not Appear After Updating a WordPress Site

The browser can receive an old stylesheet, load a different file than the one edited, or load the new rule and lose it in the cascade. Purging every cache may temporarily change the result without identifying which layer is stale.

Start by proving which CSS file and rule the browser actually uses.

Inspect the affected element

Use developer tools Styles/Computed. Find the expected property and whether the rule is absent, crossed out, overridden or invalid.

Classify:
rule absent -> wrong/stale asset
rule crossed out -> cascade/specificity/order
property ignored -> invalid/inapplicable
element/class changed -> selector mismatch
inline style wins -> source-specific override

Test anonymous and logged-in pages because administrators may bypass cache.

Open the stylesheet directly

Click the loaded CSS URL in Network/Styles and search for a unique new marker/rule. Record URL, query version, ETag, Last-Modified, cache headers and CDN status.

If the rule is missing, confirm you edited the active child/theme/plugin file and correct server/document root.

Do not use filesystem modification time alone; generated/minified CSS may be the served asset.

Fix the cascade rather than escalating

Compare selector specificity, source order, media/support conditions and !important. Prefer a component-scoped selector and correct load order.

.site-header .primary-navigation {
  background: #123456;
}

Avoid chains of !important that make future states and responsive rules unmaintainable.

Check CSS syntax before the rule; an unclosed brace can invalidate later declarations.

Identify generated CSS

Page builders, block themes and optimisation plugins may compile database settings into uploads/cache directories. Editing the generated file is temporary.

Change the source setting/child stylesheet, then use the builder’s regenerate CSS tool. Verify filesystem permissions and disk.

Do not delete all uploads to clear generated assets.

Version assets correctly

Enqueue site-owned styles with a release or file modification version:

wp_enqueue_style(
    'site-child',
    get_stylesheet_uri(),
    array(),
    wp_get_theme()->get( 'Version' )
);

Use a deployment-controlled version when theme headers are unchanged. Avoid random query strings on every request; they defeat caching.

Trace cache layers

Browser, service worker, WordPress, host, CDN and proxy can each cache CSS. Inspect headers and purge the exact asset after deploying a new version.

Cloudflare may ignore query strings under particular rules. Confirm cache-key policy.

Test after cache warm-up and from another network/browser; one hard refresh is weak evidence.

Check deployment and permissions

Confirm the file reached every web node and release symlink points to the intended build. A load balancer can alternate old/new assets.

Compare checksums across nodes. Make deployment atomic and invalidate OPcache only for PHP-generated asset maps.

Do not edit production directly when the next deployment will overwrite the change.

Check service workers and offline caches

A PWA/service worker can serve an old stylesheet independently of browser/CDN cache. Inspect Application > Service Workers/Cache Storage and the active worker scope/version.

Update the precache manifest and activation strategy through the PWA plugin/build process. Do not tell all visitors to unregister manually; deploy a worker that retires old caches safely. Test first visit, update and offline behaviour.

Test language and direction variants

Multilingual plugins may generate separate CSS or body classes per language. RTL files can load after the main stylesheet and override it, while translated templates use different class names.

Inspect English, Spanish and Catalan asset URLs and generated files. Scope rules to semantic components rather than language text, and rebuild each language cache. Preserve accessibility under longer translated labels.

Verify responsive and state styles

Test viewport breakpoints, hover/focus, dark mode, logged-in toolbar and language-specific markup. Confirm accessibility contrast and zoom.

Monitor CSS/asset 404s after release. Recurring care should retain versioned builds and a cache map; the durable fix makes every visitor fetch the correct stylesheet predictably.