Zend Framework 1 应用程序中的缓存破坏静态资产

Question

在带有 node.js、模块捆绑器、任务运行器等的“现代”Web 应用程序的美丽新世界中，我感到非常迷茫和愚蠢。

我有一个可用的 Zend Framework (ZF 1) PHP 应用程序（它还嵌入了 WordPress 多站点，允许用户创建自己的博客站点）。它托管在带有 mod_php 的 Apache 服务器上。它在表单和数据显示中使用了相当多的 html 表格，但幸好不是用于整个页面布局，尽管 css 是基于 1000 像素的固定宽度页面。

应用程序在 JavaScript 应该仅用于“渐进式增强”的概念下开始开发，尽管最终我们屈服于要求启用 javascript 以获得正确的行为。我们支持通过多个提供商（Facebook、Google、LinkedIn、Twitter 等）使用 OAuth2 身份验证进行注册和登录，但只能通过服务器流而不是 javascript SDK。我们使用 jQuery 和数量有限的 Zend_Dojo javascript 库以及一些自产的 javascript 函数（除了 WordPress 使用的任何东西）。

我们最近在原始 Apache 网络服务器前添加了一个 Nginx 反向代理。它托管我们的 ssl 证书并提供静态文件资产。

现在，我们正在寻求采用更具响应性的设计，以更好地适应移动设备和平板电脑用户，并思考渐进式网络应用。因此，对 css 的重大更改和对 javascript 的使用的增加都在计划之中。尽管 Nginx 提供的静态资产为我们提供了 eTags，但 Google Page Speed Insights 告诉我们，我们阻止了 javascript 和 css 资源的下载，并且我们没有利用浏览器缓存。

从我看到的各种文章中可以看出，Webpack 捆绑工具可以为解决所有这些性能瓶颈提供重要帮助。但就我的一生而言，我看不出它如何适应这个生态系统。我的网站工作原理的心智模型是，http 查询由 PHP 代码分析，发送到访问会话数据和我们的 MySQL 数据库的 PHP 操作例程，然后通过包含嵌入式 PHP 的 phtml 模板（ZF1 视图脚本）输出 html标签。 phtml 模板可能包含<script>、<style> 和<img> 标签，这些标签可以直接包含，也可以由其他管理整个页面布局及其<header> 部分内容的PHP 函数注入到html 中。

但是当我查看 Webpack 时，它似乎期待某种 顶级 javascript 文件，它可以通过 import 或 @ 从中构建其他 javascript 和 css 文件的依赖关系树987654327@ 指令之类的。它以某种方式支持缓存清除，方法是对静态资产文件的内容进行哈希处理，从文件名中嵌入哈希值创建新文件，并编辑对这些文件的引用以包含哈希值。但是对于这个应用程序，所有对 javascript、css 和图像文件的引用都出现在 .phtml 文件中（通常在嵌入的 <?php> 标记中）或纯 .php 文件中。然而，webpack 似乎根本不处理 php 文件——所以我看不出它如何找到对 javascript、css 和图像文件的引用，或者编辑它们以包含哈希！而且我看到的关于在PHP项目中使用webpack的文章似乎根本没有提到这个问题。有一个 html 加载器，但没有一个用于 PHP 的。是否有某种标准做法可以在 PHP 网站中以独立的模块化方式使用 javascript，而不是使用我不知道的 <script> 标签？

最后，不同的网页对 javascript 和样式有不同的要求，而 webpack 似乎想要一个可以找到所有依赖项的单一 javascript 主入口点。在这个生态系统中使用 webpack 是否意味着为每个页面创建一个单独的 webpack 项目？我已经阅读了很多关于 webpack 的文章，但它们似乎都在处理与我的结构完全不同的 web 应用程序！

我确实在 Stackoverflow 上阅读了 this 的答案，我希望这会启发我。它非常接近 - 它解释说我确实需要创建一个顶级 index.js 文件，需要s所有其他 javascript 文件。但是由于不同的页面使用不同的 javascript，我推断我需要为每个页面创建不同的 index.js 文件（从而将每个页面视为不同的项目）。这是真的吗？许多文章都在谈论“单页应用程序”，所以也许这只是这些描述中的假设。或者也许我需要了解“代码拆分”。也许如果我一遍又一遍地阅读那个答案，我最终会明白要点。它讨论了 CSS 和 style-loader 和 css-loader，但我不清楚我的 .phtml 文件中存在的 <style> 标签是如何被它们处理的（更不用说在 WordPress 代码中排队的样式了）。我已经尝试过 SurviveJs 和 Official Webpack 文档，但同样，他们似乎在谈论与我所居住的世界不同的宇宙。我认为罗塞塔石碑的存在可以将这个新世界映射回传统 PHP应用！有什么指点吗？

Answer 1

这是一个老问题，但我试图提供一些指示，因为我刚刚经历了类似的障碍：尝试将 Webpack 与旧版 ZF1 应用程序集成：

1. 资产捆绑
2. 通过将版本哈希附加到文件名来破坏缓存
3. 为不同的应用路线提供不同的捆绑包

我的做法：

首先我签入了较新版本的 Zend_View，它提供了一些用于版本控制前端资产的解决方案。我发现了这个：

https://docs.zendframework.com/zend-view/helpers/asset/

并且非常喜欢将版本控制问题封装在单独的配置文件中的想法。显然，为了能够使用这种格式，我要么必须在遗留应用程序中使用这个 zend_view 助手，要么只是扩展遗留的 zend_view 类并添加简单地读取这种格式的资源映射的 ->asset 方法：

'view_helper_config' => [
    'asset' => [
        'resource_map' => [
            'css/style.css' => 'css/style-3a97ff4ee3.css',
            'js/vendor.js' => 'js/vendor-a507086eba.js',
        ],
    ],
],

坚持这种格式的另一个好处是，一旦您将应用程序升级到较新版本的 Zend Framework 或 Zend Expressive，您无需进行任何更改，只需开始使用现代 Zend_View 的 Asset 助手即可。

一旦我们有了这样的地图，我们就需要让 webpack 编写它。所以 HtmlWebpackPlugin 并不局限于 html 文件。我们可以write our own template 并完全控制如何使用 webpack 变量（例如资产名称和哈希）编写模板。这里最大的优势是 webpack 不需要覆盖通常会变成一团糟并且有其自身问题的大量视图模板（例如，如果我们通过 headScript 调用在控制器中包含脚本怎么办？） - 它只写地图。此位解决了问题 #2 - 缓存破坏。问题 #1 和 #3 - 资产捆绑和创建不同的捆绑包现在可以通过原生 webpack 方式解决 - 通过创建多个捆绑包，然后使用我们的自定义模板编写配置文件：

const path = require('path');

 module.exports = {
     mode: 'development',
     entry: {
         'js/vendor.js': './frontend/src/js/vendor.js',
         'css/style.css': './frontend/src/css/style.js',
         // and so on...
     },
     output: {
         filename: '[name]-[hash].js',
         path: path.resolve(__dirname, 'public/js'),
     },
     plugins: [
         new HtmlWebpackPlugin({  // Also generate a test.html
             filename: 'view-helper-config.php',
             template: 'view-helper-config.tpl'
         })
     ]
 };

view-helper-config.tpl 将是：

'view_helper_config' => [
    'asset' => [
        'resource_map' => [
             <% for (var chunk in htmlWebpackPlugin.files.chunks) { %>
                 <%chunk%> => <%= htmlWebpackPlugin.files.chunks[chunk].entry %>
            <% } %>
        ],
    ],
],