用於WordPress主題開發的現代Sass工作流程

為 WordPress 主題建立現代、可維護的 CSS 程式碼面臨著開發者需要克服的諸多挑戰。使用 Sass（Syntactically Awesome Style Sheets，語法超讚樣式表）作為 CSS 前處理器可以幫助您更有效地組織、維護和擴充套件樣式。

然而，要建立一個高效的、與 WordPress 開發自然契合的 Sass 工作流程，需要周密的規劃和技術知識。

本指南將向您展示如何為 WordPress 主題開發設定專業的 Sass 工作流程。它涵蓋了現代構建工具、智慧檔案組織和部署實踐，這些實踐可以提高工作效率並確保樣式的可維護性。

使用Sass進行WordPress開發的背景

專業的 WordPress 開發通常依賴於超出平臺內建功能的工具和工作流程。Sass 可以透過變數、巢狀、混合、匯入和內建函式等功能幫助您管理 CSS 的複雜性，從而發揮關鍵作用。

Sass 網站

Sass 為主題開發提供了諸多優勢。一個典型的 WordPress 主題包含眾多元件和模板部分的樣式。Sass 並非將所有內容都放在一個笨重的樣式表中管理，而是採用模組化架構，透過程式化結構提升可維護性和可擴充套件性。

這種結構化方法超越了標準 CSS 的功能，並且能夠很好地滿足 WordPress 獨特的樣式需求。與在 WordPress 中使用 style.css 不同，Sass 允許您建立模組化、特定用途的樣式表，並透過簡單的工作流程將其編譯為最佳化的 CSS 檔案：

1. 將 Sass 檔案編譯為 CSS 的構建流程。
2. 以可維護方式組織樣式的檔案結構。
3. 用於本地測試和質量保證的開發工具。
4. 將更改推送到預釋出環境和生產環境的部署策略。

如何實施此工作流程取決於您團隊的工具偏好、技術堆疊和專案複雜性。但大多數基於 Sass 的 WordPress 設定都遵循一些常見的做法：配置源對映以進行除錯、在開發過程中監視檔案以及最佳化生產環境的輸出。

典型的設定會將 Sass 原始檔與編譯後的資原始檔分開，從而更易於維護程式碼庫並向瀏覽器提供清晰的輸出。

在WordPress專案中編譯Sass的3種方法

任何 Sass 工作流的基礎都是將 Sass 檔案轉換為瀏覽器可用的 CSS 的構建過程。在 WordPress 中，有幾種方法可以實現這一點。

1. 使用外掛：最直接的方法

在 WordPress 主題中使用 Sass 最便捷的方式是透過外掛。如果您剛剛開始使用 Sass，或者正在開發一個不需要完整構建流程的小型專案，這種方法是理想的選擇。

例如，WP-Sass 透過 WordPress 內建的 wp-config.php 操作鉤子來處理編譯，並監控主題的 Sass 目錄是否發生變化：

<?php
// Include the class (unless you are using the script as a plugin)
require_once( 'wp-sass/wp-sass.php' );
// enqueue a .less style sheet
if ( ! is_admin() )
wp_enqueue_style( 'style', get_stylesheet_directory_uri() . '/style.scss' );
else
wp_enqueue_style( 'admin', get_stylesheet_directory_uri() . '/admin.sass.php' );
// you can also use .less files as mce editor style sheets
add_editor_style( 'editor-style.sass' );
?>

另一個選項 Sassify 稍舊一些，它採用了不同的方法——透過連線到 WordPress 的 API 來管理 Sass 的編譯、輸出路徑和壓縮設定。

雖然基於外掛的解決方案很簡單，但它們也有一些侷限性：

• 效能開銷。這些外掛在伺服器上編譯 Sass，這會消耗大量資源。
• 構建選項有限。大多數 Sass 外掛提供基本的編譯功能，但缺少必要的功能。例如，通常對源對映的支援有限，缺少自動新增字首功能等等。
• 安全注意事項。在生產伺服器上執行編譯器可能會增加潛在的攻擊面，尤其是在外掛沒有定期維護的情況下。
• 版本控制問題。編譯後的 CSS 檔案通常位於主題目錄中，這會使清理 Git 工作流程變得複雜。理想情況下，編譯後的資源應該遠離你的程式碼庫。

然而，儘管存在這些侷限性，但在某些情況下，外掛仍然是一個不錯的選擇。例如，具有最少樣式要求的小型網站、將專案交給沒有技術專業知識來更深入地使用 Sass 的客戶，或者在開發資源受限的情況下進行工作。

