[WordPress] 外掛分享: Aggregator

首頁外掛目錄 › Aggregator
⚠ 此外掛已下架 — 不再更新維護,建議勿安裝。
10+
安裝啟用
尚無評分
42 天前
最後更新
問題解決
WordPress 4.8+ v2.2.0 上架:2015-06-04

內容簡介

Aggregator 外掛已達到生命終點,無法再獲得更新。此外掛曾經將網站的本地 JavaScript 檔案整合為一個標頭和一個頁尾請求,但隨著 HTTP/2 的普及,這種做法已不再必要,甚至會對網站造成傷害。

【主要功能】
• 整合本地 JavaScript 檔案
• 提供單一請求以減少載入時間
• 兼容舊版 WordPress 的需求

外掛標籤

開發者團隊

⬇ 下載最新版 (v2.2.0) 或搜尋安裝

① 下載 ZIP → 後台「外掛 › 安裝外掛 › 上傳外掛」
② 後台搜尋「Aggregator」→ 直接安裝(推薦)
📦 歷史版本下載

原文外掛簡介

This plugin has reached the end of its life and receives no further updates. Please deactivate and delete it.
It aggregated a site’s local JavaScript files into one header and one footer request, back when the number of requests was what made a page slow. That has not been true for years, and on a current WordPress the plugin now does more harm than good.
Why it is being retired
HTTP/2 removed the reason it existed. Bundling files was a way around HTTP/1.1, which opened a new connection per file. HTTP/2 and HTTP/3 send many files over one connection, so a handful of separate scripts costs next to nothing – while one big bundle has to be re-downloaded in full whenever any part of it changes.
WordPress does the job itself now. Since 6.3 a script can be registered with defer or async (wp_script_add_data( $handle, 'strategy', 'defer' )), which is a better answer to blocking scripts than merging them. Since 6.5 there are script modules, a separate registry this plugin never touched at all – so on a modern block theme part of the JavaScript was never aggregated in the first place.
And it breaks pages. Measured on WordPress 7.0.2 with version 2.1.2:

Anything added with wp_add_inline_script() is silently dropped. Both before and after code disappear. WordPress itself and a great many plugins pass configuration to their scripts this way, so this can leave a page with script files that never get their settings.

A defer or async strategy is lost. Scripts that were meant not to block rendering end up inside a bundle that does.
wp_localize_script() data survives – the plugin re-renders it itself – which is why the damage is not always obvious.

What to do instead
Deactivate and delete the plugin. Nothing needs to replace it: WordPress serves the individual files again, which is the right thing over HTTP/2. If single scripts block rendering, register them with a defer strategy.
The aggregated files the plugin wrote are left behind on purpose so nothing breaks mid-request. They can be deleted afterwards – by default in wp-content/uploads/aggregated/, or in your theme directory if that was configured under Settings › Aggregator.

延伸相關外掛

文章
Filter
Mastodon