WordPress 中的 Sass [英] Sass within WordPress

查看：27
本文介绍了WordPress 中的 Sass的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我想在我的一个 wordpress 项目中使用 SASS(这将是未来项目的样板).我希望以遵循以下标准的方式执行此操作:

  • 通过 sass-lint
  • 遵循 Wordpress 标准(例如主题标题)
  • 干净、一致和易于维护

我有一些想法，但没有一个符合上述标准.

1.删除 style.css 并单独使用 Sass

/index.php/... 其他 wordpress 文件.../assets/sass/main.scss/assets/sass/... 其他 sass 文件...

运行sass后，style.css会在根目录下创建.

优点:

  • 一致性
  • 易于维护

缺点:

  • SCSS-Lint 不喜欢WordPress 主题标题注释"，因为它更喜欢 // 注释
  • 不编译 sass 就不可能在 WordPress 后端选择主题

2.同时使用 style.css 和 Sass

/index.php/style.css/...其他 wordpress 文件.../assets/sass/main.scss/assets/sass/... 其他 sass 文件...

优点:

  • 基本上解决了(1)的缺点
  • 即使不应该那样；无需任何工具即可轻松将快速更改添加到 style.css 中

缺点:

  • 不一致
  • 冗余
  • 需要多个 CSS 请求(一个用于 style.css，一个用于编译的 sass)

这里我最大的问题是:把编译好的 SASS 放在哪里?将它与 style.css 连接起来似乎很奇怪.

有什么想法吗?谢谢！

解决方案

为什么我们需要style.css"?

在给出我的解决方案之前，我认为了解我们在 Wordpress 中需要 style.css 的原因很重要

在 Wordpress 中，需要 style.css 文件才能在后端中查看主题信息.

style.css 也用作 get_stylesheet_uri() 的默认输出.但是，这可以使用 stylesheet_uri 过滤器进行自定义.

在我看来，Wordpress 强制您将主题信息放在 style.css 中这一事实只是糟糕的设计，因为它增加了大约 1032 个字节.这不是很多，但完全没有必要；尤其是在可以避免的情况下，因为文件大小可能是影响网站性能的最大因素.

这与 Drupal CMS 不同，在 Drupal CMS 中，您的主题信息存储在一个单独的文件中，例如 yourtheme.info，因此永远不会暴露给最终用户

<小时>

解决方案 1

现在我们解决了这个问题，这是解决方案！