2. 使用NPM指令碼：平衡的解決方案

如果您追求更強的控制力和靈活性，NPM 指令碼可能是外掛的可靠替代方案。Sass 編譯是 NPM 的理想選擇，因為它在簡潔性和功能性之間取得了平衡。它比外掛在主題開發方面提供了顯著的改進，而無需完整任務執行器的複雜性：

• 透過將編譯與 WordPress 執行分開，您可以消除伺服器效能開銷。
• 您可以精確控制編譯過程的每個步驟。
• package.json 檔案確保所有團隊成員使用相同的構建流程。
• npm 指令碼與 CI/CD 流水線無縫整合。

雖然這種方法比外掛需要更多的初始設定，但它為專業主題開發提供了更強大、更可擴充套件的解決方案。

使用NPM進行Sass編譯

首先建立一個 package.json 檔案。您可以透過執行以下命令來執行此操作：

npm init -y

然後安裝 Dart Sass：

npm install sass --save-dev

接下來，將這些指令碼新增到您的 package.json：

{
"name": "your-theme-name",
"version": "1.0.0",
"description": "A WordPress theme with Sass",
"scripts": {
"sass": "sass src/sass/main.scss:assets/css/main.css",
"sass:watch": "sass --watch src/sass/main.scss:assets/css/main.css",
"build": "sass src/sass/main.scss:assets/css/main.css --style=compressed"
},
"devDependencies": {
"sass": "^1.58.3"
}
}

此設定為您提供三個實用指令碼：

• npm run sass 編譯一次您的 Sass 檔案。
• sass:watch 監視更改並根據需要重新編譯。
• build 壓縮編譯您的 Sass 檔案以供生產環境使用。

要支援舊版瀏覽器，請透過 PostCSS 新增 Autoprefixer：

npm install postcss postcss-cli autoprefixer --save-dev

更新您的 package.json 指令碼：

{
"scripts": {
"sass": "sass src/sass/main.scss:assets/css/main.css",
"prefix": "postcss assets/css/main.css --use autoprefixer -o assets/css/main.css",
"build": "npm run sass && npm run prefix"
},
"devDependencies": {
"autoprefixer": "^10.4.13",
"postcss": "^8.4.21",
"postcss-cli": "^10.1.0",
"sass": "^1.58.3"
},
"browserslist": [
"last 2 versions",
"> 1%"
]
}

為了幫助除錯，新增源對映：

{
"scripts": {
"sass": "sass src/sass/main.scss:assets/css/main.css --source-map",
"sass:watch": "sass --watch src/sass/main.scss:assets/css/main.css --source-map"
}
}

最後，要在 WordPress 中使用已編譯的 CSS，請將已編譯的 CSS 放入 functions.php 佇列中：

function theme_enqueue_styles() {
$style_path = '/assets/css/main.css';
$full_path = get_template_directory() . $style_path;
wp_enqueue_style(
'theme-styles',
get_template_directory_uri() . $style_path,
array(),
file_exists($full_path) ? filemtime($full_path) : false
);
}
add_action('wp_enqueue_scripts', 'theme_enqueue_styles');

此函式會載入已編譯的 CSS，並使用檔案的修改時間作為版本號來新增自動快取清除功能。

3. 使用Gulp：全面的解決方案

Gulp 是一款功能強大的任務執行器，擅長自動化複雜的構建流程。對於需要大量樣式設計的 WordPress 主題開發來說，它是最全面的解決方案。它能夠幫助您處理 Sass 編譯、瀏覽器同步以及介於兩者之間的所有操作。為什麼選擇 Gulp？

• Gulp 幾乎可以管理構建流程的各個方面，例如編譯、最佳化和部署。
• 您可以同時執行多個任務，從而縮短構建時間。
• 其生態系統提供了幾乎滿足所有構建需求的工具。
• BrowserSync 整合可在開發過程中提供即時反饋。

雖然 Gulp 的學習曲線比其他方法更陡峭，但它的優勢使其成為許多人的首選。

為WordPress主題設定Gulp

開始使用 Gulp 需要安裝它以及幾個用於處理特定任務的外掛：

# Initialize your project
npm init -y
# Install Gulp and related packages
npm install --save-dev gulp gulp-sass sass gulp-autoprefixer gulp-sourcemaps browser-sync gulp-cssnano

