Download the PHP package wapplersystems/ws-scss without Composer
On this page you can find all versions of the php package wapplersystems/ws-scss. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download wapplersystems/ws-scss
More information about wapplersystems/ws-scss
Files in wapplersystems/ws-scss
Package ws-scss
Short Description Compiles SCSS to CSS at runtime with caching, TypoScript variables and EXT: import support
License GPL-2.0-or-later
Homepage https://github.com/WapplerSystems/ws_scss
Informations about the package ws-scss
SASS Compiler for TYPO3 (ws_scss)
Compiles SCSS files to CSS at runtime. Uses SCSSPHP as compiler. Compiled CSS is cached and only recompiled when source files or variables change.
Installation
Requirements
- TYPO3 v14
- PHP 8.2+
Usage via TypoScript
Include SCSS files with the standard page.includeCSS — the extension automatically compiles any .scss file:
Custom output file
Output style
compressed (default) or expanded:
Source maps
Enables SCSS file/line references in browser DevTools:
Inline output
Renders CSS inline in a <style> tag instead of a <link> reference:
Variables
Global variables
Available in all SCSS files:
Per-file variables
Override or extend global variables for a specific file:
Using variables in SCSS
Variables defined via TypoScript are directly available as SCSS variables:
Variable type conversion
The extension automatically converts TypoScript values to proper SCSS types:
| TypoScript value | SCSS type |
|---|---|
#007bff |
Color (RGB) |
16px |
Number with px unit |
1.5rem |
Number with rem unit |
"Arial, sans-serif" |
String |
| Other values | Generic value |
SCSS imports
Standard SCSS imports work as expected. Additionally, the extension supports TYPO3's EXT: paths:
File resolution order: filename.scss, _filename.scss, filename.css.
Usage via Fluid ViewHelper
The extension registers a ViewHelper for compiling SCSS in Fluid templates.
File-based
With variables
Inline SCSS
ViewHelper arguments
| Argument | Type | Required | Description |
|---|---|---|---|
identifier |
string | yes | Unique ID for asset deduplication |
href |
string | no | Path to SCSS file (EXT: or fileadmin/) |
scssVariables |
array | no | Variables to pass to the compiler |
outputfile |
string | no | Custom path for compiled CSS output |
forcedOutputLocation |
string | no | Force inline or file output |
priority |
bool | no | Load before other stylesheets |
disabled |
bool | no | Add disabled attribute |
Events
AfterVariableDefinitionEvent
Modify variables before compilation:
AfterScssCompilationEvent
Post-process compiled CSS:
Caching
Compiled CSS is cached in typo3temp/assets/css/. Bookkeeping for that cache lives in a separate
TYPO3 cache identifier, ws_scss, registered with NonFlushableFileBackend -- a generic
cache:flush (CLI, deploy hook, Backend "Clear all caches") deliberately does not clear it, in
any environment. This is intentional: it used to get wiped by every unrelated flush, which forced a
full recompile of every configured SCSS entry on the very next request -- for every visitor hitting
the site concurrently right after a deploy/flush, since nothing about the .scss sources had actually
changed.
To invalidate it on purpose (i.e. after an actual .scss source change), use one of:
- the Backend's "Flush SCSS cache" entry in the "Clear cache" toolbar menu, or
- wire the CLI command into your deploy pipeline, e.g. a composer
post-autoload-dump/post-update-cmdscript, so it runs automatically on everycomposer install/update.
trustCacheWithoutRevalidation
By default (true), a cache hit is trusted without re-validating the .scss source -- no
file_get_contents()/sha1() walk of the whole @import tree, no scssphp Compiler/importer setup,
just a cache-existence check. This is what removes the per-request revalidation cost entirely (not
just the recompile-after-flush cost above).
Trade-off: with this on, editing a .scss source -- including a transitively @import-ed
partial, or (for wapplersystems/ws-components) a component .scss file that isn't the top-level
synthesized bundle string -- no longer self-heals on the next request. An explicit wsscss:flush
is required after every real .scss change, in every environment (this is not gated by
Production vs. Development context) -- otherwise the previously compiled CSS keeps being served
indefinitely, silently, without error or warning.
To restore the old always-revalidate-by-content-hash behaviour (safe for local development without
remembering to flush, at the cost of the full @import-tree walk on every call, hit or miss), disable
it per project -- either in the Backend under Admin Tools > Settings > Extension Configuration >
ws_scss, or via config file:
Complete example
License
GPL-2.0-or-later