SEO与分析功能集成方案

太长不看版

在 Kickoff 中交付了搜索引擎优化与分析的基础功能：元数据/开放图谱协议、规范链接、JSON-LD 组织结构化数据、动态 robots.txt、站点地图，以及可在管理后台编辑的谷歌分析4/谷歌标签管理器。
保持代码整洁的关键技巧：在应用启动时，将存储在数据库中的设置叠加到 config('seo.*') 之上，因此所有视图都读取配置，而没有任何地方直接读取设置类。
单一事实来源：首次启动时使用 .env 文件，之后通过管理用户界面进行配置。测试断言针对的是配置开关，而非数据库。

向应用程序添加谷歌分析通常只需一行代码。麻烦往往随后出现：你希望管理员无需重新部署即可更改谷歌分析4 ID，希望 .env 在全新安装时仍能提供合理的默认值，并且不希望一半的 Blade 视图去访问设置模型，而另一半却读取 config()。今天，我将所有这些整合到了 Kickoff 中，这种模式值得借鉴。

问题：两个事实来源

存储在数据库中的设置（Spatie 的 laravel-settings）和存储在 config/*.php 中的配置，一旦你在视图中同时读取两者，就会立即产生不一致。结果是一个局部视图中使用 config('seo.google.analytics_id')，而另一个局部视图中使用 app(SeoSettings::class)->google_analytics_id，此时在管理面板中的更改只会更新其中一处，而另一处保持不变。

解决方案是选择唯一的读取路径。我选择了 config()。

桥梁：在启动时将设置叠加到配置之上

config/seo.php 保存来自 .env 的首次启动默认值。然后，AppServiceProvider::boot() 将数据库设置叠加在其上，因此在任何视图渲染时，config('seo.*') 已经反映了管理员的编辑内容：

private function applyDatabaseSettings(): void
{
    try {
        $seo = app(SeoSettings::class);
        config([
            'seo.meta.description'      => $seo->meta_description,
            'seo.canonical'            => $seo->canonical_enabled,
            'seo.google.analytics_id'  => $seo->google_analytics_id,
            'seo.google.tag_manager_id'=> $seo->google_tag_manager_id,
            'seo.organization.name'    => $seo->organization_name,
            // ...
        ]);
    } catch (\Throwable) {

免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。

管理员可编辑的搜索引擎优化与分析功能，无需修改 .env 文件

太长不看版

问题：两个事实来源

桥梁：在启动时将设置叠加到配置之上