您還應該在主題的根目錄中建立一個 gulpfile.js，它處理幾個不同的步驟。第一部分是匯入所有必要工具的方法：

// 1. Import dependencies
const { src, dest, watch, series, parallel } = require('gulp');
const sass = require('gulp-sass')(require('sass'));
const autoprefixer = require('gulp-autoprefixer');
const sourcemaps = require('gulp-sourcemaps');
const browserSync = require('browser-sync').create();
const cssnano = require('gulp-cssnano');

每個軟體包都有其特定的用途：

• gulp：核心任務執行器。
• gulp-sass 和 sass：將 Sass 編譯為 CSS。
• gulp-autoprefixer：新增供應商字首以實現瀏覽器相容性。
• gulp-sourcemaps：生成用於除錯的原始碼對映。
• browser-sync：在開發過程中重新整理瀏覽器。
• gulp-cssnano：壓縮 CSS 以供生產環境使用。

在這裡，您可以定義原始檔和目標檔案的路徑，並建立一個函式來編譯 Sass：

// 2. Define file paths
const files = {
sassPath: './src/sass/**/*.scss',
cssPath: './assets/css/'
}
// 3. Sass development task with sourcemaps
function scssTask() {
return src(files.sassPath)
.pipe(sourcemaps.init())
.pipe(sass().on('error', sass.logError))
.pipe(autoprefixer())
.pipe(sourcemaps.write('./'))
.pipe(dest(files.cssPath))
.pipe(browserSync.stream());
}

此函式主要負責查詢所有 Sass 檔案，初始化源對映以便除錯，並將 Sass 編譯為 CSS（並進行錯誤處理）。此外，它還會新增供應商字首以相容瀏覽器，編寫源對映，儲存編譯後的 CSS，並根據更改更新瀏覽器。總而言之，它做了很多工作！

您還需要考慮建立一個可用於生產的構建函式、一個任務監視器和一個匯出函式：

// 4. Sass production task with minification
function scssBuildTask() {
return src(files.sassPath)
.pipe(sass().on('error', sass.logError))
.pipe(autoprefixer())
.pipe(cssnano())
.pipe(dest(files.cssPath));
}
// 5. Watch task for development
function watchTask() {
browserSync.init({
proxy: 'localhost:8888' // Change this to match your local development URL
});
watch(files.sassPath, scssTask);
watch('./**/*.php').on('change', browserSync.reload);
}
// 6. Export tasks
exports.default = series(scssTask, watchTask);
exports.build = scssBuildTask;

此生產版本省略了源對映，並新增了最小化功能以最佳化檔案大小。總而言之，此設定允許您執行 npx gulp 進行開發（帶有檔案監視和瀏覽器重新整理功能），並執行 npx gulp build 進行生產構建。

增強您的Gulp工作流程

對於較大的專案，您可能需要根據不同的用途區分樣式。以下是示例：

// Define paths for different style types
const paths = {
scss: {
src: './src/sass/**/*.scss',
dest: './assets/css/'
},
editorScss: {
src: './src/sass/editor/**/*.scss',
dest: './assets/css/'
}
}
// Main styles task
function mainStyles() {
return src('./src/sass/main.scss')
.pipe(sourcemaps.init())
.pipe(sass().on('error', sass.logError))
.pipe(autoprefixer())
.pipe(sourcemaps.write('./'))
.pipe(dest(paths.scss.dest))
.pipe(browserSync.stream());
}
// Editor styles task
function editorStyles() {
return src('./src/sass/editor-style.scss')
.pipe(sourcemaps.init())
.pipe(sass().on('error', sass.logError))
.pipe(autoprefixer())
.pipe(sourcemaps.write('./'))
.pipe(dest(paths.scss.dest))
.pipe(browserSync.stream());
}

對於包含大量 Sass 檔案的複雜主題，您還應該透過快取已處理的檔案以避免不必要的重新編譯、跟蹤 Sass 依賴項以僅重新編譯受影響的檔案等方式來最佳化構建效能。不過，這超出了本文的討論範圍。

其他值得考慮的構建工具

雖然大多數開發者堅持使用 NPM 指令碼或 Gulp，但您可能會發現其他一些為 WordPress 主題開發提供獨特優勢的替代方案。Vite 和 Webpack 是兩種常見的解決方案。

Webpack 擅長打包 JavaScript 和資源，如果您的主題使用基於元件的架構或 JavaScript 框架，這將是理想的選擇。它的優勢在於能夠透過程式碼拆分和“搖樹最佳化”建立最佳化的軟體包，這對於複雜且 JavaScript 密集的主題非常有價值。

相比之下，Vite 是一款較新的構建工具，它透過其創新的模組載入方法優先考慮開發速度。它的開發伺服器提供近乎即時的熱模組替換。這是一種實現迭代開發的快速方法。雖然它與 WordPress 工作流程的整合仍在不斷發展，但如果您可以利用它進行自己的主題開發，這將是一個令人興奮的選擇。

對於更簡單的專案或個人偏好，Sass CLI 提供了一種無需額外工具的簡單方法：

# Install Sass globally
npm install -g sass
# Compile Sass files
sass --watch src/sass/main.scss:assets/css/main.css

雖然手動編譯缺乏專用構建工具的自動化和整合功能，但其簡單性確實具有優勢。這種方法非常適合具有簡單樣式需求的簡單主題、快速原型或小型專案。它也適合那些喜歡極簡工具的使用者。

如何使用Sass構建和組織WordPress開發專案

除了構建過程之外，有效地組織 Sass 檔案對於可維護性和協作至關重要。精心規劃的結構可以使您的程式碼隨著主題的增長而更易於導航、更新和擴充套件。

7-1 模式：複雜主題的模組化組織

7-1 模式是大型專案中組織 Sass 檔案的典型做法。它將樣式程式碼分為七個主題資料夾和一個匯入所有內容的主檔案 (main.scss)。

這種模式建立了邏輯上的分離，使查詢和更新特定樣式變得更加容易。以下是該結構的概述：

• Abstracts。包含不直接輸出 CSS 的助手程式、顏色、排版和間距變數、計算和邏輯函式、可重用樣式模式的 mixin 以及可擴充套件樣式的佔位符。
• Base。包括基本樣式和預設值、排版規則、實用程式類和元素選擇器（不帶類）。它還允許您重置或規範化 CSS。
• Components。它包含可重用的 UI 元件，例如按鈕、表單和卡片、導航選單、小部件和側邊欄以及媒體格式（例如影像、影片）。
• Layouts。您可以在此處定義結構元素，例如頁首和頁尾、網格系統、容器結構和側邊欄排列。
• Pages。這包含頁面特定的樣式、主頁專業化、單個帖子佈局、存檔頁面變體和特殊登入頁面。
• Themes。在此部分，您可以擁有不同的視覺主題或模式。明暗主題、季節性變化、管理區域自定義和品牌特定主題都在這裡。
• Vendors。最後一部分用於儲存第三方樣式、外掛覆蓋、框架自定義以及外部元件樣式。

主檔案（通常為 main.scss）會按特定順序匯入所有部分：

// Abstracts
@import 'abstracts/variables';
@import 'abstracts/mixins';
// Vendors (early to allow overriding)
@import 'vendors/normalize';
// Base styles
@import 'base/reset';
@import 'base/typography';
// Layout
@import 'layouts/header';
@import 'layouts/grid';
// Components
@import 'components/buttons';
@import 'components/forms';
// Page-specific styles
@import 'pages/home';
@import 'pages/blog';
// Themes
@import 'themes/admin';

這種模組化方法可以避免大型專案中經常出現的“CSS 大雜燴”。它是一個可維護的系統，可以根據主題的複雜性進行擴充套件。

以區塊為中心的結構：區塊和站點編輯器的現代化組織

如果您的主題專注於區塊編輯器，那麼優先考慮這些元件的結構通常更有意義。這可以使您的 Sass 組織與 WordPress 基於塊的內容模型保持一致。

與 7-1 模式相比，該結構更加直觀：

• Core。您的基礎樣式和配置位於此處，例如變數、混合宏、輔助函式、基本元素樣式和核心 WordPress 區塊。
• Blocks。這是自定義塊變體、擴充套件的核心塊樣式和區塊樣板樣式所在的位置。
• Templates。您將在此處新增單個文章模板、存檔模板和自定義頁面模板。
• Utilities。這些是輔助類和工具，例如間距實用程式、排版類以及顏色或背景實用程式。

這種結構支援使用 Blocks 進行開發的模組化特性，從而更容易在變體和模板之間保持一致性。

WordPress特定Sass組織注意事項

在組織 WordPress 主題的 Sass 時，需要注意幾個特定於平臺的注意事項。WordPress 的模板結構決定了不同型別的內容應使用哪些 PHP 檔案。

