WinterCMS简介

认识Winter CMS
项目结构
- 目录结构
- Themes
- Plugins
- Modules
发展特点
常见问题

认识Winter CMS

Winter 是一个内容管理系统 (CMS)，其唯一目的是让您的开发工作流程再次变得简单。冬天是建立在框架, 利用长期支持 (LTS) 发布以确保项目的稳定性。

一切都应该尽可能简单，但不能更简单
（阿尔伯特·爱因斯坦，转述）

项目结构

Winter CMS 项目的代码通常可以作为三种不同类型的扩展之一存在；作为一个Theme,Plugin，或者Module.代码也可以以由管理的外部依赖项的形式包含Composer.

目录结构

📂 MyWinterProject
 ┣ 📂 bootstrap         <-- Code used to bootstrap the application
 ┣ 📂 config            <-- Configuration files for the application
 ┣ 📂 modules           <-- Modules
 ┣ 📂 plugins           <-- Plugins
 ┣ 📂 storage           <-- Local storage directory
 ┣ 📂 tests             <-- Automated tests
 ┣ 📂 themes            <-- Themes
 ┣ 📂 vendor            <-- Vendor files managed by Composer
 ┣ 📜 artisan           <-- CLI entrypoint
 ┣ 📜 composer.json     <-- Composer project file (managing dependencies)
 ┣ 📜 composer.lock     <-- Composer lock file (info on currently installed packages)
 ┣ 📜 index.php         <-- Web request entrypoint
 ┣ 📜 phpunit.xml       <-- PHPUnit configuration for unit test
 ┗ 📜 server.php        <-- Embedded server for ease of development

Themes

Themes 包含前端代码、资产和功能以及静态站点内容。

查看主题页面查看目录结构的示例。

主题是基于平面文件的，但也可以通过数据库模板功能以及主题日志特征。

主题由 CMS 模块管理，这是 Winter CMS 中的默认前端体验。然而，它不是必需的模块，因此如果需要，完全可以不在项目中包含 CMS 模块，而是使用自定义插件让 Winter 充当无头 CMS，或者根本不提供前端并仅将 Winter 用于它的后端功能（用于更复杂的、以数据为中心的应用程序，如内部工具或 SaaS 产品）。

使用的语言：

INI 是用来模板配置
PHP用于通过添加更复杂的逻辑PHP代码部分
Twig 是用来模板功能和条件.
HTML、CSS、JS、SCSS/SASS、LESS 等；可以根据需要在前端主题中使用任何其他前端语言。

Plugins

插件是通过扩展向 Winter CMS 添加新功能的基础。注册过程允许插件声明它们的特性，例如components 或后端菜单和页面。插件可以做什么的一些例子：

定义components.
定义用户权限.
添加设置页面,菜单项,lists 和forms.
创造数据库表结构和种子数据.
改变核心或其他插件的功能.
提供课程，后端控制器、视图、资产和其他文件。

查看插件页面查看目录结构的示例。

Modules

Winter CMS 中的模块可以被认为是“核心插件”。 Winter CMS本身由以下三个模块组成：

System，用于引导 Winter 并提供 Winter 运行所需的所有其他模块和插件使用的通用服务。
Backend，为 Winter 及其所有相关服务、控制器和插件使用的其他功能提供后端。
CMS, 为 Winter 及其主题使用的所有相关服务提供默认前端。

模块有一个 ServiceProvider 类来处理启动和注册，然后可以包含插件中存在的任意数量的其他功能。虽然可以开发和使用您自己的自定义模块，但大多数时候确实没有必要，因为插件能够执行自定义模块能够执行的任何操作，同时提供更好的版本文件体验和插件管理功能内置于系统和后端模块。

在 Winter CMS 中存在的三个模块中，只有系统模块是 Winter 在基本级别运行所必需的。完全有可能（并且在许多Winter项目中积极完成）仅使用后端模块操作;通常用于复杂的、数据量大的用例、“内部网”类型的内部工具和 SaaS 类型的产品。虽然也可以只使用 CMS 模块来运行 Winter，但这不太有用，因为后端模块才是 Winter 真正提供很多价值的地方。

