by
Simon Mista
0 (0 reviews)
Theme SCSS Compiler
Compile SCSS to CSS in the WordPress admin. No Node.js, no npm, no build step. Several file pairs, per-file cache busting, rebuild on change.
Theme SCSS Compiler ranks #16,369 among WordPress.org plugins with 100+ active installations, is #1,120 of 5,310 in the Utilities & Tools category, and was last updated Aug 22, 2026. Data from WordPress.org, refreshed twice daily — see methodology.
Compatible with WP 7.1.4
v1.0.8
Current Version v1.0.8
Updated 2 months ago
Last Update on 22 Aug, 2026
Refreshed 1 week ago
Last Refreshed on
#1,120 of 5,310 in Utilities & Tools
Top 25% by installs
Rank
#16,369
—
No change
Active Installs
100+
—
No change
KW Avg Position
15.7
0.4 worse
Downloads
1.1K
+10 today
Support Resolved
0%
—
No change
Rating
0%
Review 0 out of 5
0
(0 reviews)
Next Milestone 200
100+
200+
3,695
Ranks to Climb
-
Growth Needed
8,000,000
Active Installs
Pro
Unlock Exact Install Count
See the precise estimated active installs for this plugin, calculated from real-time ranking data.
- Exact install estimates within tiers
- Track install growth over time
- Milestone progress predictions
Need 85 more installs to reach 200+
Rank Changes
Current
#16,369
Change
Best
#
Downloads Growth
Downloads
Growth
Peak
Upgrade to Pro
Unlock 30-day, 90-day, and yearly download history charts with a Pro subscription.
Upgrade NowReviews & Ratings
0.0
0 reviews
Overall
0%
5
0
(0%)
4
0
(0%)
3
0
(0%)
2
0
(0%)
1
0
(0%)
Security History
Source: WPVulnerabilityNo known vulnerabilities on record for Theme SCSS Compiler. Checked 3 months ago.
Track This Plugin
Get detailed analytics, keyword tracking, and position alerts delivered to your inbox.
Start Tracking FreePlugin Details
- Version
- 1.0.8
- Last Updated
- Aug 22, 2026
- Requires WP
- 6.3+
- Tested Up To
- 7.1.4
- PHP Version
- 8.1 or higher
- Author
- Simon Mista
Support & Rating
- Rating
- ☆ ☆ ☆ ☆ ☆ 0
- Reviews
- 0
- Support Threads
- 0
- Resolved
- 0%
Keywords
Upgrade to Pro
Unlock keyword rankings, search positions, and detailed analytics with a Pro subscription.
Upgrade NowSimilar Plugins
Adminify – White Label, Admin Menu Editor, Login Customizer
6K+ installs
#2,757
Master Addons for Elementor – Elementor Addons, Widgets, Mega Menu Builder, Popup Builder, Widget Builder & Template Kits
30K+ installs
#1,015
Elementor Website Builder – more than just a page builder
10M+ installs
#1
Contact Form 7
10M+ installs
#3
All-in-One WP Migration and Backup
5M+ installs
#10
UpdraftPlus: WP Backup & Migration Plugin
4M+ installs
#14
WPCode – Insert Headers and Footers + Custom Code Snippets – WordPress Code Manager
3M+ installs
#19
Hostinger Tools
3M+ installs
#20
WordPress Importer
2M+ installs
#23
WPS Hide Login
2M+ installs
#27
TL;DR
AI summary of the plugin's readmeThis plugin is for WordPress theme developers who want to compile SCSS/Sass to CSS without Node.js or build tools. It handles multiple SCSS-to-CSS file pairs directly in the WP admin, with automatic recompilation and cache-busting versioning when source files or their imports change.
- Multiple SCSS to CSS file pairs
- Per-pair frontend or admin context
- Per-file automatic version bumping
- Smart change detection
- @import-aware auto-recompile
- Compressed or expanded output
- Auto-compile on source change
- Concurrent-compile lock
Frequently Asked Questions
Common questions about Theme SCSS Compiler
No. The compiler is PHP and ships with the plugin. Nothing is installed on the server, nothing runs on your machine. You need WordPress 6.3 and PHP 8.1 or newer.
Everything you reach for in a theme stylesheet: nesting, the & parent selector, variables, mixins, functions, @extend, @media nesting, arithmetic, interpolation, and @import for splitting your styles into partials. Import chains nest as deep as you like, and every file in the chain is tracked for change detection. Partials are the @import kind, so _variables.scss is pulled in with @import "variables"; at the top of your entry file, and everything it declares is available below. The compiler is a PHP port of Sass rather than Dart Sass, so it is worth a look at the compiled output the first time you move an existing theme over.
Give a partial a leading underscore and pull it in with @import at the top of your entry file. Everything a partial declares is available to everything below it. // assets/scss/_variables.scss $brand: #0073aa; $text: #1f232b; $radius: 8px; // assets/scss/_card.scss .card { color: $text; border-radius: $radius; } // assets/scss/_menu.scss .menu a { color: $brand; } // assets/scss/style.scss — the file you set as the pair's SCSS source @import "variables"; @import "card"; @import "menu"; Note the import name drops both the underscore and the extension: the file _card.scss is imported as "card". Two things follow from this, and both are easier to get right if you know them up front. Order matters. A partial is read at the position where you import it, so @import "variables" has to come before the partials that use those variables. Variables first, the rest below. One shared scope. Every partial writes into the same namespace, so two partials that each declare $padding will quietly disagree — last one wins. Prefix instead: $card-padding, $menu-padding. Same for mixin names.
// assets/scss/_index.scss @import "variables"; @import "card"; @import "menu"; // assets/scss/style.scss @import "index"; Chains nest as deep as you like. The plugin records every file that was read at any depth, so editing _card.scss two levels down still triggers the rebuild on your next admin page load.
Every valid CSS file is already valid SCSS, so you can rename style.css to style.scss and start there. Nesting. Write child selectors inside the parent instead of repeating it: .card { padding: 1rem; a { color: rebeccapurple; } } compiles to .card { padding: 1rem; } and .card a { color: rebeccapurple; }. The & parent reference, useful for states: .button { background: #0073aa; &:hover { background: #005177; } &.active { background: #003f66; } } compiles to .button, .button:hover and .button.active with those three colours. Variables. Set a value once and reuse it: $brand: #0073aa; a { color: $brand; } .button { background: $brand; } One thing that surprises people: the default output style is compressed, so the compiled file is one long line and rebeccapurple has become #639. Set the compiler to Expanded while you are learning. Full language guide: https://sass-lang.com/guide/
Yes, one kind of file. It is a compiler, so the boundary matters more than a reassuring "no". It writes the CSS target of each pair, for example assets/css/style.css. That file is replaced in full on every compile, so treat it as build output and never hand-edit it. It also creates the directory for that file when the directory does not exist. Each compile briefly writes a second file next to the target, style.css.tscsscompiler-tmp, and renames it onto the target when it is finished — that is what makes the swap atomic. It is gone by the time the compile returns. The name deliberately does not end in .css, so if a process is killed part-way the leftover is never served as a stylesheet; you can delete it. It writes nothing else. Your SCSS is only read. functions.php, templates and every other non-.css file are unreachable, because a target without a .css extension is refused before the write. Nothing outside the active theme can be written either: .. is rejected, and a target that turns out to be a symlink pointing out of the theme is rejected too. Cache-busting versions are never written into a file. They go onto the stylesheet URL at request time through the style_loader_src filter, so your theme's own wp_enqueue_style() calls stay as they are. One thing to watch: the target does not have to be a new file. Point a pair at a .css file that already exists in your theme and that file is replaced.
No, that one target is refused. style.css is where WordPress reads Theme Name: from, and a compile replaces the whole file, so one typo there would leave the theme unrecognisable and drop it out of Appearance → Themes. The plugin says so instead of writing. Compile to a separate file and enqueue it alongside your style.css: assets/scss/style.scss → assets/css/style.css Any other name works too. Only the theme's own root style.css is off limits; a style.css in a subfolder is fine.
Only when that pair's freshly compiled CSS differs from the file already on disk. Other pairs keep their version. An edit that produces identical CSS does not move the version. That covers // comments in any mode, and /* */ comments in compressed output, because those are stripped. In expanded output a /* */ comment is part of the CSS, so editing one is a real change and does bump the version. Versions are three-part numbers and the patch digit advances: 1.0.4 becomes 1.0.5.
Two separate settings, with different defaults. Auto-compile is on by default. On every wp-admin page load it checks whether any compiled CSS is missing or older than its SCSS source or tracked partials, and rebuilds what needs it. Nothing runs on a schedule; your own page load triggers it. Auto-recompile is off by default. Turn it on and the settings page runs a countdown, from 1 to 999 seconds, and re-checks on each tick while that page stays open in your browser. It counts down only while that tab is the one you are looking at, and it holds off while the form has unsaved changes; the readout says which of the two is happening. It compiles only when something actually changed, so a page left open does not keep rewriting the CSS. They are independent. Switching Auto-compile off does not stop the timer. To compile only on the button, switch both off.
In this order: Did you save the settings? Compile now is locked while the form has unsaved changes, and clicking it then does nothing. Press Compile now and read the message. A missing source file or a syntax error shows up here. Look at the pair's version. If it did not move, the compiled CSS came out identical and the browser is correctly serving what it has. Check whether "Bump CSS version after each compile" is on. With it off the URL never changes and browser caches keep the old file. If pairs come from TSCSSCOMPILER_PAIRS, versions are never rewritten. Edit the version value in your code. Check your caching plugin and CDN. A version in the URL does not help if something upstream serves a cached response.
