README

一个最小的CMS。特性包括

• 默认从Markdown文件中提取内容，但你可以实现自己的源，从数据库、API或其他适当的来源提取
• 使用Flysystem获取文件，这意味着它们可以存储在本地并保持版本控制，或从S3存储桶、Dropbox文件夹或FTP服务器中提取
• 使用Twig进行模板设计
• 出厂配置了Laravel Mix和Tailwind
• 使用PublishingKit/Config进行简单配置 - 你可以用YAML、PHP数组或其他任何支持的配置机制进行配置
• 内置缓存，支持多个后端
• 支持多个Monolog日志记录器
• 使用Fuse.js进行搜索
• 插件系统（目前为实验性）

计划的功能包括

• 环境间的配置差异 - 例如，你的开发和生产环境可以使用不同的缓存后端
• 从配置动态生成表单
• 支持多种表单提交通知器，包括邮件、短信和webhook支持，以便轻松集成到您自己的系统中
• 从内容动态生成导航栏
• 支持分类

Chinstrap CLI

Chinstrap附带自己的命令行运行器，你可以像这样调用它

$ php statico

这将显示可用的命令。

管理员在哪里？

按照设计，Chinstrap默认不包含管理员界面。目的是优化开发者的工作流程，而不是网站所有者的工作流程，因此Markdown文件是管理内容的更好方式。

理论上，可以创建一个插件来添加管理路由，但到目前为止，源代码和文档界面不包括执行除读取内容之外的操作的能力。一旦发生变化，应该可以创建一个作为插件的行政界面。

我该如何设置它？

目前，它是一个单个网络应用程序，尚未准备就绪。

计划是在功能完成之后，将其分成两个仓库。 statico/core 将是 src/ 文件夹中的代码，将包含应用程序的代码。其余部分将构成 statico/template 的基础，它将是一个初始的样板文件，将 statico/core 作为依赖项拉入。希望构建新项目的用户将运行 composer create-project 命令以拉入 statico/template，这将为他们提供一个包含一些Twig视图、配置文件和基本引导的基本样板文件。目标是将尽可能多的内容保持在 statico/core 中，以便尽可能多的更新只需运行 composer update。

这个的预期用例是什么？

基本上，适合使用Chinstrap的理想网站符合以下标准

• 是宣传网站
• 主要由开发者维护（而不是网站所有者）

根据我的经验，许多这些网站是用Wordpress构建的，原因有两个

• Wordpress拥有大量的市场份额
• 据说，它有一个管理员界面，允许客户自己更新它

然而，根据我的经验，WordPress通常对许多非技术用户来说过于复杂，以至于管理任务最终落在开发者身上，他们必须应对一个不适合他们技能集的界面。

再加上WordPress（至少默认情况下）缺乏合适的模板语言和前端框架，将过多内容放在数据库中，并且没有正确设置以处理不同的环境，这无疑会带来大量的挫败感。此外，WordPress需要数据库，可能运行缓慢，且常常成为被利用的目标。

相反，Chinstrap为那些使用现代MVC框架（如Laravel）的开发者提供了一种更熟悉的流程。你将获得一个基本的样板代码以供开始，可以创建和定制自己的布局，以及添加JavaScript。内容可以本地存储，以便与网站的其他部分一起进行版本控制，便于轻松回滚，或者可以使用远程文件系统之一进行拉取。这可以允许一些更具创造性的工作流程，例如从Dropbox文件夹中拉取内容。

如果你拥有大量类似网站，Chinstrap可能适合你的需求。你可以在安装之间轻松复制布局和前端文件，内容文件可以是复制的，或者从同一个远程源拉取。同样，小型或相对简单的网站，这些网站不经常更改，也可能是一个很好的选择。

我该如何构建和安装插件？

Chinstrap插件的核心是其Plugin类。这个类必须实现Chinstrap\Core\Contracts\Plugin，该接口定义了一个单个的register()方法，该方法将在应用引导过程中被调用。插件所做的任何设置都必须在这个方法中完成，或者在其调用的方法或函数中完成。Plugin类由容器实例化，因此你可以在构造函数中使用类型提示来注入任何所需的依赖项。

实现你的插件后，它必须在你的项目中可用（要么在项目文件夹中，要么通过Composer拉取）。然后你可以在配置文件中注册它。例如，如果你使用YAML，你可以这样注册你的插件：

plugins:
  - My\Super\Awesome\Plugin

我将在某个时候创建一个用于构建Chinstrap插件的样板代码。