发展特点

Winter CMS 提供了许多开箱即用的功能，使开发更加容易。为了更容易发现，下面列出了其中的一些。

AJAX 架构

这AJAX 架构在 CMS 前端和后端都可用。请求由处理服务器端 PHP 代码并返回响应。响应可以包括呈现部分（提供动态内容）、验证信息或任何自定义数据。有一个data-attributes 应用程序接口可用于使用它以及JavaScript API 使用 jQuery。

AJAX 框架用于内部Components,Controllers 和Widgets.

动态内容解析器

这动态内容解析器是 Winter CMS 独有的模板引擎，用于在模板本身内指定动态内容字段。它有两种模式，编辑器（生成用户为模板提供自定义内容所需的字段）和视图（使用用户提供的内容填充模板）。

这个模板引擎可以在其他模板引擎之上使用，但主要与 Twig 一起使用。它可用于生成后端当前支持的任何类型的字段。动态内容解析器提供了制作可由客户端控制的完全可定制和复杂内容页面的能力。

前端组件

Components 是后端功能和前端内容之间的主要管道，用于布局、页面和部分。它们将交互和动态内容生成作为结构化“对象”处理，包括处理所有功能的 PHP 文件，前端内容的默认部分，以及任何其他 JS 或 CSS 资产。它们可以提供可配置的属性来设置组件的各个方面，通过后端进行控制。

主题可以覆盖组件的部分根据自己的规格定制组件输出。

资产编译器

Winter CMS 包括一个服务器端资产编译器这利用了资产框架通过 PHP 编译和组合 CSS 和 JavaScript 服务器端等资产，无需复杂的构建工作流程。 Asset Compiler 提供 SASS 和 LESS 样式表的即时服务器端编译，以及一次性手动编译资产无需额外的工作流工具，如 Node 或 NPM。它还能够合并和缩小 CSS 和 JS 文件。

此外，您可以在 theme.yaml 文件中定义变量可以在后端的主题设置区域进行修改，然后将其注入编译文件，为主题和品牌创建灵活性。

图片大小调整

这图片大小调整服务可用于调整应用程序可访问的任何图像资源的大小。

它的工作原理是接受各种图像源并规范化管道以存储所需的调整大小配置，然后推迟图像的实际调整大小直到浏览器请求。当调整大小路由被命中时，配置从缓存中检索并用于生成所需的图像，然后重定向到生成的图像静态路径以最小化服务器上的负载。

图像的未来加载会自动指向调整大小图像的静态 URL，甚至不会点击调整器路由。

行为和动态类扩展

在 Winter CMS 中，可以动态扩展大多数类的构造函数以添加新的属性和方法。这也让绑定到本地事件只出现在特定的对象实例上而不是全局的。

动态类扩展提供了以下好处：

动态添加新的属性和方法。
绑定到在模型、小部件和其他位置触发的本地事件，甚至是核心模块或其他插件中的事件。
向类添加额外的行为（私有特征，见下文）。
必须延长Winter\Storm\Extension\Extendable 类或实现Winter\Storm\Extension\ExtendableTrait.
不能覆盖已经定义的方法和属性。
可扩展类受到保护，不会在首次使用时设置未定义的属性，并且必须使用$object->addDynamicProperty();反而。
动态添加的方法不能覆盖代码中定义的方法。

请参阅下面的示例，了解动态类扩展的可能性：

// Dynamically extend a model that belongs to a third party plugin
Post::extend(function($model) {
    // Bind to an event that's only fired locally
    $model->bindEvent('model.afterSave', function () use ($model) {
        if (!$model->isValid()) {
            throw new \Exception("Invalid Model!");
        }
    });

    // Add a new property to the class
    $model->addDynamicProperty('tagsCache', null);

    // Add a new method to the class
    $model->addDynamicMethod('getTagsAttribute', function() use ($model) {
        if ($model->tagsCache) {
            return $model->tagsCache;
        } else {
            return $model->tagsCache = $model->tags()->lists('name');
        }
    });
});

