在Zend Framework 1应用程序中进行缓存清除静态资源

3

在“现代”Web应用程序的世界中,我对使用node.js、模块打包器、任务运行器等技术感到非常迷茫和愚蠢。

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

该应用程序最初开发时认为javascript只应用于“渐进增强”,但最终我们不得不要求启用javascript以获得正确的行为。我们支持使用OAuth2身份验证通过几个提供程序(Facebook、Google、LinkedIn、Twitter等)进行注册和登录,但仅通过服务器流而不是javascript SDK。我们使用jQuery和有限量的Zend_Dojo javascript库以及一些自制的javascript函数(除了WordPress使用的任何内容)。

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

现在我们正在寻求移向更具响应性的设计,以更好地适应移动和平板电脑用户,并考虑渐进式Web应用程序。因此,需要对css进行重大更改并增加javascript的使用。尽管Nginx提供了静态资源的eTags,但Google Page Speed Insights告诉我们,我们存在阻塞下载javascript和css资源,并且我们没有利用浏览器缓存。

从我看到的各种文章来看,Webpack打包工具可以在解决所有这些性能瓶颈方面提供重要帮助。但是我真的不知道它如何适用于这个生态系统。我对我们网站工作方式的精神模型是,通过PHP代码分析http查询,将其分派给访问会话数据和MySQL数据库的PHP操作例程,然后通过phtml模板(ZF1视图脚本)输出html,其中包含嵌入的PHP标记。 phtml模板可以直接或通过其他管理整个页面布局及其

部分内容的PHP函数将
1个回答

2
这是一个老问题,但我尝试给出一些指引,因为我刚刚经历了类似的障碍:尝试将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文件。我们可以编写自己的模板并完全控制如何使用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 %>
            <% } %>
        ],
    ],
],

你也在将你的应用程序升级到ZF 2吗?如果是,你期望有什么样的好处(除了现代化的Zend_View)?我几年前考虑过这个问题,但是根据我当时所读的内容,这听起来需要付出巨大的努力,但收益很少。现在我正在思考的是,如果我要进行重新编写,那么就应该转向渐进式Web应用程序,因为原生体验和在没有互联网连接的情况下执行某些功能非常重要。 - sootsnoot
1
我从未真正喜欢Zend Framework在ZF2和ZF3中发展的方向,但与此同时,ZF1已经过了其生命周期,我需要保持整个堆栈的新鲜和安全(升级到php7.2,升级ubuntu等)。因此,这是我的主要升级动机-必要性和未来证明,而不是任何特定的好处。幸运的是,Zend推出了Zend Expressive-一个精简的微框架,您可以选择和匹配组件,并且在我看来,它提供了比通过ZF1-> ZF2-> ZF3的非常规升级路径更短的升级路线。 - Jarek.D
1
ZE的配置灵活性使我能够轻松地在遗留系统周围创建一个外观,并逐步将旧的ZF1模型重构为ZE服务等。我目前看到的主要好处主要是架构方面 - 我终于可以开始使用Composer来解决依赖关系,我终于可以正确地使用依赖注入(不像ZF2的服务定位器模式)。所有这些都有助于更可测试和强大的代码库。 - Jarek.D

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接