在 Sass 組織中映象此層次結構可以在 PHP 模板及其相關樣式之間建立直觀的聯絡。因此，請考慮組織頁面特定的樣式以匹配 WordPress 模板結構：

// _archive.scss
.archive {
// Base archive styles
&.category {
// Category archive styles
}
&.tag {
// Tag archive styles
}
&.author {
// Author archive styles
}
}

這種方法可以立即明確哪些樣式適用於特定的模板上下文，同時簡化維護和更新。

外掛相容性組織

外掛通常會注入自己的樣式，而您的主題可能需要覆蓋這些樣式。與其將覆蓋樣式分散到您的基礎檔案中，不如考慮將它們隔離開來：

例如，WooCommerce 整合的結構可以採用多種結構之一：

vendors/woocommerce/
├── _general.scss          // Base WooCommerce styles
├── _buttons.scss          // WooCommerce button styles
├── _forms.scss            // WooCommerce form styles
├── _shop.scss             // Shop page styles
└── _single-product.scss   // Single product page styles

這種組織方式使得在外掛更新時輕鬆更新外掛相容樣式，保持主題樣式和外掛樣式之間的分離，並快速找到與外掛相關的特定樣式。

始終為覆蓋設定名稱空間，以避免樣式衝突：

// _woocommerce.scss
.woocommerce {
.products {
// Custom product grid styles
display: grid;
grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
gap: 2rem;
}
.single-product {
// Single product page styles
.price {
font-size: 1.5rem;
color: $price-color;
}
}
}

這種方法可以防止外掛樣式滲透到主題的核心設計中，同時在需要的地方提供清晰的覆蓋。

編輯器和後臺樣式

您通常需要同時設定前端和區塊編輯器介面的樣式。因此，您可以為後臺特定的樣式建立專用的結構：

admin/
├── _editor.scss         // Block editor styles
├── _login.scss          // Login page customization
└── _dashboard.scss      // Dashboard customizations

對於區塊編輯器支援，編譯一個單獨的樣式表並像這樣將其排隊：

function theme_editor_styles() {
add_theme_support('editor-styles');
add_editor_style('assets/css/editor.css');
}
add_action('after_setup_theme', 'theme_editor_styles');

這可以使您的編輯器上下文保持簡潔、一致，並在視覺上與前端保持一致。

響應式設計實現

WordPress 主題必須相容各種尺寸的裝置，因此您需要系統地進行響應式設計。這時，使用 Sass mixins 可以建立一個一致且可維護的系統：

// Breakpoint mixin
@mixin respond-to($breakpoint) {
@if $breakpoint == "sm" {
@media (min-width: 576px) { @content; }
}
@else if $breakpoint == "md" {
@media (min-width: 768px) { @content; }
}
@else if $breakpoint == "lg" {
@media (min-width: 992px) { @content; }
}
}

如果將響應式樣式與其基本定義保持上下文接近，則可以建立更易於維護的程式碼庫，並清晰地展示元件如何跨斷點進行自適應。

設定本地開發環境

本地開發是任何 WordPress 工作流程的核心部分——在使用 Sass 等工具時，這一點尤為重要。正確的設定可以實現快速迭代、即時反饋，並在 Sass 構建流程和 WordPress 網站之間實現無縫連線。

您可以選擇 MAMP 或者其他成熟的本地開發環境。使用這些軟體，根據您的需求進行定製，安裝和設定非常簡單。

使用 Gulp 在主題目錄中設定 Sass 編譯是最直接的選擇。首先，導航到主題目錄，然後初始化 NPM 並安裝依賴項，就像我們之前解釋的那樣。

接下來，建立一個 gulpfile.js 檔案，併為您的網站配置 BrowserSync：

const { src, dest, watch, series } = require('gulp');
const sass = require('gulp-sass')(require('sass'));
const autoprefixer = require('gulp-autoprefixer');
const sourcemaps = require('gulp-sourcemaps');
const browserSync = require('browser-sync').create();
// Get your DevKinsta site URL from the dashboard
const siteURL = 'your-site-name.local';
function scssTask() {
return src('./src/sass/**/*.scss')
.pipe(sourcemaps.init())
.pipe(sass().on('error', sass.logError))
.pipe(autoprefixer())
.pipe(sourcemaps.write('./'))
.pipe(dest('./assets/css/'))
.pipe(browserSync.stream());
}
function watchTask() {
browserSync.init({
proxy: siteURL,
notify: false
});
watch('./src/sass/**/*.scss', scssTask);
watch('./**/*.php').on('change', browserSync.reload);
}
exports.default = series(scssTask, watchTask);

