Kinsta主机部署Radicle开发WordPress完整教程

现代WordPress开发早已告别手动配置和混乱的部署流程。Radicle整合了Roots生态及其他主流WordPress开发工具（比如Bedrock、Sage、Acorn），打包成一套一站式启动套件。也就是说，只要在WordPress中直接获得Laravel级别的开发体验，就可以在保留WordPress的灵活性的同时又能用上现代化的开发工具链。

Kinsta主机支持SSH访问、集成WP-CLI工具，还能自定义网站根目录，部署Radicle能获得完美适配的托管环境。本文将详细讲解在Kinsta主机上配置并部署Radicle的完整步骤。

一、Radicle及其核心组件

Radicle整合了Roots旗下三个核心项目：

Bedrock：作为基础框架，优化了目录结构，采用Composer进行依赖管理；
Sage：负责主题开发，内置Tailwind CSS集成和Vite资源构建工具；
Acorn：打通WordPress和Laravel的壁垒，把Blade模板、数据库迁移、路由等Laravel核心功能引入WordPress项目。

这套开发环境可以直接在项目根目录工作，而不用局限于传统的主题文件夹：模板文件存放在项目根目录的“resources/views/“下，配置则通过“bedrock“目录中不同环境的专属文件管理。

Composer会通过一个“composer.json“文件统一管理WordPress核心程序、插件和自定义依赖。这套套件要求PHP 8.3及以上版本，还需要安装特定扩展；另外依赖管理需要Composer，命令行操作则需要WP-CLI工具。

二、Radicle与传统WordPress的区别

标准WordPress安装会把所有文件都放在“wp-content“目录下，让版本控制更复杂，而且很难在不同环境（开发、测试、生产）中保持一致的安装状态；而Radicle重新设计了目录结构，只对业务代码进行版本控制，不用跟踪WordPress核心文件或上传的媒体资源：

WordPress核心程序存放在“public/wp“目录，与业务代码完全分离；
“public/content“目录替代了传统的“wp-content“，自定义主题代码则放在项目根目录；
采用Laravel风格的“.env“环境变量配置，数据库信息、安全密钥不再硬编码到配置文件中。开发、测试、生产环境的不同设置，可通过“bedrock/environments/“目录下的专属文件定义。

这样一来，版本控制的效率会大大提升，只需跟踪自己的业务代码和配置文件，WordPress核心更新通过Composer完成，插件作为依赖管理，主题修改则存储在代码仓库中，避免了多环境同步的麻烦。

三、购买Kinsta主机

Kinsta是一家成立于2013年的美国主机商，提供网站性能、世界级的支持和强大MyKinsta仪表板，全球部署37个数据中心，Cloudflare集成，支持虚拟主机、WordPress主机、云主机、经销商主机等多种产品方案，支持无限制免费迁移、14天备份以及30天退款保证。

限时福利：Kinsta首月免费试用服务>>>

注意：免费月活动适用于Starter 35k和WP 2套餐，同时还能享受30天退款保证。注册时需要提供信用卡信息，但下个月才会扣费。

相关推荐：《Kinsta主机综合评测（定价/功能/特点/性能/速度）》

四、为Kinsta主机配置Radicle

部署到Kinsta时需要用到SSH密钥认证，在MyKinsta即可设置，非常方便。

进入网站的“信息”（Info）板块，找到SFTP/SSH访问详情；
如果还没添加过公钥，在这里上传你的SSH公钥即可。

Kinsta环境完全适配Radicle的技术要求：运行PHP8.3版本，预装Composer用于依赖管理，还有WP-CLI工具，能通过命令行直接管理WordPress。

和传统WordPress不同，Radicle采用“基于版本的目录结构”，每次部署都会创建一个带时间戳的版本文件夹，通过“current“符号链接指向当前活跃的版本。因此，网站的根目录需要设置为“public/current/public“。

1、配置环境变量

在Radicle项目根目录找到“.env.example“文件，复制一份并重命名为“.env“；

填入数据库信息和环境配置，示例如下：

DB_NAME=’your_database_name’
DB_USER=’your_database_user’
DB_PASSWORD=’your_database_password’
DB_HOST=’your_database_host’
WP_ENV=’staging’
WP_HOME=’https://{kinsta-staging-url}’
WP_SITEURL=”${WP_HOME}/wp”

Radicle把WordPress核心安装在“/wp“子目录下，这样能让核心文件与你的自定义代码彻底分离，让目录结构更清晰，也更利于版本控制。

2、测试环境配置

Radicle项目根目录下，“public“和“resources“文件夹旁边就是配置目录。打开“bedrock/environments/staging.php“，可定义测试环境的专属设置。只要“.env“文件中“WP_ENV“设为“staging“，这个文件的配置就会覆盖“bedrock/application.php“中的默认值。

