Question

我在＃34;现代＆＃34;的勇敢新世界中感到非常迷茫和愚蠢。带有node.js，模块捆绑器，任务运行器等的Web应用程序。

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

应用程序开始开发的概念是javascript只应用于＆＃34;渐进增强＆＃34;，但最终我们屈服于要求启用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>标记，也可以通过管理整个页面布局及其内容的其他PHP函数注入到html中。 {1}}部分。

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

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

我在Stackoverflow上读过这里的this回答，我希望能启发我。它相当接近 - 它解释说我需要创建一个需要所有其他javascript文件的顶级index.js文件。但由于不同的页面使用不同的javascript，我推断我需要为每个页面创建不同的index.js文件（因此将每个页面视为不同的项目）。这可能是真的吗？许多文章都谈论单页应用程序＆＃34;所以也许这只是这些描述中的假设。或许我需要理解＆＃34; Code Splitting＆＃34;。也许如果我一遍又一遍地阅读这个答案，我最终会得到这个要点。它讨论了CSS和<?php>以及<script>，但我不清楚我的.phtml文件中的style-loader标记是如何被它们处理的（更不用说样式了）在WordPress代码中排队）。我曾尝试过SurviveJs和官方Webpack文档，但同样，他们似乎在谈论的是一个与我所居住的不同的宇宙。我认为Rosetta石头存在于某个可以映射这个新世界的地方回到传统的PHP应用程序！有什么指针吗？

Answer 1

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

资产捆绑
通过将版本哈希附加到文件名中来清除缓存
为不同的应用路线分配不同的捆绑商品

我的方法：

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

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

并非常喜欢将版本控制问题封装在单独的配置文件中的想法。显然，要使用此格式，我要么必须在旧版应用程序中使用此zend_view帮助程序，要么简单地扩展旧版zend_view类并添加简单读取此格式资源映射中的->asset方法：< / p>

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

坚持使用这种格式的另一个优点是，一旦将应用程序升级到更高版本的Zend Framework或Zend Expressive，就无需进行任何更改，只需开始使用Asset Zend_View。

一旦有了类似的地图，我们需要使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 %>
            <% } %>
        ],
    ],
],

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

1 个答案: