> Passess sass-lint
>遵循wordpress标准(例如主题标题)
>清洁，一致&易于维护
我有几个想法，但没有一个遵循上述标准。
删除style.css并且只使用Sass
/index.PHP /... other wordpress files ... /assets/sass/main.scss /assets/sass/...other sass files...
运行sass后，style.css将在根目录中创建。
优点：
>一致性
>易于维护
缺点：
> Scss-Lint不喜欢“wordpress主题头注释”，因为它更喜欢//注释
>没有编译sass它不可能选择wordpress后端的主题
2.同时使用style.css和Sass
/index.PHP /style.css /...other wordpress files... /assets/sass/main.scss /assets/sass/... other sass files...
优点：
>基本上解决(1)
>即使它不应该是这样的;快速更改可以轻松地添加到style.css而无需任何工具
缺点：
>不一致
>冗余
>需要多个CSS请求(一个用于style.css，一个用于编译的sass)
另外我最大的问题是：在哪里放编译的SASS？连接它与style.css似乎相当奇怪。
有任何想法吗？谢谢！
解决方法
在我给我的解决方案之前，我认为重要的是通过我们需要style.css在wordpress的原因
在wordpress中，style.css文件是必需的，以便查看后端中的主题信息。
style.css也用作get_stylesheet_uri()的默认输出。但是，这可以使用stylesheet_uri过滤器来定制。
在我看来，wordpress强制你在style.css中拥有你的主题信息的事实只是糟糕的设计，因为它增加了大约1032字节。这不是很多，但完全不必要;特别是如果可以避免，因为文件大小可能是影响网站性能的最大因素。
这不像Drupal CMS，你的主题信息存储在一个单独的文件，如yourtheme.info，所以决不暴露给最终用户
解决方案1
我认为最好的办法是：
>通过使用导入和部分(参见http://sass-lang.com/guide#topic-5)将所有sass文件编译为单个文件(如style.min.css)。随意命名为别的东西。
>在style.css中保留所有的wordpress主题头。
例如像这样：
style.css
/* Theme Name: Twenty Thirteen Theme URI: http://wordpress.org/themes/twentythirteen Author: the wordpress team Author URI: http://wordpress.org/ Description: The 2013 theme for wordpress takes us back to the blog,featuring a full range of post formats,each displayed beautifully in their own unique way. Version: 1.0 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Tags: black,brown,orange Text Domain: twentythirteen Use it to make something cool,have fun,and share what you've learned with others. */
style.min.css
p{color:red;}h1{color:blue;} ...
然后，您可以确保在frontend的每个页面上使用以下代码在functions.PHP文件中添加新的样式表：
function theme_name_stylesheets() {
wp_enqueue_style('style-name',get_template_directory_uri() . '/style.min.css');
}
add_action( 'wp_enqueue_scripts','theme_name_stylesheets' );
更多信息参见：https://codex.wordpress.org/Function_Reference/wp_enqueue_style
因此，当你运行wp_head()在你的文档的头部，它会自动添加正确的CSS文件。
然后你可以在你的sass文件上运行sass-lint，但是在你的style.css中仍然有你的主题信息，给出两个世界的最好的。
优点
> passes sass-lint，因为没有任何sass文件包含形式/ * … * /的注释，因为主题头在style.css中不是style.min.css
>样式表的文件大小较小，因为style.min.css不再包含主题头信息，因为它存储在style.css中
>更好的网站性能：由于所有的SCSS文件都编译成一个CSS文件，发送到您的服务器的HTTP请求数量减少，从而提高您的整体网站性能。
缺点
>两个CSS文件。不是真的很多缺点，因为用户在前端只发送style.min.css，而不是style.css
>可能会混淆用户在wordpress社区。大多数wordpress用户希望你的样式是在style.css。但是，我怀疑这将是一个很大的问题(特别是如果你不发布你的主题)，也可以纠正一个简单的评论。
解决方案2
您的问题的另一个解决方案是临时禁用scss-lint注释规则使用以下：
// scss-lint:disable Comment /*! Theme Name: Twenty Thirteen Theme URI: http://wordpress.org/themes/twentythirteen Author: the wordpress team Author URI: http://wordpress.org/ Description: The 2013 theme for wordpress takes us back to the blog,and share what you've learned with others. */ // scss-lint:enable Comment p { font-size: 16px; }
还要注意使用大声评论(即/ *！… * /而不是/ * … * /)。这基本上意味着这个评论不应该在sass的缩小版本中删除。
优点
>一个CSS文件
>不太可能在wordpress社区中混淆用户
>通过sass-lint，因为注释规则被暂时禁用！
>更好的网站性能：(与解决方案1相同的原因)
缺点
>样式表的文件大小较大，因为编译的CSS文件包含主题头信息。这只是一个小的增加。
对不使用Sass或Grunt / Gulp的最终用户有什么影响？
从你提到的另一个评论，你说你希望用户能够更改小的东西，而不安装sass或构建自动化工具。
这并不意味着你不能使用构建自动化工具。它只是意味着你的编译的CSS文件从解决方案1或解决方案2，不应该缩小，因为用户不能轻易地编辑文件！不幸的是，这意味着您的网站将在文件大小更大，因此更慢。
或者，您可以有两个文件：
– website.min.css：编译SCSS的缩小版本
– website.css：编译SCSS的扩展版本
[再次，你愿意命名他们]
然后如果用户希望在没有sass或Grunt / Gulp的情况下进行快速更改，那么他/她可以这样做到website.css(然而，用户还需要更改在functions.PHP中加载的文件)
此外，经验丰富的用户谁有sass经验或用户不想做任何更改，不必妥协，因为他们仍然可以利用快速缩小的website.min.css版本的优势！
两全其美的！