我认为最好的方法是:

  • 使用导入和部分将所有 sass 文件编译为一个文件(例如 style.min.css)(请参阅 http://sass-lang.com/guide#topic-5).随意命名其他名称.
  • 将所有 wordpress 主题标题留在 style.css 中.

例如像这样:

style.css

/*主题名称:二十十三主题 URI:http://wordpress.org/themes/twentythirteen作者:WordPress 团队作者 URI:http://wordpress.org/描述:2013 年的 WordPress 主题将我们带回了博客，它具有全方位的帖子格式，每种格式都以自己独特的方式精美地展示.版本:1.0许可证:GNU 通用公共许可证 v2 或更高版本许可证 URI:http://www.gnu.org/licenses/gpl-2.0.html标签:黑色、棕色、橙色文本域:二十三用它来制作一些很酷的东西，玩得开心，并与他人分享你学到的东西.*/

style.min.css

p{color:red;}h1{color:blue;} ...

然后，您可以使用 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 了解更多信息信息

因此，当您在文档的 head 中运行 wp_head() 时，它会自动添加正确的 CSS 文件.

然后你可以在你的 sass 文件上运行 sass-lint，但仍然在你的 style.css 中包含你的主题信息，从而两全其美.>

优势

  • 通过 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 注释/*!主题名称:二十十三主题 URI:http://wordpress.org/themes/twentythirteen作者:WordPress 团队作者 URI:http://wordpress.org/描述:2013 年的 WordPress 主题将我们带回了博客，它具有全方位的帖子格式，每种格式都以自己独特的方式精美地展示.版本:1.0许可证:GNU 通用公共许可证 v2 或更高版本许可证 URI:http://www.gnu.org/licenses/gpl-2.0.html标签:黑色、棕色、橙色文本域:二十三用它来制作一些很酷的东西，玩得开心，并与他人分享你学到的东西.*///scss-lint:启用注释p{字体大小:16px；}

还要注意大声评论的使用(即/*! ... */ 而不是/* ... */).这基本上意味着不应在 sass 的缩小版本中删除此注释.

优势

  • 一个 CSS 文件
  • 不太可能混淆 Wordpress 社区中的用户
  • 通过sass-lint，因为评论规则暂时禁用！
  • 更好的网站性能:(与解决方案 1 的原因相同)

缺点

  • 更大的文件大小用于样式表，因为编译后的 CSS 文件包含主题标头信息.然而，这只是小幅增长.

不使用 Sass 或 Grunt/Gulp 的最终用户呢?

从你提到的另一条评论中，你说你希望用户能够在不安装 sass 或构建自动化工具的情况下更改小东西.

这并不意味着您不能使用构建自动化工具.这只是意味着您从解决方案 1 或解决方案 2 编译的 CSS 文件不应缩小，因为用户无法轻松编辑文件！不幸的是，这意味着您的站点的文件大小会大得多，因此速度会变慢.

或者你可以有两个文件:

  • website.min.css:编译后的 SCSS 的缩小版
  • website.css:编译后的 SCSS 的扩展版本

[再次，随意命名]

那么如果用户希望在没有 sass 或 Grunt/Gulp 的情况下进行快速更改，那么他/她可以在 website.css 中这样做(但是，用户还需要更改在 functions.php) 中加载

此外，有 sass 经验的用户或不想进行任何更改的用户不必妥协，因为他们仍然可以利用快速缩小的 website.min.css 版本！

两全其美！

I'd like to use SASS in one of my wordpress projects (which will be kind of a boilerplate for future projects). I wish to do this in a way that follows the following criteria:

  • Passess sass-lint
  • Follows Wordpress standards (e.g. theme headers)
  • Clean, Consistent & Easy to maintain

I had a few ideas, but none of them follows the above criteria.

1. Remove style.css and solely use Sass

/index.php
/... other wordpress files ...
/assets/sass/main.scss
/assets/sass/...other sass files...

After running sass the style.css will be created in the root directory.

Pros:

  • Consistency
  • Easy to maintain

Cons:

  • SCSS-Lint doesn't like the "WordPress theme header comment", since it prefers // comments
  • Without compiling sass it's impossible to select the theme in the WordPress backend

2. Use the style.css and Sass simultaneously

/index.php
/style.css
/...other wordpress files...
/assets/sass/main.scss
/assets/sass/... other sass files...

Pros:

  • Basically solves the cons of (1)
  • Even it shouldn't be that way; quick changes can be easily added to the style.css without any tools

Cons:

  • Inconsistency
  • Redundancy
  • Requires multiple CSS requests (one for style.css, one for the compiled sass)

Also my biggest problem here is: where to put the compiled SASS? Concatenating it with the style.css seems fairly odd.

Any ideas? Thanks!

解决方案

Why do we need "style.css"?

Before I give my solution, I think it's important to go through the reason we need style.css in Wordpress

In Wordpress, the style.css file is required in order to view the theme information in the backend.

style.css is also used as the default output of get_stylesheet_uri(). However this can be customised using the stylesheet_uri filter.

In my opinion, the fact that Wordpress forces you to have your theme information in style.css is just bad design, as it adds approximately 1032 bytes. This is not a lot, but completely unnecessary; especially if it can be avoided, as the file size is perhaps the biggest factor impacting site performance.

This is unlike the Drupal CMS where your theme infomation is stored in a seperate file such as yourtheme.info, so is never exposed to the end user

Solution 1

Now we got that out the way, here is the solution!

The best approach in my opinion would be to:

  • Compile all your sass files into a single file (such as style.min.css), by using imports and partials (see http://sass-lang.com/guide#topic-5). Feel free to name it something else.
  • Leave all your wordpress theme headers in style.css.

For example like so:

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;} ...

You can then make sure that the new stylesheet in added on every page of the frontend using the following code in your functions.php file:

function theme_name_stylesheets() {
    wp_enqueue_style('style-name', get_template_directory_uri() . '/style.min.css');
}

add_action( 'wp_enqueue_scripts', 'theme_name_stylesheets' );

See: https://codex.wordpress.org/Function_Reference/wp_enqueue_style for more infomation

Thus when your run wp_head() in your head of your document, it will add the correct CSS file automatically.

Then you can run sass-lint on your sass files, but still have your theme information in your style.css, giving the best of both worlds.

Advantages

  • Passes sass-lint, as none of the sass files contains comments of the form /* ... */, as the theme headers are in style.css NOT style.min.css
  • Smaller file size for the stylesheet, as the style.min.css no longer contains the theme header information, as this is stored in style.css
  • Better site performance: As all your SCSS files are compiled into a single CSS file, the number of HTTP requests sent to your server reduces, thus improving your overall site performance.

Disadvantages

  • Two CSS files. Not really much of a disadvantage, as the user on the front-end is only sent the style.min.css, NOT the style.css
  • Can confuse users in the Wordpress community. Most Wordpress users expect your styles to be in style.css. However, I doubt this will be much of a problem (especially if you're not publishing your theme) and also can be rectified by a simple comment.

Solution 2

Another solution to your problem is to temporarily disable the scss-lint Comment rule using the following:

// 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, 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.
*/
// scss-lint:enable Comment
p {
  font-size: 16px;
}

Also note the use of loud comments (i.e. /*! ... */ instead of /* ... */) . This basically means that this comment should not be removed in the minified versions of sass.

Advantages

  • One CSS file
  • Less likely to confuse users in the Wordpress community
  • Passes sass-lint, as the comment rules is temporarily disabled!
  • Better site performance: (same reason as Solution 1)

Disadvantages

  • Larger file size for the stylesheet, as the compiled CSS file contains the theme header information. This is only a small increase however.

What about end-users who are not using Sass or Grunt/ Gulp?

From another comment you mentioned, you said you want users to be able to change minor things without installing sass or a build automation tool.

This does not mean that YOU can't use a build automation tool. It just means that your compiled CSS file from solution 1 or solution 2, should not be minified, as users cannot easily edit the file! Unfortunately, this means your site will be a lot larger in file size and thus slower as a result.

Alternatively you can have two files:

  • website.min.css: the minified version of the compiled SCSS
  • website.css: the expanded version of the compiled SCSS

[Again, name them as you wish]

Then if the user wishes to make quick changes without sass or Grunt/ Gulp, then he/she can do so to website.css (however, the user also needs to change the file that is being loaded in functions.php)

Also, experienced users who DO have sass experience or users who don't want to make any changes, don't have to compromise, as they still can take advantage of the fast minified website.min.css version!

The best of both worlds!

这篇关于WordPress 中的 Sass的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
前端开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