然後設定檔案結構：

mkdir -p src/sass/{abstracts,base,components,layouts,pages,themes,vendors}
touch src/sass/main.scss

現在您可以執行 npx gulp 了。每當 Sass 或 PHP 檔案發生更改時，您的樣式都會進行編譯、注入瀏覽器並根據需要進行重新整理。

從開發環境遷移到生產環境

在本地開發完主題後，您需要一個可靠的策略來將其部署到預釋出環境和生產環境。

這可確保編譯後的 CSS 和 Sass 原始檔安全地遷移到暫存區。對於部署需求更復雜的團隊，可以使用 Gulp 自動化暫存部署。以下是示例：

const { src, parallel, series } = require('gulp');
const rsync = require('gulp-rsync');
// Clean and build tasks defined earlier
// Deployment task
function deployToStaging() {
return src('dist/**')
.pipe(rsync({
root: 'dist/',
hostname: 'your-sftp-host',
destination: 'public/wp-content/themes/your-theme/',
archive: true,
silent: false,
compress: true
}));
}
// Export the deployment task
exports.deploy = series(
parallel(cleanStyles, cleanScripts),
parallel(styles, scripts),
deployToStaging
);

部署到臨時環境後，您仍然應該進行全面的測試，以確保 Sass 編譯的 CSS 能夠正常工作：

1. 視覺測試。驗證所有樣式是否按預期在各個頁面上應用。
2. 響應式測試。檢查所有斷點是否正常執行。
3. 效能測試。Google PageSpeed Insights、Lighthouse 和其他工具可以幫助您檢查 CSS 載入情況。
4. 跨瀏覽器驗證。請記住在不同的瀏覽器上進行測試以發現相容性問題。

在測試期間，請特別注意路徑、快取設定和檔案許可權，因為這些是導致部署問題的常見原因。接下來，您可以將主題部署到生產環境。

在部署之前，你還需要確保 CSS 得到適當的最佳化。最佳化的方法有很多，例如壓縮、檔案組織和快取清除。

建立有效的區塊編輯器整合

現代 WordPress 開發以區塊編輯器為中心，良好的樣式設計將確保編輯和前端之間的一致性。

例如，與其純粹按照頁面模板來組織樣式，不如考慮以區塊為中心進行組織。您可以先為每種區塊型別建立專用的 Sass 區域性程式碼：

blocks/
├── _paragraph.scss      // Paragraph block styles
├── _heading.scss        // Heading block styles
├── _image.scss          // Image block styles
├── _gallery.scss        // Gallery block styles
└── _custom-block.scss   // Custom block styles

這樣，隨著 WordPress 核心的演變和主題區塊庫的擴充，樣式的維護將變得更加輕鬆。每個區塊的樣式都可以整齊地儲存並獨立更新。

在每個區塊檔案中，請嘗試建立與 WordPress 區塊類一致的清晰命名約定：

// _paragraph.scss
.wp-block-paragraph {
// Base paragraph block styles
font-family: $body-font;
line-height: 1.6;
// Block variations
&.is-style-lead {
font-size: 1.2em;
font-weight: 300;
}
&.has-background {
padding: 1.5rem;
}
}

這種方法在塊編輯器控制元件和生成的樣式之間建立了直接關聯，從而使您的主題更具可預測性和可維護性。

為了使編輯體驗與前端保持同步，請編譯單獨的樣式表並在它們之間共享變數：

// In your gulpfile.js
function themeStyles() {
return src('./src/sass/main.scss')
.pipe(sass().on('error', sass.logError))
.pipe(autoprefixer())
.pipe(dest('./assets/css/'));
}
function editorStyles() {
return src('./src/sass/editor.scss')
.pipe(sass().on('error', sass.logError))
.pipe(autoprefixer())
.pipe(dest('./assets/css/'));
}

專門為區塊編輯器上下文排隊這些編輯器樣式：

function theme_editor_styles() {
add_theme_support('editor-styles');
add_editor_style('assets/css/editor.css');
}
add_action('after_setup_theme', 'theme_editor_styles');

為了保持視覺一致性，您可以在兩個樣式表中使用共享變數和混合：