在“staging.php“顶部添加以下常量，设置测试环境的网站地址：

<?php
define(‘WP_HOME’, ‘https://staging-url’);
define(‘WP_SITEURL’, WP_HOME . ‘/wp’);

测试环境地址可在MyKinsta后台的“环境”（Environments）板块中找到。

部署路径决定了文件在Kinsta服务器上的存放位置：

在MyKinsta的“环境详情”中查看部署路径，通常格式为“/www/网站名/public“；
部署脚本会把文件同步到这个路径下，每个部署会生成“/www/网站名/public/releases/时间戳“文件夹，“/www/网站名/public/current“则通过符号链接指向当前活跃的版本。

另外，建议在“bedrock/environments/staging.php“中开启调试模式（WP_DEBUG），方便排查问题。测试环境的数据库信息可以填在本地的“.env“文件中（这个文件不要提交到代码仓库），也可以在部署服务器上设置为环境变量，因为Kinsta会为每个环境生成独立的数据库凭证。

3、生产环境配置

在MyKinsta后台的环境下拉菜单中切换到生产环境后，配置流程和测试环境类似，但需要使用生产环境的专属参数和更严格的安全设置。

打开项目根目录“bedrock“文件夹下的“bedrock/environments/production.php“；

修改生产环境的网站地址：

<?php
define(‘WP_HOME’, ‘https://yourdomain.com’);
define(‘WP_SITEURL’, WP_HOME . ‘/wp’);

生产环境的错误处理和测试环境不同，需要关闭调试显示，但保留错误日志记录：

define(‘WP_DEBUG’, false);
define(‘WP_DEBUG_LOG’, true);
define(‘WP_DEBUG_DISPLAY’, false);
define(‘SCRIPT_DEBUG’, false);

生产环境的数据库凭证，可在MyKinsta生产环境的“数据库访问”（Database Access）板块中查看，这些凭证和测试环境通常不同；

生产环境的部署路径格式和测试环境一致，但指向的是正式环境的服务器目录，可在MyKinsta的“环境详情”中确认，部署脚本会把文件同步到这个路径下。

五、修改部署任务

Radicle的默认部署流程假设你能完全控制服务器，但Kinsta作为托管服务不会开放这些权限。因此需要移除部署任务中涉及服务器服务管理的部分。

1、移除PHP-FPM重载任务

如果使用Trellis（Radicle的默认部署工具），需要编辑“trellis/roles/deploy/hooks/finalize-after.yml“文件，把“Reloadphp-fpm”（重载PHP-FPM）任务彻底删除，Kinsta会在检测到文件变化时自动重启PHP-FPM，无需手动操作。

2、替换缓存清理方式

Kinsta的缓存清理通过API实现，而非服务器命令。因此需要把部署任务中基于服务器的缓存清理，替换为向Kinsta缓存清理接口发送HTTP请求：

先获取Kinsta提供的专属缓存清理接口（可联系Kinsta支持团队获取）；

在部署的最终钩子中添加以下任务（需先配置好API密钥）：

– name: Clear Kinsta cache
uri:
url: “{{ site_env.wp_home }}/kinsta-clear-cache-endpoint/”
method: GET

3、资源编译与依赖安装

在部署前完成，而非在服务器上执行。在本地开发机或CI/CD流水线中运行“npmrunbuild“，把JavaScript和CSS编译到“public/build“目录，编译后的资源会和PHP文件一起部署到服务器；
Composer依赖安装：文件同步到服务器后，通过SSH执行以下命令安装依赖：

cd /www/sitename/public/current
composer install –no-dev –optimize-autoloader –no-interaction

“–no-dev“：排除开发依赖（如测试框架、调试工具），减少服务器资源占用；
“–optimize-autoloader“：生成类映射，加快自动加载速度，降低请求时的类文件查找开销；
“–no-interaction“：自动执行安装。

六、向Radicle添加Kinsta MU插件

Kinsta MU插件能实现整页缓存、CDN集成，还能通过MyKinsta管理缓存。由于Radicle的目录结构比较特殊，需要设置一些专属配置常量，不过插件本身可以通过Composer安装。

安装与配置步骤：

1、通过Composer安装KinstaMU插件；

2、在“bedrock/application.php“文件中添加以下常量，解决目录结构不兼容的问题：

/**
* Kinsta CDN fix for Radicle/Bedrock structure
*/

define(‘KINSTA_CDN_USERDIRS’, ‘app’);

/**
* Fix Kinsta MU Plugins URL path with Radicle/Bedrock
*/

$mu_plugins_url = Config::get(‘WP_CONTENT_URL’) . ‘/mu-plugins’;

define(‘KINSTAMU_CUSTOM_MUPLUGIN_URL’, “{$mu_plugins_url}/kinsta-mu-plugins”);

第一个常量指定Bedrock结构中的上传目录；
第二个常量修正插件的资源URL路径，确保JavaScript和CSS文件能正常加载。

3、确认插件安装成功后，可通过MyKinsta后台测试缓存清理功能，验证插件是否能正常与Kinsta服务器通信。

七、设置自动化部署

GitHub Actions是实现Radicle自动部署到Kinsta的简单方案。可以在代码仓库中创建“.github/workflows/deploy.yml“工作流文件，当代码推送到特定分支时，自动触发资源构建和部署到对应环境（测试/生产）。

核心思路可以参考：通过GitHub仓库中存储的SSH密钥，建立与Kinsta服务器的安全连接；用部署脚本同步文件，同时排除无用文件；最后完成缓存清理和旧版本清理。

1、准备工作

在GitHub仓库中添加以下Secrets（密钥），用于SSH连接Kinsta服务器：

“SSH_PRIVATE_KEY“：你的SSH私钥；

“KINSTA_STAGING_HOST“/“KINSTA_PRODUCTION_HOST“：测试/生产环境的Kinsta服务器地址；
“KINSTA_STAGING_PORT“/“KINSTA_PRODUCTION_PORT“：测试/生产环境的SSH端口；
“KINSTA_STAGING_USER“/“KINSTA_PRODUCTION_USER“：测试/生产环境的SSH用户名。

2、GitHub Actions配置文件

在仓库根目录创建“.github/workflows/deploy.yml“文件，内容如下（含详细注释）：

name: Deploy to Kinsta
on:
push:
branches:
– staging
– main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
– name: Checkout code
uses: actions/checkout@v3
– name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: ’22’
– name: Install dependencies and build assets
run: |
npm ci
npm run build

矩阵策略可处理多个环境，而无需复制工作流代码。添加的特定于环境的变量可以根据触发工作流的分支进行更改：

strategy:
matrix:
include:
– branch: staging
ssh_host: ${{ secrets.KINSTA_STAGING_HOST }}
ssh_port: ${{ secrets.KINSTA_STAGING_PORT }}
ssh_user: ${{ secrets.KINSTA_STAGING_USER }}
deploy_path: /www/sitename_1/public
– branch: main
ssh_host: ${{ secrets.KINSTA_PRODUCTION_HOST }}
ssh_port: ${{ secrets.KINSTA_PRODUCTION_PORT }}
ssh_user: ${{ secrets.KINSTA_PRODUCTION_USER }}
deploy_path: /www/sitename_2/public

配置PHP环境，用于安装Composer依赖：

– name: Setup PHP
uses: server/setup-php@v2
with:
php-version: ‘8.3’

– name: Install Composer dependencies
run: composer install –no-dev –optimize-autoloader –no-interaction

八、通过rsync同步文件到Kinsta服务器

– name: Deploy to Kinsta via rsync
env:
SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
run: |
mkdir -p ~/.ssh
echo “$SSH_PRIVATE_KEY” > ~/.ssh/deploy_key
chmod 600 ~/.ssh/deploy_key
rsync -avz –delete \
–exclude=’.git’ \
–exclude=’node_modules’ \
–exclude=’.env’ \
–exclude=’trellis’ \
-e “ssh -i ~/.ssh/deploy_key -p ${{ matrix.ssh_port }} -o StrictHostKeyChecking=no” \
./ ${{ matrix.ssh_user }}@${{ matrix.ssh_host }}:${{ matrix.deploy_path }}/releases/$(date +%Y%m%d%H%M%S)/

其中.env文件包含跨部署持续存在的特定于环境的配置，存储在发布目录之外的上传将防止在删除旧发布时丢失媒体文件。而原子符号链接更新 (ln -nfs) 可确保零停机时间，因为请求永远不会达到半部署版本。

Cleanup在成功部署后删除旧版本，仅保留五个最新版本：

name: Clean up old releases
run: |
ssh -i ~/.ssh/deploy_key -p ${{ matrix.ssh_port }} -o StrictHostKeyChecking=no \
${{ matrix.ssh_user }}@${{ matrix.ssh_host }} << ‘EOF’
cd ${{ matrix.deploy_path }}/releases
ls -t | tail -n +6 | xargs rm -rf
EOF

此清理策略在磁盘空间利用率和回滚功能之间取得了平衡。五个版本提供了多个回滚点，同时防止了无限的存储增长。