inpsyde / vip-composer-plugin
一个 Composer 插件,用于简化将项目部署到 WordPress.com VIP 服务器,并支持基于 Composer 的开发。
Requires
- php: >=8.0
- composer-plugin-api: ^2.4
- ext-json: *
Requires (Dev)
- composer/composer: ^2.4
- inpsyde/php-coding-standards: ^2@dev
- phpunit/phpunit: ^9.6.17
- vimeo/psalm: ^5.23.1
This package is auto-updated.
Last update: 2024-09-12 12:41:53 UTC
README
此包是用于部署到 VIP Go 平台 的 Composer 插件,提供具有 两个不同目的 的 CLI 命令:
- 简化与 VIP Go 平台兼容的基于 Composer 的 本地环境
- 简化在 VIP Go 上的 自动部署
快速参考
此包提供了一个命令 composer vip
,可用于准备 本地环境 并部署到 VIP Go 仓库。
示例
composer vip --local # prepare local environment composer vip --deploy --branch="develop" # deploy to VIP Go repository
如上所示的部署命令需要在 composer.json
中进行一些配置,至少包括仓库的 GitHub URL,如果未在 composer.json
中指定,则可以通过 --git-url
选项传递给命令。
需要注意的是,composer vip
命令 必须在执行 composer install|update 之后运行。
以下是一条同时更新 Composer 依赖项和准备本地环境的单行命令:
composer update && composer vip
如果您第一次来到这里,建议阅读以下内容以更好地理解该命令的功能、方法和原因。
跳转到 命令参考 部分,以获取关于该命令及其可用选项的详细文档。
原因
VIP Go 平台是一个托管 WordPress 主机,允许通过向 GitHub 上托管的仓库提交 Git 提交来部署到其服务器。不同的分支意味着不同的环境,而 master
分支用于生产。
该仓库不包含完整的 WordPress 文件夹,而是 类似 于 /wp-content
文件夹。
类似 于,因为存在一些差异
- MU 插件不是保存在
mu-plugins
文件夹中,而是保存在/client-mu-plugins
文件夹中,因为mu-plugins
为平台始终存在的专有 MU 插件预留。 - 存在一个
/vip-config
文件夹,其中必须包含至少一个vip-config.php
文件,该文件从平台的wp-config.php
加载,是设置通常位于wp-config.php
中的常量的地方(由于无法访问整个安装的wp-config.php
,因此无法编辑)。 - 存在一个
/private
文件夹,其中包含无法通过浏览器访问的文件,但可以用于存储 PHP 可访问的数据、配置等。 - 存在一个
/images
浏览器可访问的文件夹,其中包含可用于网站的图片。 - 没有
/uploads
文件夹。所有媒体都存储在 CDN 上,并且不会出现在服务器文件系统中。
更多信息请参阅: https://vip.wordpress.com/documentation/vip-go/understanding-your-vip-go-codebase/
此外,如上所述,VIP Go 有许多 专有 MU 插件,始终会加载。
这意味着为了拥有一个可用于开发网站的本地环境,需要
- 安装WordPress
- 确保从
wp-config.php
加载vip-config/vip-config.php
- 安装所有VIP Go MU插件
更多信息请在此处查找: https://vip.wordpress.com/documentation/vip-go/local-vip-go-development-environment/
要拥有一个完全基于Composer的本地环境,其中插件、主题、库和WordPress核心都是通过Composer安装的,还需要执行额外的任务
- Composer自动加载器必须在请求引导的早期某个点加载
- 部署的Composer自动加载器不得包含开发依赖项
- 必须配置WordPress包(主题/插件/mu插件)的自定义安装路径,因为Composer安装器提供的标准路径是错误的(
/wp-content/...
) - 如果Composer需要任何MU插件,必须有一个“加载”机制,因为WordPress不会从子文件夹加载MU插件,而Composer会在子文件夹中安装MU插件。
该包的目的是使所有这些任务尽可能简单直接。
先决条件
对于本地开发,需要
- 某种能够运行PHP 7.2+和MySql的东西。无论是XAMPP、Mamp、Vagrant、Docker还是其他任何东西,都不是特别相关。
- 一个准备好的数据库用于网站
- 机器上可用的(更新后的)Git客户端,可通过
git
命令访问 - Composer
准备本地安装
本地环境中必须有一个文件夹专门用于项目。例如结构如下
详细结构
在上面的图像结构中,只有composer.json
和vip-config/vip-config.php
是必需的,所有其他文件夹/文件都是可选的。
/config
该配置文件夹将包含用于域名配置的YAML文件,如VIP Go文档中所述。
/images
此文件夹包含全站可用的图片,它是VIP Go代码库标准部分。
/mu-plugins
此文件夹包含特定于项目的MU插件。请注意,这些不是VIP Go MU插件,而是特定于项目的MU插件。
标准的Inpsyde流程需要为通过此存储库中的composer.json
拉取的每个插件/主题/库使用不同的存储库。然而,每个MU插件都是一个单独的PHP文件,通常由几行组成,将每个放入单独的存储库是过度设计的。这就是为什么存在/mu-plugins
文件夹的原因:该文件夹中包含的所有文件都将部署到client-mu-plugins
文件夹。
/private
此文件夹与VIP代码库中同名文件夹的作用相同。如VIP Go文档中所述,此文件夹的存在是为了包含由您的主题或插件访问的不是网页可访问的文件。典型用例是证书和密钥文件等。
请注意,VIP上的私有文件夹只可从PHP读取,不可写入。
/themes
此文件夹包含特定于项目的主题。
标准的Inpsyde流程要求为每个主题创建不同的仓库,然后通过composer.json
将它们组合在一起。然而,有时将主题(尤其是子主题)放入单独的仓库可能过于繁琐。这就是为什么可以使用/themes
的原因:其中包含的所有文件都将部署在VIP Go代码库的themes
文件夹中,与通过Composer需要使用的任何其他主题一起。
/vip-config
这是放置网站配置的地方。在VIP Go代码库中有一个对应的同名文件夹(在此处查看),它应该包含一个vip-config.php
文件,用于包含在“正常”安装中会放入wp-config.php
中的PHP配置常量,考虑到在VIP Go上无法访问。
/composer.json
“魔法”在这里发生。使用Composer来收集项目中将使用到的所有依赖项。
Composer配置
composer.json
相当标准。有一些事情必须考虑:
- 必须要求此插件,其名称为
inpsyde/vip-composer-plugin
- 可以使用对象
extra.vip-composer
来配置/自定义插件行为。这是完全可选的
。 - 必须使用
config.vendor-dir
来指定“客户端MU插件文件夹”,默认为vip/client-mu-plugins/vendor
(但外部文件夹名称,/vip
,可能会根据extra.vip-composer.vip.local-dir
的配置而改变)
所有可用的设置及其默认值如下所示
{ "config": { "vendor-dir": "vip/client-mu-plugins/vendor", "platform": { "php": "8.1" } }, "extra": { "vip-composer": { "vip": { "local-dir": "vip", "muplugins-local-dir": "vip-go-mu-plugins" }, "git": { "url": "", "branch": "" }, "wordpress": { "version": "^6.2", "local-dir": "public", "uploads-local-dir": "uploads" }, "plugins-autoload": { "include": ["*/*"] }, "dev-paths": { "muplugins-dir": "mu-plugins", "plugins-dir": "plugins", "themes-dir": "themes", "languages-dir": "languages", "images-dir": "images", "vip-config-dir": "vip-config", "config-dir": "config", "private-dir": "private" }, "custom-env-names": [ ] } } }
config
对象是Composer架构的一部分,而不是特定于此插件的。上述内容是为了完整性而显示的。将config.platform
设置为7.3
是因为在撰写本文时,VIP Go平台正在使用该版本,设置此值将有助于即使在本地运行不同的PHP版本时也能部署相同的依赖项。
因为所有vip-composer配置都是可选的
,如果上述内容对您来说足够好,无需添加任何配置
,因为这些默认值将在没有配置的情况下使用。
详细配置
vip-composer.vip
此插件提供的命令之一是创建一个文件夹,该文件夹反映了VIP Go仓库的结构。此文件夹将位于项目文件夹的根目录中。
vip-composer.vip.local-dir
配置控制该文件夹的名称。
此插件命令的另一个操作是下载VIP Go MU插件,并在本地WordPress安装中使用它们。
vip-composer.vip.muplugins-local-dir
配置控制这些MU插件将下载的文件夹名称(在项目根目录内)。
vip-composer.git
此对象控制VIP Go GitHub仓库的Git配置。如上图所示,默认设置是空的,这要求将URL和分支作为选项传递给composer vip
命令。
建议至少填写URL,以避免输入长命令。
注意:URL必须以HTTPS格式提供(因为更容易验证),即使命令(如果可能)将使用SSH与GitHub交互。
vip-composer.wordpress
当composer vip
命令运行以设置本地环境时,它会安装WordPress
。此配置对象控制要安装的目标位置和版本。
vip-composer.wordpress.version
控制已安装的版本。如果这是空的,插件将检查 require
对象以查看类型为 wordpress-core
的包的版本,并使用找到的第一个此类包的版本。此配置接受 Composer 包链接 所接受的任何格式,以及 "latest"
,以始终获取最新版本。
vip-composer.wordpress.local-dir
控制项目根目录内 WordPress 将安装的文件夹。注意,此文件夹(而不是项目根目录)必须在本地环境 Web 服务器中设置为 webroot。
vip-composer.wordpress.uploads-local-dir
控制项目根目录内 "uploads" 文件夹所在的位置。实际上,上传文件夹位于 WordPress 文件夹外部,以使 WordPress 文件夹可以完全替换而不丢失媒体。该插件命令将文件夹 符号链接 到 /wp-content/uploads
,这样 WordPress 就可以无问题地工作。
vip-composer.plugins-autoload
VIP 建议使用 wpcom_vip_load_plugin
函数通过代码加载插件(有关详细信息,请参阅 VIP 文档)。
摘录
我们建议从代码中加载插件。在代码中加载插件可以带来更多的控制和更一致的跨生产环境、非生产环境和本地开发环境。
默认情况下,此包创建了一个使用 VIP 建议的 wpcom_vip_load_plugin
通过代码加载插件的 loader MU 插件。
但是,在多站点安装中,可能希望在仅某些站点上激活某些插件,而通过 wpcom_vip_load_plugin
加载插件时不可能做到这一点。
多亏了 plugins-autoload
设置,可以选择哪些插件将通过允许列表(要自动加载的插件列表)或拒绝列表(不要自动加载的插件列表)自动加载。
如果没有任何设置,默认是“自动加载一切”。
要控制要包含的插件,可以列出它们,最终可以使用 *
作为通配符,例如。
{ "extra": { "vip-composer": { "plugins-autoload": { "include": [ "foo/some-package", "bar/*", "baz/something-*" ] } } } }
如果更容易从加载中排除包,可以使用 exclude
键。
{ "extra": { "vip-composer": { "plugins-autoload": { "exclude": [ "foo/some-package", "bar/*" ] } } } }
请注意
- 这仅适用于类型为 "wordpress-plugins" 的包,类型为 "wordpress-muplugins" 的包将始终加载。
- 按精确限定名称(供应商 + 名称的组合)列出的包将始终优先于 glob 模式。
- 如果没有限定名称匹配,模式将按其编写的顺序评估,因此可以尝试将“更通用的”匹配项放在最后。
- 如果同时提供了
include
和exclude
键,则忽略exclude
:任何匹配include
的包都将加载,其他任何包都不会。
vip-composer.dev-paths
如上所述在 准备本地安装 部分,项目文件夹根目录中可能有用于主题、插件、MU插件的文件夹,可以用于将这些内容包含在项目的同一存储库中,而无需使用单独的存储库。此外,还有如 config
、private
和 images
的文件夹,可以用于填充相关的 VIP 文件夹。
只有 config/vip-config.php
是必需的,其他文件夹及其内容是可选的。
vip-composer.dev-paths
控制这些文件夹的名称。默认名称与 VIP Go 存储库使用的名称相同,除了 mu-plugins/
被重命名为 client-mu-plugins/
。
vip-composer.custom-env-names
VIP 预期 WordPress 的配置(通常放置在 wp-config.php
文件中,例如包含机密信息的常量)应放置在 vip-config.php
文件中。为了帮助具有特定环境的设置,这个包支持多个文件来设置此类配置,其中每个文件都是特定环境的,并以环境名称命名。配置文件可以直接放置在 "网站仓库" 根目录下的 ./vip-config/
文件夹中,或者可以放置在具有 vip-composer-plugin-env-config
类型的单独 Composer 包中,该包的支持由这个包处理。在后一种情况下,默认情况下从包复制到网站配置文件夹的支持文件是那些以 WordPress 核心支持的环境命名的文件,包括:local.php
、development.php
、staging.php
和 production.php
,以及一个名为 all.php
的文件,旨在针对所有环境。考虑到 VIP GO 允许我们拥有更多环境或无论如何命名它们,可以通过 vip-composer.custom-env-names
配置扩展支持文件名的列表。
命令运行后的文件夹结构
假设默认配置和类似于在 准备本地安装 部分截图所示的文件夹结构,在运行后
composer update && composer vip --local
(并等待一段时间)项目文件夹的结构将是
上面突出显示的淡黄色命令创建的文件和文件夹。让我们列出它们
/public
这是 项目网站根目录,其中包含一个标准的 WordPress 安装。
注意:为了便于阅读,图中除了 index.php
(wp-load.php
、wp-login.php
等)之外的所有 WordPress 根文件都已删除。
/uploads
这个文件夹将包含所有在 WordPress 中本地上传的媒体文件。文件夹位于 /public
文件夹之外,以便后者完全可丢弃。然而,因为 /public
文件夹是网站根目录,所以 /uploads
文件夹是链接到 /public/wp-content/uploads
的符号链接,这是标准的 WordPress 上传文件夹,所以只要 WordPress(和 Web 服务器)关心上传就可以正确地提供。
对于 Linux 用户特别相关:确保文件夹可由本地 Web 服务器和 PHP 写入。
/vip
这个文件夹包含 与 VIP Go 仓库的精确 1:1 表示。它包含将推送到 VIP Go 仓库的项目中的所有文件。更多关于这个文件夹的内容将在下一节中介绍。
/vip-go-mu-plugins
这个文件夹包含 VIP Go MU 插件。在也生成的 wp-config.php
文件中,这个文件夹已经被配置为 WordPress 的 WPMU_PLUGIN_DIR
,以便本地 WordPress 可以正确加载所有 VIP MU 插件。
/composer.lock
Composer 锁文件。
熟悉 Composer 的人可能会想知道 Composer "vendor" 文件夹和 Composer 自动加载文件在哪里。
答案是:在 /vip/client-mu-plugins
内部。如上所述,/vip
文件夹包含将被推送到 VIP Git 仓库的精确内容,并且由于我们肯定需要在线使用 Composer 库和自动加载,所以需要它们在 /vip
文件夹中。
/wp-cli.yml
WP CLI 配置文件。它包含对 WordPress 安装路径的引用,因此可以从项目根目录执行 WP CLI 命令,而无需始终传递 --path
参数。
/wp-config.php
WordPress 的本地环境配置文件。这与 "标准" wp-config.php
略有不同,因为它包含
- 将
WPMU_PLUGIN_DIR
定义为指向 MU 插件的来源/vip-go-mu-plugins
。 - 一个加载
vip-config/vip-config.php
的require
语句,模拟在 VIP Go 中发生的情况
首次执行VIP Go Composer插件时,需要填写项目设置,例如数据库设置、nonce密钥等。
/vip
文件夹详细说明
让我们“放大”查看 /vip
文件夹
/client-mu-plugins
此文件夹包含 Composer /vendor
文件夹,包括 autoload.php
文件。这是一个“标准”的Composer供应商文件夹,它之所以位于此处,是因为在 composer.json
中添加了 config.vendor-dir
配置。
此文件夹还包含 所有 在 /mu-plugins
文件夹中可用的MU插件的副本。
最后,它包含由 composer vip
命令生成的MU插件 __loader.php
文件,该文件包含以下指令:
- 加载Composer自动加载文件
- 通过调用
wpcom_vip_load_plugin
函数强制通过Composer要求的插件激活,如 VIP文档 中建议的
/config
、/images
和 /languages
此文件夹包含位于根目录下同名文件夹中的任何文件的副本。在上述示例中,这些文件夹是空的,因为根目录下相应的文件夹是空的或根本不存在。
/plugins
此文件夹包含所有通过Composer要求的插件(在示例中只有一个),以及根目录下 /plugins
文件夹中任何插件的副本(在示例中该文件夹根本不存在)。
/private
此文件夹将包含根目录下 /private
文件夹中任何文件的副本(在示例中该文件夹根本不存在),以及一个 deploy-id
文件,该文本文件包含一个唯一的随机UUID,每个构建(因此每个部署)都是唯一的。它可以由应用程序代码使用,例如,通过破坏缓存,以确保每次部署时缓存都无效。
/themes
此文件夹包含所有通过Composer要求的主题(在示例中只有一个),以及根目录下 /themes
文件夹中任何插件的副本(在示例中有一个子主题)。
请注意,尽管这种方法受到支持,但 建议为主题使用单独的存储库,因为“开发路径”使用子文件夹存在问题,而主题总是以文件夹的形式出现。
请确保查看下面的 管理开发路径 部分,其中详细说明了此问题。
/vip-config
此文件夹包含根目录下 /vip-config
文件夹中任何文件的副本,至少包含所需的 vip-config.php
文件。
开发路径
在上述部分中已经提到,文件夹 /client-mu-plugins
、/config
、/images
、/languages
、/plugins
、/themes
和 /vip-config
,都可能包含位于软件包根目录中文件的副本。这样做的原因是为了使 /vip
文件夹成为将部署到VIP的精确的1:1表示,但这种方法有一些需要注意的问题。
请确保查看下面的 管理开发路径 部分,其中详细说明了此问题。
一个 .gitignore
示例
重要的是,需要将Composer和此插件生成的新文件都添加到 gitignore
中。
一个 .gitignore
的示例可能如下所示
/public/ /uploads/ /vip/ /vip-go-mu-plugins/ /wp-config.php
但请注意,这 不是 自动生成的。
本地开发工作流程
拥有一个运行良好的本地环境只是开发过程的开始。
开发工作流程将是
- 为每个需要在项目中使用的主题/插件/库创建一个新的仓库
- 将其推送到远程版本控制系统服务(GitHub、BitBucket、GitLab等)
- 将其添加到项目的
composer.json
文件中的依赖项 - 运行
composer update && composer vip --local
来更新依赖项并刷新本地环境
处理每个插件/主题/库的远程仓库可能过于繁琐,尤其是在开发的早期阶段。
使用Composer Studio进行本地开发
在开发过程中处理本地仓库会更好。有人提到,对于简单和/或特定项目的MU插件/插件/主题,可以使用“dev paths”作为作用域,但很可能需要处理需要生活在单独仓库中的包。
幸运的是,Composer支持“路径仓库”。
简而言之,Composer可以使用本地路径(甚至是相对路径)作为包的源版本控制系统仓库,这样就可以运行composer install
,将文件夹的内容安装得像任何其他远程托管包一样。
它的好处是,用作路径仓库的本地文件夹很可能是远程仓库的本地克隆,因此当在本地(多亏了路径仓库)最终确定和测试更改后,可以将它们推送到远程仓库以在线部署。
它的坏处是,使用路径仓库需要更改composer.json
,这不是一个选项,因为将本地路径放在推送到线上的composer.json
中没有意义。
为了解决这个问题,可以使用Composer Studio,这是一个Composer插件,允许使用Composer路径仓库而不更改composer.json
,而是使用一个单独的studio.json
文件,该文件可以轻松git忽略并保持本地。
命令参考
如最初快速编写的那样,此插件提供单个命令
composer vip
选项速查表
-
--local
- 告诉命令构建本地环境 -
--deploy
- 告诉命令准备用于生产的文件和文件夹,并将任何更改提交到VIP Go GitHub仓库,这实际上是在部署网站。 -
--git-url
- 设置从其拉取和推送到Git远程URL。当使用--local
时,此选项仅在同时使用--git
或--push
时相关。 -
--branch
- 设置从其拉取和推送到Git分支。当使用--local
时,此选项仅在同时使用--git
或--push
时相关。 -
--git
- 构建Git镜像文件夹,但不推送。与--local
一起使用。如果使用--deploy
,则忽略。 -
--push
- 构建Git镜像并将其推送。与--local
一起使用。如果使用--deploy
,则忽略。 -
--sync-dev-paths
- 同步本地开发路径。作为唯一选项使用。 -
--prod-autoload
- 生成生产自动加载。与--local
一起使用。假设如果使用--git
或vip-dev-env
。 -
--update-wp
- 强制更新WordPress核心。作为唯一选项或与--local
一起使用。如果使用--deploy
,则忽略。 -
--skip-wp
- 跳过WordPress核心的更新。与--local
一起使用。如果使用--deploy
,则忽略。 -
--update-vip-mu-plugins
- 强制更新VIP Go MU插件。作为唯一选项或与--local
一起使用。如果使用--deploy
,则忽略。 -
--skip-vip-mu-plugins
- 跳过 Vip Go MU 插件的更新。需要与--local.
结合使用。如果使用--deploy
,则会被忽略。 -
--vip-dev-env
- 准备vip dev-env
的环境。作为唯一选项使用。
详细说明
本地
--local
选项使命令执行一系列任务以准备和/或更新本地环境
- 如有必要,下载 WP 核心文件
- 如有必要,创建和配置
wp-config.php
- 如有必要,下载 VIP Go MU 插件
- 生成一个加载文件以要求 Composer 自动加载器以及从子文件夹中可能存在的 MU 插件
- 将 "content" 文件夹符号链接到 WordPress 安装目录
- 将 "dev paths" 复制到 VIP 文件夹
- 如有必要,创建和配置
wp-cli.yml
这是 默认选项,如果没有传递任何选项,则假定使用该选项。
部署
--deploy
选项使命令执行一系列任务以准备、同步和更新 VIP Go GitHub 仓库
- 将远程仓库克隆到临时文件夹
- 在此临时文件夹中替换所有需要部署的已更新文件,跳过不应更新的所有文件(例如,开发依赖项)
- 生成 "生产" 版本的 Composer 自动加载
- 将更改推送到远程仓库
使用此选项的命令非常适合在 CI 管道中运行。
Git 配置
有两个命令选项可用于配置 Git 操作
--git-url
- 设置从/推送到 Git 仓库的 URL。如果未提供,则从composer.json
中的extra.vip-composer.git.url
配置中获取值。如果没有此类配置,则 Git 同步将失败。--branch
- 设置从/推送到 Git 仓库的分支。如果未提供,则从composer.json
中的extra.vip-composer.git.branch
配置中获取值。如果没有此类配置,则 Git 同步将失败。
示例
composer vip --deploy --git-url="https://github.com/wpcomvip/my-project" --branch="develop"
本地环境的 Git 选项
默认情况下,当使用 --local
选项时,插件准备本地环境 完全不需要 考虑 Git。有时在实际上部署之前,查看使用 --deploy
会推送的 Git diff 可能是希望做的事情。
这可以通过 --git
选项实现。
当使用此选项时,插件在 /vip
中创建一个包含独特名称的文件夹,名称以点开头,例如 /.vipgit5b59852eb21c7
。
此文件夹将是一个 Git 仓库,由 VIP Go GitHub 仓库构建,其中已提交所有更改。因此,通过将 Git 客户端/工具指向此文件夹,可以“预览”推送前的更改。实际上,通过在此文件夹上运行 git push
,可以部署更改。
有时也希望通过本地环境直接推送更改。
这可以通过 --push
选项实现。使用 --local --push
与 --deploy
结合使用与仅使用 --deploy
不同之处在于,后者只会运行与 远程 服务器相关的任务(例如,始终跳过 WP 安装、VIP MU 插件下载等),因此它是从 CI 部署的良好选择。通过使用 --local --push
,命令将更新开发环境并且 还会 推送更改到远程仓库。
当使用 --git
或 --push
时,Git 配置(URL 和分支)的适用方式与使用 --deploy
时相同。
示例
composer vip --local --git --branch="develop"
管理 Dev Paths
关于此插件推广的文件夹结构似乎难以理解的事情之一是为什么在项目的根目录中存在 "dev paths"(插件、主题、配置以及 VIP Go 结构中的所有其他文件夹),并且相同的文件夹也被 复制 到 /vip
文件夹下。
原因相当简单。《/vip》文件夹的存在是为了成为VIP Go Git仓库的1:1镜像。
这意味着在使用Composer时,像/vip/plugins
这样的文件夹将包含通过Composer安装的插件。主题和MU插件也是如此。
如果出于任何原因,开发者想要使用同一个“项目”仓库来包含插件、MU插件和主题,而它们不在单独的仓库中,那么就意味着在通过Composer安装之后,/vip/plugins
(或/theme
或/client-mu-plugins
)将包含第三方依赖项和为项目编写的自定义包的“混合”。
因为后者肯定需要放在版本控制之下,而前者可能不需要,这就需要依赖于相当复杂(并且说实话难以维护)的.gitignore
配置。
通过使用单独的文件夹,如这些插件所做的那样,根目录中的文件夹只包含需要放在版本控制下的自定义工作,然后命令会负责将它们复制到适当的位置(多亏了插件中提供的自定义安装程序)。
这样,/vip
文件夹就可以完全被Git忽略,并且它也变得完全可丢弃的,这对自动生成的文件夹来说是个好事。
然而,这种方法也有两个问题。
第一个问题是根文件夹中的“开发路径”被“复制”到/vip
文件夹中,这意味着任何更改都要重新复制。.
这就是为什么插件命令提供了--sync-dev-paths
选项。
此标志必须作为唯一的标志使用,并使命令从根同步开发路径到/vip
。
示例
composer vip --sync-dev-paths
考虑到这是一个相当快速的操作,如果可能的话,使用IDE功能自动在“开发路径”内任何更改时运行上述命令是有意义的。
以下是使用PHPStorm通过“文件监视器”设置此配置的截图。
第二个问题涉及到在自身文件夹中的主题和插件。问题是,当从/themes
或/plugins
中删除自身文件夹中的主题或插件时,它不会从/vip/themes
或/vip/plugins
中删除。
例如,如果在/themes/my-theme
中有一个主题,它的文件将正确地与/vip/themes/my-theme
保持同步,只要/themes/my-theme
存在。然而,如果/themes/my-theme
被删除,/vip/themes/my-theme
将不会被删除。
这个问题不会影响单文件插件,例如位于/plugins/my-plugin.php
的插件将正确地与/vip/plugins/my-plugin.php
保持同步,如果/plugins/my-plugin.php
被删除,/vip/plugins/my-plugin.php
也将被删除。
因此,建议只将“开发路径”用于MU插件和简单的单文件插件,但对于主题(总是存在于自身文件夹中)或更复杂的插件,请使用单独的仓库。
强制或跳过WP下载
当使用--local
时,该命令执行的一件事是从官方发布zip文件(“无内容”版本)下载WordPress。
这发生在以下3种情况下:
- 第一次运行该命令(或任何情况下WordPress文件夹未找到)
- 在
composer.json
的插件配置中使用"latest"
作为版本要求,并且已经发布了一个新的(稳定)版本 - 在
composer.json
中的版本要求已更改(无论是在require
还是在插件配置中),并且当前安装的版本不满足新的要求。
这意味着即使有更新版本的WordPress发布,并且满足要求,但如果当前安装的版本也满足要求,则不会进行安装。
例如,如果要求是 4.9.*
,而安装的版本是 4.9.5
,但 4.9.7
可用,则使用 --local
选项时,WordPress 默认不会更新。
在这种情况下,可以通过使用 --update-wp
标志强制更新。
此标志可以与 --local
结合使用,表示 "更新本地环境,并在有新可接受版本时强制更新WP",或者它可以单独使用,表示 "仅更新WP,不更新其他内容"。
后一种用法很有价值,因为,如前所述,当使用此插件时,composer update
不会更新WordPress。
控制WordPress下载的另一个选项是 --skip-wp
。
此选项指示命令 永不下载WP。只能与 --local
结合使用。这在例如,版本要求设置为“最新”但希望节省下载和解压WordPress所需的时间(这可能需要一些时间,尤其是在慢速连接上)时很有用。
必须注意,如果WordPress文件夹不存在且使用 --skip-wp
,则本地安装将无法使用。
还值得一提的是,如果一起使用 --update-wp
和 --skip-wp
,则命令将失败。
示例
composer vip --update-wp
更新或跳过VIP Go MU插件下载
首次运行命令时,最耗时的任务是下载VIP Go MU插件。这些插件总共超过300 Mb,从一个具有 多个 递归子模块的仓库中拉取。
这就是为什么默认情况下,composer vip
命令仅在MU插件不存在时才下载它们。所以假设首次运行此命令,或者如果手动删除了文件夹。
然而,这些MU插件正在积极开发中,有时需要更新它们以与VIP Go服务器上的内容保持同步。
这可以通过使用 --update-vip-mu-plugins
标志来实现。
此标志可以与 --local
结合使用,表示 "更新本地环境,并在有新可接受版本时强制更新VIP Go MU插件",或者它可以单独使用,表示 "仅更新VIP Go MU插件"。
后一种用法基本上是
git clone --recursive git@github.com:Automattic/vip-go-mu-plugins.git
的别名
composer vip --update-vip-mu-plugins
但更短,更容易记忆。
控制Vip Go MU插件下载的另一个选项是 --skip-vip-mu-plugins
。
此选项指示命令 永不下载VIP Go MU插件。只能与 --local
结合使用。这在MU插件不存在(从未下载或手动删除)但出于任何原因希望节省下载它们所需的时间时很有用。
必须注意,如果MU插件不存在且使用 --skip-vip-mu-plugins
,则本地安装将无法使用。
还值得一提的是,如果一起使用 --update-vip-mu-plugins
和 --skip-vip-mu-plugins
,则命令将失败。
示例
composer vip --local --update-vip-mu-plugins
VIP开发环境
VIP开发环境使用 Docker 和 Lando 模拟VIP环境。
因此,虽然它是一个本地开发环境,但具有生产环境的多项特性。命令的 --vip-dev-env
标志执行准备 vip/
文件夹所需的全部步骤,包括生产自动加载,跳过下载WordPress核心或VIP MU插件等操作,因为这些由 vip dev-env create
命令处理。
示例
composer vip --vip-dev-env
vip dev-env create --app-code="./vip"
许可证和版权
VIP Composer 插件 是一款免费软件,遵循 MIT 许可协议发布。请参阅 许可证 以获取完整的许可证信息。
Syde 团队自2006年以来一直在进行网页工程。