// abstracts/_variables.scss
$primary-color: #0073aa;
$secondary-color: #23282d;
$heading-font: 'Helvetica Neue', Helvetica, Arial, sans-serif;
$body-font: 'Georgia', serif;
// Import in both main.scss and editor.scss

這種方法可確保編輯和檢視體驗中的顏色、字型和間距保持一致。

與theme.json整合

theme.json 檔案是 Block 主題定義全域性設定的方式，這些設定會影響編輯器和前端。將 Sass 變數與 theme.json 設定對齊可以建立一個有凝聚力的系統。例如：

{
"version": 2,
"settings": {
"color": {
"palette": [
{
"name": "Primary",
"slug": "primary",
"color": "#0073aa"
}
]
}
}
}

您可以在 Sass 檔案中匹配此內容：

// Match theme.json values
$color-primary: #0073aa;
// Generate matching custom properties
:root {
--wp--preset--color--primary: #{$color-primary};
}

這種簡單的同步功能將確保您的自定義樣式與塊編輯器的內建控制元件和全域性樣式系統協調一致。

使用Sass進行效能最佳化

效能最佳化是專業 WordPress 主題的關鍵考慮因素。除了基本的編譯功能外，Sass 工作流還可以引入其他多種技術來提升載入速度和使用者體驗 (UX)。

實現關鍵CSS以加快載入速度

關鍵 CSS 是一種最佳化技術，它提取並內聯網站在“首屏”渲染內容所需的最少 CSS。在 WordPress 開發中，關鍵渲染路徑通常非常重要；最佳化關鍵 CSS 可以透過減少阻塞渲染的 CSS 來提升感知載入時間。

編寫關鍵 CSS 本身就是一門技能——新增 Sass 會進一步提升難度。首先，您需要為關鍵樣式建立一個單獨的 Sass 檔案，然後配置構建流程以單獨編譯此檔案：

// critical.scss - Only include styles for above-the-fold content
@import 'abstracts/variables';
@import 'abstracts/mixins';
// Only essential styles
@import 'base/reset';
@import 'layouts/header';
@import 'components/navigation';
function criticalStyles() {
return src('./src/sass/critical.scss')
.pipe(sass().on('error', sass.logError))
.pipe(autoprefixer())
.pipe(cssnano())
.pipe(dest('./assets/css/'));
}

要在主題中實現這個關鍵的 CSS，您只需在非同步填充 CSS 載入時將其內聯在 head 標籤中：

function add_critical_css() {
$critical_css = file_get_contents(get_template_directory() . 
'/assets/css/critical.css');
echo '' . $critical_css . '';
// Async load full CSS
echo '';
}
add_action('wp_head', 'add_critical_css', 1);

此技術可以更快地顯示內容，同時其餘樣式在後臺載入。但是，並非每個頁面都需要主題的所有樣式。基於當前模板或內容型別的條件載入可以進一步提升效能。

您可以透過在主題的 functions.php 中載入特定於模板的 CSS 來實現此目的：

function load_template_specific_css() {
// Base styles for all pages
wp_enqueue_style('main-styles', 
get_template_directory_uri() . '/assets/css/main.css');
// Product page specific styles
if (is_singular('product')) {
wp_enqueue_style('product-styles', 
get_template_directory_uri() . '/assets/css/product.css');
} 
// Archive page specific styles
elseif (is_archive()) {
wp_enqueue_style('archive-styles', 
get_template_directory_uri() . '/assets/css/archive.css');
}
}
add_action('wp_enqueue_scripts', 'load_template_specific_css');

這種方法可以減少每個頁面的 CSS 負載，縮短載入時間，並保持較高的設計質量。

實現智慧快取控制

管理快取始終會讓終端使用者受益，因為他們可以獲得最新的樣式，同時利用快取來儲存未更改的資源。使用 Sass 自動清除快取會在主題的樣式佇列中進行：

function enqueue_styles_with_cache_busting() {
$css_file = get_template_directory() . '/assets/css/main.css';
$version = filemtime($css_file);
wp_enqueue_style('main-styles', 
get_template_directory_uri() . '/assets/css/main.css', 
array(), $version);
}
add_action('wp_enqueue_scripts', 'enqueue_styles_with_cache_busting');

此技術使用檔案的修改時間作為版本號，確保瀏覽器僅在 CSS 發生更改之前快取 CSS，然後自動下載更新版本。

安全管理源對映