动态类扩展还增加了类的能力私人特质, 也被称为Behaviors.这些类似于原生 PHP 特性除了它们有一些明显的好处：

行为有自己的构造函数。
行为可以有私有或受保护的方法。
方法和属性名称可以安全地发生冲突。
为跨控制器共享功能提供安全机制，同时仍保持其自身状态。
类可以动态扩展行为。

行为力量的最好例子是后端form,list，和relation ControllerBehaviors 在 Winter CMS 中为实现它们的任何控制器提供大部分 CRUD 要求。

常见问题

由于 Winter 是一个旨在满足世界各地从事各种不同项目的开发人员需求的项目，我们有时会做出从希望在 Winter 上构建的单个项目的角度来看并不明显的决定。本节应提供一些背景信息，介绍在项目生命周期内做出的决策中最常见的一些问题。

为什么选择 Laravel？

这Laravel 文档有一个很好的部分说明为什么应该使用它；但基本上这一切都归结为这样一个事实，即它是可用的对开发人员最友好的 PHP 框架，更不用说最大的 PHP 框架和最大的第三方包集合了。

为什么选择 Laravel LTS？

冬天是基于关闭Laravel LTS 版本确保我们所有用户的整个平台的稳定性。过去，Laravel 有时会在 LTS 版本之间的中间主要版本中引入重大更改。虽然这对框架的开发非常有用，但 Winter CMS 以其稳定性和可靠性而自豪。这意味着每当升级 Winter CMS 所针对的 Laravel 核心版本时，Winter CMS 开发团队都会投入大量时间来尽可能地平滑重大更改，并将详细的、针对性强的迁移指南放在一起，使更新过程轻而易举。

因此，为了降低核心 Winter CMS 开发团队和我们的最终用户的维护负担，Winter CMS 仅针对 Laravel 的 LTS 版本。这通常不是问题，因为所有第一方 Laravel 包都支持 LTS 版本以及大多数第三方包生态系统。

为什么是 Twig 而不是 Blade？

Winter CMS 使用Twig 作为默认的模板引擎，尽管Blade 作为 Laravel 提供的模板引擎。

在基本层面上，所有模板引擎都是相同的。然而，Winter 决定使用 Twig，因为它是一种健壮且成熟的模板语言，易于学习，在其他项目中广泛使用，并且与Liquid, 使用的模板引擎Shopify.这些因素结合起来意味着 Twig 更容易为大多数开发人员挑选和开始使用，而不需要任何现有的 PHP 或 Blade 知识，这意味着更广泛的开发人员群体可以更轻松地使用 Winter CMS。

此外，Blade 受到与 Laravel 本身在主要版本之间引入的相同的重大更改的影响，虽然模板引擎中的重大更改可能适用于为一次性项目设计的 Web 应用程序框架，可以轻松更新其视图文件以及它们的基础框架版本升级期间的逻辑文件；它完全不符合 Winter 提供稳定基础以构建长期项目的要求。更新您的 CMS 需要您对前端进行更改，这根本不是我们希望提供的开发人员体验。

虽然理论上可以让您的 Winter CMS 项目使用 Blade 来呈现模板，但这不是推荐的方法，因为前端使用单个模板引擎以确保所有主题和插件之间的最大兼容性很重要。

同样对于历史背景，在做出决定时，Blade 并没有今天拥有的许多更高级的功能，而这些功能（例如组件）自 2014 年创建以来就存在于 Winter CMS 中。

WinterCMS简介

#认识Winter CMS

#项目结构

#目录结构

#Themes

#Plugins

#Modules

#发展特点

#AJAX 架构

#动态内容解析器

#前端组件

#资产编译器

#图片大小调整

#行为和动态类扩展

#常见问题

#为什么选择 Laravel？

#为什么选择 Laravel LTS？

#为什么是 Twig 而不是 Blade？