布說明深度解讀：jQuery UI 靜態(tài)資源、圖片焦點(diǎn)裁切與 Elasticsearch 端口默認(rèn)值修復(fù))
Wagtail 0.8.3 發(fā)布說明深度解讀jQuery UI 靜態(tài)資源、圖片焦點(diǎn)裁切與 Elasticsearch 端口默認(rèn)值修復(fù)【免費(fèi)下載鏈接】wagtailA Django content management system focused on flexibility and user experience項(xiàng)目地址: https://gitcode.com/GitHub_Trending/wa/wagtailWagtail 0.8.3 是 2014 年 11 月 18 日發(fā)布的一個集中修復(fù)版本覆蓋靜態(tài)資源收集collectstatic、頁面 ForeignKeyon_delete系統(tǒng)檢查、表單 Builder 的 JSON 序列化、圖片焦點(diǎn)點(diǎn)focal point裁切、Elasticsearch 連接配置等多個子系統(tǒng)。本文以 0.8.3 官方發(fā)布說明 為骨架逐條梳理其 Bug 修復(fù)內(nèi)容并結(jié)合當(dāng)前倉庫源碼說明這些修復(fù)點(diǎn)在現(xiàn)代版本中的演化結(jié)果幫助你理解每個修復(fù)背后涉及的機(jī)制以及升級到該版本時(shí)需要關(guān)注的唯一一項(xiàng)破壞性變更。版本概況與修復(fù)范圍0.8.3 是一個純 Bug 修復(fù)版本發(fā)布說明中沒有 Whats new 的新功能條目共包含 12 項(xiàng)修復(fù)按主題可以分為五類靜態(tài)資源jQuery UI sprite 文件缺失導(dǎo)致collectstatic報(bào)錯系統(tǒng)檢查頁面 ForeignKeyon_delete檢查的誤報(bào)與報(bào)錯級別調(diào)整表單 Builder含數(shù)字字段的提交失敗JSON 序列化錯誤的回歸修復(fù)圖片處理焦點(diǎn)點(diǎn)裁切的除零錯誤、指示器定位、透明圖處理與 Pillow 版本下限搜索與前端Elasticsearch 配置支持 URL 內(nèi)嵌 HTTP 認(rèn)證與端口默認(rèn)值修正、RoutablePageMixin頁面預(yù)覽的TypeError、富文本中缺失圖片文件不再拖垮整頁渲染。靜態(tài)資源補(bǔ)齊 jQuery UI sprite 文件修復(fù)說明Added missing jQuery UI sprite files, causing collectstatic to throw errors (most reported on Heroku)在 0.8.3 之前collectstatic命令會因缺少 jQuery UI 的 sprite 圖片文件而拋錯且在 Heroku 這類部署平臺其部署流程依賴collectstatic成功完成上被大量報(bào)告。此修復(fù)補(bǔ)全了被遺漏打包的 sprite 資源文件使python manage.py collectstatic能完整收集管理端靜態(tài)資源而不中斷。這一修復(fù)的直接收益是部署流程的健壯性靜態(tài)資源收集失敗會直接阻斷部署。雖然當(dāng)前版本的前端已演化為基于 Webpack 的構(gòu)建管線構(gòu)建入口可參考 webpack 配置但靜態(tài)資源必須可被完整收集這一約束始終存在于 Wagtail 的部署要求中。頁面系統(tǒng)檢查on_delete 檢查的誤報(bào)與級別調(diào)整0.8.3 對manage.py check中針對頁面 ForeignKey 的on_delete行為檢查做了兩處調(diào)整修復(fù)抽象基類繼承導(dǎo)致的誤報(bào)當(dāng)頁面類繼承自一個抽象類abstract base class且 ForeignKey 定義在該抽象類上時(shí)檢查會錯誤地將該 ForeignKey 報(bào)為問題false positive。此版本修復(fù)了該誤報(bào)貢獻(xiàn)者 Alejandro Giacometti。檢查級別由 error 降為 warningon_delete相關(guān)的 ForeignKey 檢查現(xiàn)在只產(chǎn)生警告而不是錯誤。背景解釋Django 從 1.9 起要求 ForeignKey 顯式聲明on_delete行為Wagtail 的系統(tǒng)檢查進(jìn)一步提醒開發(fā)者注意頁面刪除級聯(lián)時(shí)的外鍵行為。將其調(diào)整為 warning 意味著該檢查不會阻斷manage.py check的通過例如 CI 或 Heroku 部署中把 check 失敗當(dāng)作致命錯誤的場景只提示開發(fā)者自行判斷數(shù)據(jù)一致性風(fēng)險(xiǎn)。這一機(jī)制在當(dāng)前倉庫中仍保留Wagtail 的核心系統(tǒng)檢查入口在 wagtail/checks.py通過wagtail.checks模塊向 Django 檢查框架注冊自定義檢查項(xiàng)當(dāng)前版本的外鍵級聯(lián)行為定義可見 遷移 0023 與 遷移 0024它們將 Page 相關(guān)外鍵統(tǒng)一調(diào)整為明確的on_delete策略。表單 Builder數(shù)字字段提交的 JSON 序列化回歸Fixed a regression where form builder submissions containing a number field would fail with a JSON serialization error此版本修復(fù)了一個回歸缺陷表單 Builder 生成的表單中包含數(shù)字number字段時(shí)提交數(shù)據(jù)會觸發(fā) JSON 序列化錯誤導(dǎo)致保存失敗。問題根源在于表單提交數(shù)據(jù)序列化路徑中對數(shù)字類型值的處理不當(dāng)。表單 Builder 在當(dāng)前倉庫中位于wagtail/contrib/forms子應(yīng)用表單模型定義見 wagtail/contrib/forms/models.py。表單提交記錄FormSubmission以 JSON 字段保存用戶填寫的數(shù)據(jù)因此提交數(shù)據(jù)可被 JSON 序列化是該功能的基本前提此回歸修復(fù)保證了數(shù)字型字段值能正確進(jìn)入提交流程。圖片焦點(diǎn)點(diǎn)裁切除零、定位與透明圖處理0.8.3 包含一組圍繞focal point焦點(diǎn)點(diǎn)機(jī)制的圖片處理修復(fù)。焦點(diǎn)點(diǎn)允許圖片所有者在上傳時(shí)標(biāo)記視覺重點(diǎn)此后執(zhí)行fill類裁切過濾器時(shí)裁切框會優(yōu)先覆蓋該焦點(diǎn)區(qū)域避免裁掉畫面主體。這一機(jī)制在當(dāng)前版本中依然保留核心實(shí)現(xiàn)位于 wagtail/images/image_operations.pyFocalPoint相關(guān)的寬度/高度/坐標(biāo)參數(shù)focal_point_width、focal_point_height、focal_point_x、focal_point_y定義了焦點(diǎn)區(qū)域裁切計(jì)算中通過focal_point.centroid獲取焦點(diǎn)中心點(diǎn)并將裁切矩形move_to_cover(focal_point)移動到覆蓋焦點(diǎn)位置當(dāng)焦點(diǎn)區(qū)域與目標(biāo)裁切寬高比不一致時(shí)會按crop_aspect_ratio調(diào)整焦點(diǎn)框尺寸再計(jì)算偏移。0.8.3 針對該機(jī)制的三項(xiàng)修復(fù)除零錯誤當(dāng)焦點(diǎn)點(diǎn)尺寸恰好等于圖片尺寸時(shí)縮放計(jì)算中出現(xiàn)除以零。從當(dāng)前源碼的裁切計(jì)算邏輯看焦點(diǎn)框會被等比調(diào)整以適配目標(biāo)寬高比焦點(diǎn)框尺寸為零或全圖時(shí)都會進(jìn)入該分支這是當(dāng)年觸發(fā)ZeroDivisionError的典型輸入。指示器定位偏移對于小尺寸或細(xì)長thin圖片管理端焦點(diǎn)點(diǎn)選擇器上的指示器有時(shí)定位不正確。此版本修正了指示器坐標(biāo)的計(jì)算使其在極端寬高比下也能準(zhǔn)確貼合焦點(diǎn)位置。選擇器背景色改為灰色焦點(diǎn)點(diǎn)選擇器focal point chooser背景色由其他顏色改為灰色便于在透明圖片如 PNG 帶 alpha 通道上觀察焦點(diǎn)位置。透明圖與 Pillow 版本下限與透明圖處理相關(guān)的兩條修復(fù)Fix: Minimum Pillow version bumped to 2.6.1 to work around a crash when using images with transparencyFix: Images with transparency are now handled better when being used in feature detectionPillow 最低版本提升到 2.6.1低版本 Pillow 在處理帶透明通道的圖片時(shí)會崩潰此版本將 Pillow 最低要求提升到 2.6.1 以規(guī)避該問題。特征檢測中的透明圖處理Wagtail 圖片處理包含feature detection特征檢測如自動識別圖片焦點(diǎn)區(qū)域邏輯透明圖在其中處理得不夠穩(wěn)健此版本改進(jìn)了該路徑。版本約束方面當(dāng)前倉庫的依賴聲明已將要求大幅上調(diào)——pyproject.toml 中聲明Pillow9.1.0。也就是說當(dāng)年因崩潰而提升的 2.6.1 下限只是起點(diǎn)現(xiàn)代版本運(yùn)行需要 Pillow 9.1.0 及以上。搜索與頁面Elasticsearch 配置、RoutablePageMixin 預(yù)覽與富文本容錯Elasticsearch 連接 URL 解析Elasticsearch configuration now supports specifying HTTP authentication parameters as part of the URL, and defaults to ports 80 (HTTP) and 443 (HTTPS) if port number not specified0.8.3 對WAGTAILSEARCH_BACKENDS中的 Elasticsearch 連接 URL 解析做了兩點(diǎn)改進(jìn)支持在 URL 中直接攜帶 HTTP 認(rèn)證參數(shù)http://user:passhost/形式無需在配置中單獨(dú)拆分用戶名密碼URL 中未顯式指定端口時(shí)按 URL scheme 的常規(guī)默認(rèn)值處理——http用 80https用 443此前錯誤地默認(rèn)成 9200詳見下文升級注意事項(xiàng)。搜索后端配置經(jīng)由 Django settings 的WAGTAILSEARCH_BACKENDS傳入后端構(gòu)造邏輯。當(dāng)前倉庫中搜索后端的實(shí)現(xiàn)位于wagtail/search/backends包下Elasticsearch 后端文件包括 elasticsearch7.py、elasticsearch8.py、elasticsearch9.py另有 OpenSearch 后端這些文件均委托給上游modelsearch包的同名后端實(shí)現(xiàn)連接 URL 的解析含端口默認(rèn)值與認(rèn)證參數(shù)提取也由該共享層完成。RoutablePageMixin 預(yù)覽 TypeErrorFixed a TypeError when previewing pages that use RoutablePageMixin使用RoutablePageMixin的頁面在預(yù)覽時(shí)觸發(fā)TypeError。該類用于讓頁面在子路徑上路由到不同視圖如列表頁與詳情頁共用一個頁面模型。預(yù)覽preview流程中請求構(gòu)造與RoutablePageMixin的路由邏輯發(fā)生參數(shù)不匹配此版本修復(fù)了該兼容性問題。RoutablePageMixin當(dāng)前仍位于wagtail/contrib/routable_page子應(yīng)用中預(yù)覽修復(fù)后不影響其路由行為。富文本中缺失圖片的容錯渲染Rendering image with missing file in rich text no longer crashes the entire pageIOErrors thrown by underlying image libraries that are not reporting a missing image file are no longer caught這兩條互為表里此前富文本中引用的圖片文件丟失時(shí)渲染會拋出異常并導(dǎo)致整頁崩潰修復(fù)后單張圖片缺失不再影響整個頁面的渲染。同時(shí)收緊了異常捕獲邊界底層圖片庫拋出的IOError中只有確實(shí)對應(yīng)圖片文件缺失的情況才會被容錯處理其他IOError可能意味著磁盤故障、權(quán)限問題等真實(shí)錯誤不再被靜默吞掉會正常向上拋出以便排查。這條修復(fù)確立了 Wagtail 圖片渲染的一條重要容錯原則缺失媒體文件屬于可恢復(fù)的顯示問題渲染占位/跳過而底層 IO 異常屬于系統(tǒng)問題應(yīng)當(dāng)暴露二者不可混同捕獲。升級注意事項(xiàng)Elasticsearch 必須顯式指定 9200 端口這是 0.8.3 唯一的破壞性變更發(fā)布說明原文In previous versions, an Elasticsearch connection URL inWAGTAILSEARCH_BACKENDSwithout an explicit port number (e.g.http://localhost/) would be treated as port 9200 (the Elasticsearch default) whereas the correct behavior would be to use the default http/https port of 80/443. This behavior has now been fixed, so sites running Elasticsearch on port 9200 must now specify this explicitly - e.g.http://localhost:9200. (Projects using the default settings, or the settings given in the Wagtail documentation, are unaffected.)要點(diǎn)拆解舊行為0.8.3 之前WAGTAILSEARCH_BACKENDS中不帶端口的 Elasticsearch URL如http://localhost/會被當(dāng)作 9200Elasticsearch 的服務(wù)默認(rèn)端口處理。這對遵循官方文檔配置的站點(diǎn)是恰好正確的因?yàn)槲臋n給出的示例本身就跑在 9200 上。新行為0.8.3 起不帶端口的 URL 按 URL 協(xié)議語義取 80HTTP或 443HTTPS。因此如果你的 Elasticsearch 恰好運(yùn)行在 9200必須在配置中顯式寫出端口。受影響的站點(diǎn)需要把WAGTAILSEARCH_BACKENDS中的連接 URL 改為顯式端口寫法WAGTAILSEARCH_BACKENDS { default: { BACKEND: wagtailsearch.backends.elasticsearch, URL: http://localhost:9200, # 必須顯式指定 9200 端口 }, }發(fā)布說明同時(shí)指出使用 Wagtail 默認(rèn)設(shè)置或官方文檔所給設(shè)置的站點(diǎn)不受影響因?yàn)槟切┡渲帽旧砭蛶Я?9200只有自寫了省略端口 URL 的站點(diǎn)需要修改。這類默認(rèn)端口語義修正在升級舊版本時(shí)值得作為檢查項(xiàng)任何依賴省略端口且服務(wù)恰好跑在非常規(guī)端口上的連接配置都會在解析邏輯修正后悄然連到錯誤端口。小結(jié)Wagtail 0.8.3 雖小卻清晰勾勒出這個內(nèi)容管理系統(tǒng)的幾條核心健壯性原則部署健壯性靜態(tài)資源必須能被collectstatic完整收集否則阻斷部署平臺檢查分級系統(tǒng)檢查區(qū)分必須修復(fù)的 error與需要留意的 warning避免誤報(bào)阻塞發(fā)布流程圖片管道焦點(diǎn)點(diǎn)裁切對邊界輸入焦點(diǎn)全圖、細(xì)長圖、透明圖必須安全且底層庫崩潰要靠版本下限兜底渲染容錯邊界缺失圖片文件降級處理真實(shí) IO 異常必須暴露配置解析語義連接 URL 的端口默認(rèn)值遵循協(xié)議規(guī)范非常規(guī)端口必須顯式聲明。如需查看該版本前后各次發(fā)布的完整變更記錄可參考 docs/releases 目錄下的其余版本說明文件?！久赓M(fèi)下載鏈接】wagtailA Django content management system focused on flexibility and user experience項(xiàng)目地址: https://gitcode.com/GitHub_Trending/wa/wagtail創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Wagtail 0.8.3 發(fā)布說明深度解讀：jQuery UI 靜態(tài)資源、圖片焦點(diǎn)裁切與 Elasticsearch 端口默認(rèn)值修復(fù)
Wagtail 0.8.3 發(fā)布說明深度解讀jQuery UI 靜態(tài)資源、圖片焦點(diǎn)裁切與 Elasticsearch 端口默認(rèn)值修復(fù)【免費(fèi)下載鏈接】wagtailA Django content management system focused on flexibility and user experience項(xiàng)目地址: https://gitcode.com/GitHub_Trending/wa/wagtailWagtail 0.8.3 是 2014 年 11 月 18 日發(fā)布的一個集中修復(fù)版本覆蓋靜態(tài)資源收集collectstatic、頁面 ForeignKeyon_delete系統(tǒng)檢查、表單 Builder 的 JSON 序列化、圖片焦點(diǎn)點(diǎn)focal point裁切、Elasticsearch 連接配置等多個子系統(tǒng)。本文以 0.8.3 官方發(fā)布說明 為骨架逐條梳理其 Bug 修復(fù)內(nèi)容并結(jié)合當(dāng)前倉庫源碼說明這些修復(fù)點(diǎn)在現(xiàn)代版本中的演化結(jié)果幫助你理解每個修復(fù)背后涉及的機(jī)制以及升級到該版本時(shí)需要關(guān)注的唯一一項(xiàng)破壞性變更。版本概況與修復(fù)范圍0.8.3 是一個純 Bug 修復(fù)版本發(fā)布說明中沒有 Whats new 的新功能條目共包含 12 項(xiàng)修復(fù)按主題可以分為五類靜態(tài)資源jQuery UI sprite 文件缺失導(dǎo)致collectstatic報(bào)錯系統(tǒng)檢查頁面 ForeignKeyon_delete檢查的誤報(bào)與報(bào)錯級別調(diào)整表單 Builder含數(shù)字字段的提交失敗JSON 序列化錯誤的回歸修復(fù)圖片處理焦點(diǎn)點(diǎn)裁切的除零錯誤、指示器定位、透明圖處理與 Pillow 版本下限搜索與前端Elasticsearch 配置支持 URL 內(nèi)嵌 HTTP 認(rèn)證與端口默認(rèn)值修正、RoutablePageMixin頁面預(yù)覽的TypeError、富文本中缺失圖片文件不再拖垮整頁渲染。靜態(tài)資源補(bǔ)齊 jQuery UI sprite 文件修復(fù)說明Added missing jQuery UI sprite files, causing collectstatic to throw errors (most reported on Heroku)在 0.8.3 之前collectstatic命令會因缺少 jQuery UI 的 sprite 圖片文件而拋錯且在 Heroku 這類部署平臺其部署流程依賴collectstatic成功完成上被大量報(bào)告。此修復(fù)補(bǔ)全了被遺漏打包的 sprite 資源文件使python manage.py collectstatic能完整收集管理端靜態(tài)資源而不中斷。這一修復(fù)的直接收益是部署流程的健壯性靜態(tài)資源收集失敗會直接阻斷部署。雖然當(dāng)前版本的前端已演化為基于 Webpack 的構(gòu)建管線構(gòu)建入口可參考 webpack 配置但靜態(tài)資源必須可被完整收集這一約束始終存在于 Wagtail 的部署要求中。頁面系統(tǒng)檢查on_delete 檢查的誤報(bào)與級別調(diào)整0.8.3 對manage.py check中針對頁面 ForeignKey 的on_delete行為檢查做了兩處調(diào)整修復(fù)抽象基類繼承導(dǎo)致的誤報(bào)當(dāng)頁面類繼承自一個抽象類abstract base class且 ForeignKey 定義在該抽象類上時(shí)檢查會錯誤地將該 ForeignKey 報(bào)為問題false positive。此版本修復(fù)了該誤報(bào)貢獻(xiàn)者 Alejandro Giacometti。檢查級別由 error 降為 warningon_delete相關(guān)的 ForeignKey 檢查現(xiàn)在只產(chǎn)生警告而不是錯誤。背景解釋Django 從 1.9 起要求 ForeignKey 顯式聲明on_delete行為Wagtail 的系統(tǒng)檢查進(jìn)一步提醒開發(fā)者注意頁面刪除級聯(lián)時(shí)的外鍵行為。將其調(diào)整為 warning 意味著該檢查不會阻斷manage.py check的通過例如 CI 或 Heroku 部署中把 check 失敗當(dāng)作致命錯誤的場景只提示開發(fā)者自行判斷數(shù)據(jù)一致性風(fēng)險(xiǎn)。這一機(jī)制在當(dāng)前倉庫中仍保留Wagtail 的核心系統(tǒng)檢查入口在 wagtail/checks.py通過wagtail.checks模塊向 Django 檢查框架注冊自定義檢查項(xiàng)當(dāng)前版本的外鍵級聯(lián)行為定義可見 遷移 0023 與 遷移 0024它們將 Page 相關(guān)外鍵統(tǒng)一調(diào)整為明確的on_delete策略。表單 Builder數(shù)字字段提交的 JSON 序列化回歸Fixed a regression where form builder submissions containing a number field would fail with a JSON serialization error此版本修復(fù)了一個回歸缺陷表單 Builder 生成的表單中包含數(shù)字number字段時(shí)提交數(shù)據(jù)會觸發(fā) JSON 序列化錯誤導(dǎo)致保存失敗。問題根源在于表單提交數(shù)據(jù)序列化路徑中對數(shù)字類型值的處理不當(dāng)。表單 Builder 在當(dāng)前倉庫中位于wagtail/contrib/forms子應(yīng)用表單模型定義見 wagtail/contrib/forms/models.py。表單提交記錄FormSubmission以 JSON 字段保存用戶填寫的數(shù)據(jù)因此提交數(shù)據(jù)可被 JSON 序列化是該功能的基本前提此回歸修復(fù)保證了數(shù)字型字段值能正確進(jìn)入提交流程。圖片焦點(diǎn)點(diǎn)裁切除零、定位與透明圖處理0.8.3 包含一組圍繞focal point焦點(diǎn)點(diǎn)機(jī)制的圖片處理修復(fù)。焦點(diǎn)點(diǎn)允許圖片所有者在上傳時(shí)標(biāo)記視覺重點(diǎn)此后執(zhí)行fill類裁切過濾器時(shí)裁切框會優(yōu)先覆蓋該焦點(diǎn)區(qū)域避免裁掉畫面主體。這一機(jī)制在當(dāng)前版本中依然保留核心實(shí)現(xiàn)位于 wagtail/images/image_operations.pyFocalPoint相關(guān)的寬度/高度/坐標(biāo)參數(shù)focal_point_width、focal_point_height、focal_point_x、focal_point_y定義了焦點(diǎn)區(qū)域裁切計(jì)算中通過focal_point.centroid獲取焦點(diǎn)中心點(diǎn)并將裁切矩形move_to_cover(focal_point)移動到覆蓋焦點(diǎn)位置當(dāng)焦點(diǎn)區(qū)域與目標(biāo)裁切寬高比不一致時(shí)會按crop_aspect_ratio調(diào)整焦點(diǎn)框尺寸再計(jì)算偏移。0.8.3 針對該機(jī)制的三項(xiàng)修復(fù)除零錯誤當(dāng)焦點(diǎn)點(diǎn)尺寸恰好等于圖片尺寸時(shí)縮放計(jì)算中出現(xiàn)除以零。從當(dāng)前源碼的裁切計(jì)算邏輯看焦點(diǎn)框會被等比調(diào)整以適配目標(biāo)寬高比焦點(diǎn)框尺寸為零或全圖時(shí)都會進(jìn)入該分支這是當(dāng)年觸發(fā)ZeroDivisionError的典型輸入。指示器定位偏移對于小尺寸或細(xì)長thin圖片管理端焦點(diǎn)點(diǎn)選擇器上的指示器有時(shí)定位不正確。此版本修正了指示器坐標(biāo)的計(jì)算使其在極端寬高比下也能準(zhǔn)確貼合焦點(diǎn)位置。選擇器背景色改為灰色焦點(diǎn)點(diǎn)選擇器focal point chooser背景色由其他顏色改為灰色便于在透明圖片如 PNG 帶 alpha 通道上觀察焦點(diǎn)位置。透明圖與 Pillow 版本下限與透明圖處理相關(guān)的兩條修復(fù)Fix: Minimum Pillow version bumped to 2.6.1 to work around a crash when using images with transparencyFix: Images with transparency are now handled better when being used in feature detectionPillow 最低版本提升到 2.6.1低版本 Pillow 在處理帶透明通道的圖片時(shí)會崩潰此版本將 Pillow 最低要求提升到 2.6.1 以規(guī)避該問題。特征檢測中的透明圖處理Wagtail 圖片處理包含feature detection特征檢測如自動識別圖片焦點(diǎn)區(qū)域邏輯透明圖在其中處理得不夠穩(wěn)健此版本改進(jìn)了該路徑。版本約束方面當(dāng)前倉庫的依賴聲明已將要求大幅上調(diào)——pyproject.toml 中聲明Pillow9.1.0。也就是說當(dāng)年因崩潰而提升的 2.6.1 下限只是起點(diǎn)現(xiàn)代版本運(yùn)行需要 Pillow 9.1.0 及以上。搜索與頁面Elasticsearch 配置、RoutablePageMixin 預(yù)覽與富文本容錯Elasticsearch 連接 URL 解析Elasticsearch configuration now supports specifying HTTP authentication parameters as part of the URL, and defaults to ports 80 (HTTP) and 443 (HTTPS) if port number not specified0.8.3 對WAGTAILSEARCH_BACKENDS中的 Elasticsearch 連接 URL 解析做了兩點(diǎn)改進(jìn)支持在 URL 中直接攜帶 HTTP 認(rèn)證參數(shù)http://user:passhost/形式無需在配置中單獨(dú)拆分用戶名密碼URL 中未顯式指定端口時(shí)按 URL scheme 的常規(guī)默認(rèn)值處理——http用 80https用 443此前錯誤地默認(rèn)成 9200詳見下文升級注意事項(xiàng)。搜索后端配置經(jīng)由 Django settings 的WAGTAILSEARCH_BACKENDS傳入后端構(gòu)造邏輯。當(dāng)前倉庫中搜索后端的實(shí)現(xiàn)位于wagtail/search/backends包下Elasticsearch 后端文件包括 elasticsearch7.py、elasticsearch8.py、elasticsearch9.py另有 OpenSearch 后端這些文件均委托給上游modelsearch包的同名后端實(shí)現(xiàn)連接 URL 的解析含端口默認(rèn)值與認(rèn)證參數(shù)提取也由該共享層完成。RoutablePageMixin 預(yù)覽 TypeErrorFixed a TypeError when previewing pages that use RoutablePageMixin使用RoutablePageMixin的頁面在預(yù)覽時(shí)觸發(fā)TypeError。該類用于讓頁面在子路徑上路由到不同視圖如列表頁與詳情頁共用一個頁面模型。預(yù)覽preview流程中請求構(gòu)造與RoutablePageMixin的路由邏輯發(fā)生參數(shù)不匹配此版本修復(fù)了該兼容性問題。RoutablePageMixin當(dāng)前仍位于wagtail/contrib/routable_page子應(yīng)用中預(yù)覽修復(fù)后不影響其路由行為。富文本中缺失圖片的容錯渲染Rendering image with missing file in rich text no longer crashes the entire pageIOErrors thrown by underlying image libraries that are not reporting a missing image file are no longer caught這兩條互為表里此前富文本中引用的圖片文件丟失時(shí)渲染會拋出異常并導(dǎo)致整頁崩潰修復(fù)后單張圖片缺失不再影響整個頁面的渲染。同時(shí)收緊了異常捕獲邊界底層圖片庫拋出的IOError中只有確實(shí)對應(yīng)圖片文件缺失的情況才會被容錯處理其他IOError可能意味著磁盤故障、權(quán)限問題等真實(shí)錯誤不再被靜默吞掉會正常向上拋出以便排查。這條修復(fù)確立了 Wagtail 圖片渲染的一條重要容錯原則缺失媒體文件屬于可恢復(fù)的顯示問題渲染占位/跳過而底層 IO 異常屬于系統(tǒng)問題應(yīng)當(dāng)暴露二者不可混同捕獲。升級注意事項(xiàng)Elasticsearch 必須顯式指定 9200 端口這是 0.8.3 唯一的破壞性變更發(fā)布說明原文In previous versions, an Elasticsearch connection URL inWAGTAILSEARCH_BACKENDSwithout an explicit port number (e.g.http://localhost/) would be treated as port 9200 (the Elasticsearch default) whereas the correct behavior would be to use the default http/https port of 80/443. This behavior has now been fixed, so sites running Elasticsearch on port 9200 must now specify this explicitly - e.g.http://localhost:9200. (Projects using the default settings, or the settings given in the Wagtail documentation, are unaffected.)要點(diǎn)拆解舊行為0.8.3 之前WAGTAILSEARCH_BACKENDS中不帶端口的 Elasticsearch URL如http://localhost/會被當(dāng)作 9200Elasticsearch 的服務(wù)默認(rèn)端口處理。這對遵循官方文檔配置的站點(diǎn)是恰好正確的因?yàn)槲臋n給出的示例本身就跑在 9200 上。新行為0.8.3 起不帶端口的 URL 按 URL 協(xié)議語義取 80HTTP或 443HTTPS。因此如果你的 Elasticsearch 恰好運(yùn)行在 9200必須在配置中顯式寫出端口。受影響的站點(diǎn)需要把WAGTAILSEARCH_BACKENDS中的連接 URL 改為顯式端口寫法WAGTAILSEARCH_BACKENDS { default: { BACKEND: wagtailsearch.backends.elasticsearch, URL: http://localhost:9200, # 必須顯式指定 9200 端口 }, }發(fā)布說明同時(shí)指出使用 Wagtail 默認(rèn)設(shè)置或官方文檔所給設(shè)置的站點(diǎn)不受影響因?yàn)槟切┡渲帽旧砭蛶Я?9200只有自寫了省略端口 URL 的站點(diǎn)需要修改。這類默認(rèn)端口語義修正在升級舊版本時(shí)值得作為檢查項(xiàng)任何依賴省略端口且服務(wù)恰好跑在非常規(guī)端口上的連接配置都會在解析邏輯修正后悄然連到錯誤端口。小結(jié)Wagtail 0.8.3 雖小卻清晰勾勒出這個內(nèi)容管理系統(tǒng)的幾條核心健壯性原則部署健壯性靜態(tài)資源必須能被collectstatic完整收集否則阻斷部署平臺檢查分級系統(tǒng)檢查區(qū)分必須修復(fù)的 error與需要留意的 warning避免誤報(bào)阻塞發(fā)布流程圖片管道焦點(diǎn)點(diǎn)裁切對邊界輸入焦點(diǎn)全圖、細(xì)長圖、透明圖必須安全且底層庫崩潰要靠版本下限兜底渲染容錯邊界缺失圖片文件降級處理真實(shí) IO 異常必須暴露配置解析語義連接 URL 的端口默認(rèn)值遵循協(xié)議規(guī)范非常規(guī)端口必須顯式聲明。如需查看該版本前后各次發(fā)布的完整變更記錄可參考 docs/releases 目錄下的其余版本說明文件?！久赓M(fèi)下載鏈接】wagtailA Django content management system focused on flexibility and user experience項(xiàng)目地址: https://gitcode.com/GitHub_Trending/wa/wagtail創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考