源對映在開發過程中非常重要，但在生產環境中可能會暴露您的 Sass 原始碼。這時，實施特定於環境的源對映處理可能會有所幫助：

// In your gulpfile.js
const isProduction = process.env.NODE_ENV === 'production';
function styles() {
return src('./src/sass/main.scss')
.pipe(gulpif(!isProduction, sourcemaps.init()))
.pipe(sass().on('error', sass.logError))
.pipe(autoprefixer())
.pipe(gulpif(!isProduction, sourcemaps.write('./')))
.pipe(dest('./assets/css/'));
}

對於生產中的受控除錯，您可能希望僅向管理員提供源對映：

function conditional_source_maps() {
// Only for administrators with debug parameter
if (current_user_can('manage_options') && isset($_GET['debug_css'])) {
wp_enqueue_style('debug-maps', 
get_template_directory_uri() . '/assets/css/main.css.map');
}
}
add_action('wp_enqueue_scripts', 'conditional_source_maps', 999);

這既保留了源對映在除錯方面的優勢，又保護了您的原始碼免遭不必要的暴露——這是一個全方位的巨大優勢。

構建高效的團隊工作流程

對於任何使用 Sass 開發 WordPress 主題的團隊來說，一致的工作流程和標準都至關重要。對於特定於 Sass 的工作流程，您應該在幾個關鍵領域建立清晰的標準。

例如，嘗試為變數、混合宏和類定義一致的命名約定和模式：

// Variables: use kebab-case with descriptive prefixes
$color-primary: #0073aa;
$font-heading: 'Helvetica Neue', sans-serif;
$spacing-base: 1rem;
// Mixins: verb-based naming
@mixin create-gradient($start, $end) {
background: linear-gradient(to bottom, $start, $end);
}
// Classes: BEM convention
.card {
&__header { /* header styles */ }
&__body { /* body styles */ }
&--featured { /* featured variant */ }
}

規範新檔案加入專案的方式也是一個好主意。以下是一些您可以實施的示例標準：

• 新元件將放入 components 目錄。
• 每個元件都有自己的檔案。
• 所有檔案將使用相同的匯入順序。
• 部分檔案始終以下劃線開頭。

此外，還要定義程式碼註釋和文件的要求。您可以在 .stylelintrc 配置檔案中“規範化”這些標準，以自動執行：

{
"extends": "stylelint-config-standard-scss",
"rules": {
"indentation": 2,
"selector-class-pattern": "^[a-z][a-z0-9-]*$",
"max-nesting-depth": 3,
"selector-max-compound-selectors": 4
}
}

程式碼審查對 Sass 至關重要，因為細微的更改可能會對主題的外觀產生深遠的影響。您自己的審查流程應透過以下幾種方式專門處理樣式問題：

• 遵循樣式指南。確保新樣式符合專案當前的設計系統。
• 效能考慮。審查所有 CSS 輸出，以發現任何最佳化機會。
• 跨瀏覽器相容性。驗證您構建的樣式是否適用於所有必需的瀏覽器。

當然，您應該將這些 Sass 特有的關注點納入團隊的程式碼審查清單中，以保持整個程式碼庫的高標準。

Sass專案的版本控制策略

版本控制中有幾個 Sass 特有的注意事項值得您關注。一個重要的決定是是否提交編譯後的 CSS。有兩種觀點會影響您的選擇：

• 不提交 CSS 可以使您的程式碼庫保持整潔，但在部署期間需要構建步驟。
• 提交 CSS 會增加程式碼庫的大小，但也能確保您部署的檔案與測試檔案完全匹配。

如果您選擇不提交已編譯的檔案，則需要確保它們在您的 .gitignore 檔案中得到適當的排除：

# .gitignore
.sass-cache/
*.css.map
*.scss.map
node_modules/
/assets/css/

最後，檢查樣式​​工作的分支結構，並思考如何管理新元件（例如功能分支）、視覺變體（可以使用主題分支）以及主要設計更新（或許可以使用特定於樣式的分支）的樣式變更。

小結

現代的 Sass 工作流程可以將您的 WordPress 主題開發從一項挑戰轉變為一個結構化、可維護的流程。

高效的 Sass 工作流程的關鍵組成部分包括簡潔而強大的構建流程、周到的檔案組織、效能最佳化以及可靠的團隊工作流程。隨著塊編輯器的不斷發展，靈活而強大的 Sass 實現可以讓您在適應變化的同時，仍然能夠提供高質量的結果。