、搜索模块拆分与后台权限体系修复)
Wagtail 1.1 版本解析PageQuerySet.specific()、搜索模块拆分与后台权限体系修复【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址: https://gitcode.com/GitHub_Trending/wa/wagtailWagtail 1.12015-09-15 发布是 Django 内容管理系统 Wagtail 早期演进中的关键版本它引入了PageQuerySet.specific()这一至今仍被广泛使用的查询优化机制将推广搜索结果Promoted search results从核心搜索模块剥离为独立 contrib 模块让wagtailapi重构到 Django REST Framework 之上并系统性修复了后台权限模型的多处不一致。读完本文你将掌握这四项核心改动的技术细节与源码实现脉络、完整的次要特性与缺陷修复清单以及两条对升级者有实际影响的破坏性变更EditorsPick模型迁移与is_creatable标志替换。版本背景Wagtail 1.1 发布于 2015 年 9 月 15 日原始发布说明见 docs/releases/1.1.rst。此时的 Wagtail 正处于 1.x 系列快速迭代期本次版本的重心是机制化与模块化把此前隐藏在内部实现中的页面类型查询机制specific()正式开放为公共 API把功能性的推广搜索从wagtail.wagtailsearch中拆出并借wagtail start项目模板的普及开始规范第三方依赖的引入方式Django REST Framework。以下逐项展开并结合当前仓库源码说明这些设计在今天的代码库中演变成了什么。核心新特性1. PageQuerySet 的specific()方法发布说明原文指出获取页面 QuerySet 的操作例如homepage.get_children()默认返回的是基础Page实例只包含 title 等核心页面数据新增的specific()方法例如homepage.get_children().specific()允许以最少查询次数把它们取出为各自最具体的子类型。这一设计解决的是 Wagtail 页面模型树的固有难题wagtailcore.page表只存储所有页面共有的通用字段具体页面类型如文章页、产品页的字段分散在多张子表中。specific()的价值在于按content_type分组后对每组各发一条子查询而不是对每一行页面逐条查询子表——这正是文档中using the minimum number of queries的含义。在当前仓库中该机制的完整实现位于 wagtail/query.py 的SpecificQuerySetMixin约 L138 起specific()方法wagtail/query.py#L157-L170通过克隆 QuerySet 并将_iterable_class切换为SpecificIterable或deferTrue时的DeferredSpecificIterable只加载通用字段、延迟加载具体字段来工作单条Page实例上的对应实现则在 wagtail/models/specific.py#L88。值得注意的是从源码结构看当前版本还扩展了select_related(..., for_specific_subqueriesTrue)wagtail/query.py#L182-L208允许在具体类型子查询中预取外键相关对象——这属于 1.1 之后多年的增强但它所基于的分组子查询骨架正是 1.1 年奠定的。2. Promoted search results 拆分为独立模块1.1 之前推广搜索结果编辑为某搜索词人工置顶的结果条目实现在wagtail.wagtailsearch内随核心搜索一起默认启用。1.1 将其移入独立模块wagtail.contrib.wagtailsearchpromotions从而不再默认启用。在当前仓库中该模块位于 wagtail/contrib/search_promotions/ 目录其AppConfig声明在 wagtail/contrib/search_promotions/apps.pyPython 包名已改为下划线风格wagtail.contrib.search_promotions但数据库 app label 仍保留历史值wagtailsearchpromotions以保证迁移连续性。文档中提到的SearchPromotion模型定义在 wagtail/contrib/search_promotions/models.py#L101配套的表单、视图与后台钩子分别位于 wagtail/contrib/search_promotions/forms.py、wagtail/contrib/search_promotions/views/settings.py 和 wagtail/contrib/search_promotions/wagtail_hooks.py其使用文档见 docs/reference/contrib/searchpromotions.md。3. Elasticsearch 索引的原子重建ATOMIC_REBUILD实验特性1.1 的 Elasticsearch 搜索后端接受一个实验性的ATOMIC_REBUILD标志开启后update_index任务运行期间旧索引仍然可供查询通过建新索引 切换别名的方式实现重建期间的服务不中断。文档将其标注为 experimental并引用了wagtailsearch_backends_atomic_rebuild文档锚点。从当前仓库的证据看这一标志如今仅存在于历史发布说明与 CHANGELOG.txt 中例如 1.11/1.12.x 曾修复过其与新版 Elasticsearch 客户端的别名处理兼容性当前 Elasticsearch 后端代码中已不再提供该配置项。可以推断随着搜索后端的多次重构这一早期实验特性已被后续实现所取代对 1.1 使用者而言它代表的重建期间索引持续可用这一设计目标在后续版本中由其他机制承接。4. wagtailapi 模块重构到 Django REST Framework 之上1.1 中wagtail.contrib.wagtailapi模块改用 Django REST Framework 构建并首次随附一套可复用的序列化器库供开发者在自己的 DRF 项目中直接调用。发布说明明确No user-facing changes have been made——即对最终 API 使用者的接口形态没有变化同时表达了未来支持 browsable API 等更多 DRF 特性的期望。从源码演进脉络看这条路线一直延续至今当前仓库的公开内容 API 已发展到 wagtail/api/v2/ 与 wagtail/api/v3/而后台自身的页面 APIwagtail/admin/api/同样基于 DRF 序列化器见 wagtail/admin/api/serializers.py。1.1 确立的API 层交给 DRF决策是今天 Wagtail API 子系统的直接起点。5. 后台权限体系修复1.1 修复了后台界面中多处权限不一致清单包括移除User profile的全部权限原本未被使用移除图片和文档的 delete 权限原本未被使用用户现只需持有 change 权限即可访问图片与文档此前还需要 add 权限Users 的权限现在取自自定义 user model若已配置而不再总是硬编码使用 Django 内置 User 模型的权限Groups 与 Users 现在对其各自的 add、change、delete 权限表现一致。这些修复针对的是 1.0 时代wagtail start模板与 Django 权限框架交互时的若干死权限与隐性门槛。对自定义用户模型的项目尤其重要Wagtail 后台从 1.1 起正式尊重项目AUTH_USER_MODEL的权限配置这一行为一直保留到当前版本的用户权限管理实现wagtail/users/。6. 可搜索的 Snippets继承自wagtail.wagtailsearch.index.Indexed的 snippet 模型如今会在 snippet 选择器chooser和列表页上获得搜索框。在当前仓库中snippets 功能已从早期的 contrib 地位提升为内置的独立应用 wagtail/snippets/而搜索入口的接入依赖于 1.1 时期确立的模型实现Indexed即可被搜索框架发现这一约定——搜索框架核心位于 wagtail/search/其注册机制允许任何实现了Indexed接口的模型Page 或 Snippet接入统一的索引与检索体系。次要特性清单Minor features1.1 的次要特性较多以下完整继承发布说明原文并在涉及当前仓库实现处给出佐证路径实现了表单提交form submissions的删除功能页面选择器模态框page chooser modal实现分页项目模板project template中的INSTALLED_APPS改为按优先级顺序precedence order排列应用{% image %}模板标签支持对图片变量施加过滤器例如{% image primary_img|default:secondary_img width-500 %}——即先按default回退选择图片再对其做width-500规格渲染风格指南style guide菜单项移入 Settings 子菜单搜索后端可以按模块路径如wagtail.wagtailsearch.backends.elasticsearch而非具体类...elasticsearch.ElasticSearch配置API 新增descendant_of过滤器。当前后台 API 中该过滤器仍然可用见 wagtail/admin/api/views.py#L100 对child_of/descendant_of的说明以及 wagtail/admin/api/serializers.py#L79-L93 中以?descendant_of2为例的子页面计数与分页链接生成wagtail start命令新增可选目录参数允许指定新项目生成位置非超级用户在持有相应权限时可查看/编辑/删除站点sites图片文件大小file size开始存入数据库避免不必要的文件系统查询页面 URL 查找命中缓存/数据库的频率降低后台 URL 全面改用 namespaced URLupdate_index任务改为按 1000 条一批索引以便展示进度并控制内存占用为PageRevision和Image增加数据库索引改善大型站点性能页面选择器中的搜索改用 Wagtail 搜索框架使结果按相关度排序PageChooserPanel支持传入页面类型列表list/tuple作为可接受类型SnippetChooserPanel的 snippet 类型参数可省略或传模型名字符串而不必传模型类为self模板变量增加别名以适配 Jinja2 模板引擎页面对象用page、字段面板/编辑处理器用field_panel、块block用value页面浏览器explorer增加引导文案提示编辑者除非在建站否则不应在根层级创建页面组页面权限表单中页面字段上的 Clear choice 与 Edit this page 按钮被移除Stream 控件的样式调整为与其他按钮一致新增is_creatable标志可标记某页面模型不允许在后台创建抽象abstractDjango 模型的页面自动视为不可创建新增挪威博克马尔语Norwegian Bokmål与冰岛语Icelandic翻译。其中is_creatable的当前实现可见于 wagtail/models/pages.py#L330-L334页面元类在类构建时按是否显式声明is_creatable、是否抽象、是否为基类Page本身计算默认值wagtail/models/pages.py#L1695 的can_create判断则是该类型是否允许在指定父节点下创建的入口相关测试见 wagtail/tests/test_page_model.py#L3500-L3511 与 wagtail/admin/tests/pages/test_create_page.py#L344-L345。缺陷修复清单Bug fixes发布说明列出的 13 项修复如下完整继承原文页面编辑器中非默认标签页里的文本域现在能正确调整高度富文本编辑器插入链接模态框中的标签页不再消失贡献者Tim Heap富文本字段中的 H2 元素在放入可折叠多字段面板collapsible multi field panel时被误加click()绑定的问题被修复wagtailimages模块现在兼容不允许重开已关闭文件的远程存储后端自动索引没有id字段的模型时搜索不再崩溃wagtailfrontendcache模块的 HTTP 后端被重写可靠地把请求转发到配置的缓存主机名使用 fill 过滤器缩放单像素图片时不再抛出ZeroDivisionError或 tile cannot extend outside image 错误数据库搜索后端search操作返回的 QuerySet 现在正确保留原查询的附加属性如prefetch_related/select_related外部图片 URL 生成器external image URL generator的响应被正确标记为流式streaming与 Django 缓存中间件配合时不再失败使用多重继承的页面现在可以正常复制page copy表单构建器form builder页面现在会读取get_context方法中定义的模板变量复制页面时页面修订记录page revision records中子对象的 ID 此前没有被重映射到新对象——这会导致编辑新页面时原页面上这些对象丢失现已修复新增的重定向redirect现在对所有站点生效而不仅是访问 Wagtail 后台所经由的那个站点添加用户Add user表单在校验失败时不再抛出硬错误hard error。其中与页面复制相关的两项多重继承支持、修订记录子对象 ID 重映射在 1.1 之后被进一步抽象为动作action体系当前仓库中页面复制的核心逻辑位于 wagtail/actions/copy_page.py它依然处理目标节点不能是源页面自身或其后代等约束见 wagtail/actions/copy_page.py#L87 处的is_descendant_of校验1.1 修复的正是这类复制语义的边界情况。升级注意事项Upgrade considerations1. 推广搜索结果不再默认启用由于该功能移入 contrib 模块升级到 1.1 后需手动重新启用在INSTALLED_APPS中加入wagtail.contrib.wagtailsearchpromotions原文档给出的配置示例INSTALLED_APPS [ ... wagtail.contrib.wagtailsearchpromotions, ... ]如果项目代码中引用了旧模型wagtail.wagtailsearch.models.EditorsPick必须改为wagtail.contrib.wagtailsearchpromotions.models.SearchPromotion。文档特别提示使用 Wagtail 1.0 的wagtail start命令创建的项目其search/views.py中通常含有对EditorsPick的引用需要一并更新。当前仓库中该模型的最终形态即 wagtail/contrib/search_promotions/models.py#L101 的SearchPromotion早期迁移见 wagtail/contrib/search_promotions/migrations/0001_initial.py。2.is_abstract标志被is_creatable取代1.1 之前页面模型上存在一个未文档化的is_abstract标志用于表示不应出现在可创建页面类型列表中典型场景仅供子类继承、不直接使用的基类页面模型。由于它与 DjangoMeta.abstract是两回事且容易混淆1.1 将其替换为语义更清晰的is_creatable。升级操作若你在任何模型上写过is_abstract True应改为is_creatable False如果模型本身就是 Django 意义上的抽象模型Meta中abstract True则无需添加该标志——此类模型本就不应出现在创建入口。从当前源码结构看这一约定已固化在页面元类中wagtail/models/pages.py#L330-L334 显示只有当类未显式声明is_creatable时才会按not cls._meta.abstract and cls is not base_page_model推导默认值——即Django 抽象模型自动不可创建的 1.1 规则沿用至今。测试 wagtail/tests/test_page_model.py#L3500-L3511 验证了默认值、显式is_creatable False以及该标志不被继承三种行为对应 wagtail/test/testapp/models.py#L2055 中is_creatable False的测试模型。结语从 1.1 看 Wagtail 的机制传承Wagtail 1.1 的发布说明篇幅不长但几乎每一条都指向此后多年仍在仓库中活跃的代码路径specific()的分组子查询机制wagtail/query.py、作为 contrib 模块推广的搜索推广wagtail/contrib/search_promotions/、建立在 DRF 之上的 API 层wagtail/api/v2/、wagtail/api/v3/、尊重自定义用户模型的权限体系、以及is_creatable标志wagtail/models/pages.py。理解这一版本等于理解了当前 Wagtail 查询层、搜索层与 API 层的共同起点而对于仍在使用旧版本的维护者两条升级注意事项SearchPromotion模型迁移与is_creatable替换至今仍是阅读该版本说明时最需要核对的操作项。【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址: https://gitcode.com/GitHub_Trending/wa/wagtail创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Wagtail 1.1 版本解析：PageQuerySet.specific()、搜索模块拆分与后台权限体系修复
Wagtail 1.1 版本解析PageQuerySet.specific()、搜索模块拆分与后台权限体系修复【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址: https://gitcode.com/GitHub_Trending/wa/wagtailWagtail 1.12015-09-15 发布是 Django 内容管理系统 Wagtail 早期演进中的关键版本它引入了PageQuerySet.specific()这一至今仍被广泛使用的查询优化机制将推广搜索结果Promoted search results从核心搜索模块剥离为独立 contrib 模块让wagtailapi重构到 Django REST Framework 之上并系统性修复了后台权限模型的多处不一致。读完本文你将掌握这四项核心改动的技术细节与源码实现脉络、完整的次要特性与缺陷修复清单以及两条对升级者有实际影响的破坏性变更EditorsPick模型迁移与is_creatable标志替换。版本背景Wagtail 1.1 发布于 2015 年 9 月 15 日原始发布说明见 docs/releases/1.1.rst。此时的 Wagtail 正处于 1.x 系列快速迭代期本次版本的重心是机制化与模块化把此前隐藏在内部实现中的页面类型查询机制specific()正式开放为公共 API把功能性的推广搜索从wagtail.wagtailsearch中拆出并借wagtail start项目模板的普及开始规范第三方依赖的引入方式Django REST Framework。以下逐项展开并结合当前仓库源码说明这些设计在今天的代码库中演变成了什么。核心新特性1. PageQuerySet 的specific()方法发布说明原文指出获取页面 QuerySet 的操作例如homepage.get_children()默认返回的是基础Page实例只包含 title 等核心页面数据新增的specific()方法例如homepage.get_children().specific()允许以最少查询次数把它们取出为各自最具体的子类型。这一设计解决的是 Wagtail 页面模型树的固有难题wagtailcore.page表只存储所有页面共有的通用字段具体页面类型如文章页、产品页的字段分散在多张子表中。specific()的价值在于按content_type分组后对每组各发一条子查询而不是对每一行页面逐条查询子表——这正是文档中using the minimum number of queries的含义。在当前仓库中该机制的完整实现位于 wagtail/query.py 的SpecificQuerySetMixin约 L138 起specific()方法wagtail/query.py#L157-L170通过克隆 QuerySet 并将_iterable_class切换为SpecificIterable或deferTrue时的DeferredSpecificIterable只加载通用字段、延迟加载具体字段来工作单条Page实例上的对应实现则在 wagtail/models/specific.py#L88。值得注意的是从源码结构看当前版本还扩展了select_related(..., for_specific_subqueriesTrue)wagtail/query.py#L182-L208允许在具体类型子查询中预取外键相关对象——这属于 1.1 之后多年的增强但它所基于的分组子查询骨架正是 1.1 年奠定的。2. Promoted search results 拆分为独立模块1.1 之前推广搜索结果编辑为某搜索词人工置顶的结果条目实现在wagtail.wagtailsearch内随核心搜索一起默认启用。1.1 将其移入独立模块wagtail.contrib.wagtailsearchpromotions从而不再默认启用。在当前仓库中该模块位于 wagtail/contrib/search_promotions/ 目录其AppConfig声明在 wagtail/contrib/search_promotions/apps.pyPython 包名已改为下划线风格wagtail.contrib.search_promotions但数据库 app label 仍保留历史值wagtailsearchpromotions以保证迁移连续性。文档中提到的SearchPromotion模型定义在 wagtail/contrib/search_promotions/models.py#L101配套的表单、视图与后台钩子分别位于 wagtail/contrib/search_promotions/forms.py、wagtail/contrib/search_promotions/views/settings.py 和 wagtail/contrib/search_promotions/wagtail_hooks.py其使用文档见 docs/reference/contrib/searchpromotions.md。3. Elasticsearch 索引的原子重建ATOMIC_REBUILD实验特性1.1 的 Elasticsearch 搜索后端接受一个实验性的ATOMIC_REBUILD标志开启后update_index任务运行期间旧索引仍然可供查询通过建新索引 切换别名的方式实现重建期间的服务不中断。文档将其标注为 experimental并引用了wagtailsearch_backends_atomic_rebuild文档锚点。从当前仓库的证据看这一标志如今仅存在于历史发布说明与 CHANGELOG.txt 中例如 1.11/1.12.x 曾修复过其与新版 Elasticsearch 客户端的别名处理兼容性当前 Elasticsearch 后端代码中已不再提供该配置项。可以推断随着搜索后端的多次重构这一早期实验特性已被后续实现所取代对 1.1 使用者而言它代表的重建期间索引持续可用这一设计目标在后续版本中由其他机制承接。4. wagtailapi 模块重构到 Django REST Framework 之上1.1 中wagtail.contrib.wagtailapi模块改用 Django REST Framework 构建并首次随附一套可复用的序列化器库供开发者在自己的 DRF 项目中直接调用。发布说明明确No user-facing changes have been made——即对最终 API 使用者的接口形态没有变化同时表达了未来支持 browsable API 等更多 DRF 特性的期望。从源码演进脉络看这条路线一直延续至今当前仓库的公开内容 API 已发展到 wagtail/api/v2/ 与 wagtail/api/v3/而后台自身的页面 APIwagtail/admin/api/同样基于 DRF 序列化器见 wagtail/admin/api/serializers.py。1.1 确立的API 层交给 DRF决策是今天 Wagtail API 子系统的直接起点。5. 后台权限体系修复1.1 修复了后台界面中多处权限不一致清单包括移除User profile的全部权限原本未被使用移除图片和文档的 delete 权限原本未被使用用户现只需持有 change 权限即可访问图片与文档此前还需要 add 权限Users 的权限现在取自自定义 user model若已配置而不再总是硬编码使用 Django 内置 User 模型的权限Groups 与 Users 现在对其各自的 add、change、delete 权限表现一致。这些修复针对的是 1.0 时代wagtail start模板与 Django 权限框架交互时的若干死权限与隐性门槛。对自定义用户模型的项目尤其重要Wagtail 后台从 1.1 起正式尊重项目AUTH_USER_MODEL的权限配置这一行为一直保留到当前版本的用户权限管理实现wagtail/users/。6. 可搜索的 Snippets继承自wagtail.wagtailsearch.index.Indexed的 snippet 模型如今会在 snippet 选择器chooser和列表页上获得搜索框。在当前仓库中snippets 功能已从早期的 contrib 地位提升为内置的独立应用 wagtail/snippets/而搜索入口的接入依赖于 1.1 时期确立的模型实现Indexed即可被搜索框架发现这一约定——搜索框架核心位于 wagtail/search/其注册机制允许任何实现了Indexed接口的模型Page 或 Snippet接入统一的索引与检索体系。次要特性清单Minor features1.1 的次要特性较多以下完整继承发布说明原文并在涉及当前仓库实现处给出佐证路径实现了表单提交form submissions的删除功能页面选择器模态框page chooser modal实现分页项目模板project template中的INSTALLED_APPS改为按优先级顺序precedence order排列应用{% image %}模板标签支持对图片变量施加过滤器例如{% image primary_img|default:secondary_img width-500 %}——即先按default回退选择图片再对其做width-500规格渲染风格指南style guide菜单项移入 Settings 子菜单搜索后端可以按模块路径如wagtail.wagtailsearch.backends.elasticsearch而非具体类...elasticsearch.ElasticSearch配置API 新增descendant_of过滤器。当前后台 API 中该过滤器仍然可用见 wagtail/admin/api/views.py#L100 对child_of/descendant_of的说明以及 wagtail/admin/api/serializers.py#L79-L93 中以?descendant_of2为例的子页面计数与分页链接生成wagtail start命令新增可选目录参数允许指定新项目生成位置非超级用户在持有相应权限时可查看/编辑/删除站点sites图片文件大小file size开始存入数据库避免不必要的文件系统查询页面 URL 查找命中缓存/数据库的频率降低后台 URL 全面改用 namespaced URLupdate_index任务改为按 1000 条一批索引以便展示进度并控制内存占用为PageRevision和Image增加数据库索引改善大型站点性能页面选择器中的搜索改用 Wagtail 搜索框架使结果按相关度排序PageChooserPanel支持传入页面类型列表list/tuple作为可接受类型SnippetChooserPanel的 snippet 类型参数可省略或传模型名字符串而不必传模型类为self模板变量增加别名以适配 Jinja2 模板引擎页面对象用page、字段面板/编辑处理器用field_panel、块block用value页面浏览器explorer增加引导文案提示编辑者除非在建站否则不应在根层级创建页面组页面权限表单中页面字段上的 Clear choice 与 Edit this page 按钮被移除Stream 控件的样式调整为与其他按钮一致新增is_creatable标志可标记某页面模型不允许在后台创建抽象abstractDjango 模型的页面自动视为不可创建新增挪威博克马尔语Norwegian Bokmål与冰岛语Icelandic翻译。其中is_creatable的当前实现可见于 wagtail/models/pages.py#L330-L334页面元类在类构建时按是否显式声明is_creatable、是否抽象、是否为基类Page本身计算默认值wagtail/models/pages.py#L1695 的can_create判断则是该类型是否允许在指定父节点下创建的入口相关测试见 wagtail/tests/test_page_model.py#L3500-L3511 与 wagtail/admin/tests/pages/test_create_page.py#L344-L345。缺陷修复清单Bug fixes发布说明列出的 13 项修复如下完整继承原文页面编辑器中非默认标签页里的文本域现在能正确调整高度富文本编辑器插入链接模态框中的标签页不再消失贡献者Tim Heap富文本字段中的 H2 元素在放入可折叠多字段面板collapsible multi field panel时被误加click()绑定的问题被修复wagtailimages模块现在兼容不允许重开已关闭文件的远程存储后端自动索引没有id字段的模型时搜索不再崩溃wagtailfrontendcache模块的 HTTP 后端被重写可靠地把请求转发到配置的缓存主机名使用 fill 过滤器缩放单像素图片时不再抛出ZeroDivisionError或 tile cannot extend outside image 错误数据库搜索后端search操作返回的 QuerySet 现在正确保留原查询的附加属性如prefetch_related/select_related外部图片 URL 生成器external image URL generator的响应被正确标记为流式streaming与 Django 缓存中间件配合时不再失败使用多重继承的页面现在可以正常复制page copy表单构建器form builder页面现在会读取get_context方法中定义的模板变量复制页面时页面修订记录page revision records中子对象的 ID 此前没有被重映射到新对象——这会导致编辑新页面时原页面上这些对象丢失现已修复新增的重定向redirect现在对所有站点生效而不仅是访问 Wagtail 后台所经由的那个站点添加用户Add user表单在校验失败时不再抛出硬错误hard error。其中与页面复制相关的两项多重继承支持、修订记录子对象 ID 重映射在 1.1 之后被进一步抽象为动作action体系当前仓库中页面复制的核心逻辑位于 wagtail/actions/copy_page.py它依然处理目标节点不能是源页面自身或其后代等约束见 wagtail/actions/copy_page.py#L87 处的is_descendant_of校验1.1 修复的正是这类复制语义的边界情况。升级注意事项Upgrade considerations1. 推广搜索结果不再默认启用由于该功能移入 contrib 模块升级到 1.1 后需手动重新启用在INSTALLED_APPS中加入wagtail.contrib.wagtailsearchpromotions原文档给出的配置示例INSTALLED_APPS [ ... wagtail.contrib.wagtailsearchpromotions, ... ]如果项目代码中引用了旧模型wagtail.wagtailsearch.models.EditorsPick必须改为wagtail.contrib.wagtailsearchpromotions.models.SearchPromotion。文档特别提示使用 Wagtail 1.0 的wagtail start命令创建的项目其search/views.py中通常含有对EditorsPick的引用需要一并更新。当前仓库中该模型的最终形态即 wagtail/contrib/search_promotions/models.py#L101 的SearchPromotion早期迁移见 wagtail/contrib/search_promotions/migrations/0001_initial.py。2.is_abstract标志被is_creatable取代1.1 之前页面模型上存在一个未文档化的is_abstract标志用于表示不应出现在可创建页面类型列表中典型场景仅供子类继承、不直接使用的基类页面模型。由于它与 DjangoMeta.abstract是两回事且容易混淆1.1 将其替换为语义更清晰的is_creatable。升级操作若你在任何模型上写过is_abstract True应改为is_creatable False如果模型本身就是 Django 意义上的抽象模型Meta中abstract True则无需添加该标志——此类模型本就不应出现在创建入口。从当前源码结构看这一约定已固化在页面元类中wagtail/models/pages.py#L330-L334 显示只有当类未显式声明is_creatable时才会按not cls._meta.abstract and cls is not base_page_model推导默认值——即Django 抽象模型自动不可创建的 1.1 规则沿用至今。测试 wagtail/tests/test_page_model.py#L3500-L3511 验证了默认值、显式is_creatable False以及该标志不被继承三种行为对应 wagtail/test/testapp/models.py#L2055 中is_creatable False的测试模型。结语从 1.1 看 Wagtail 的机制传承Wagtail 1.1 的发布说明篇幅不长但几乎每一条都指向此后多年仍在仓库中活跃的代码路径specific()的分组子查询机制wagtail/query.py、作为 contrib 模块推广的搜索推广wagtail/contrib/search_promotions/、建立在 DRF 之上的 API 层wagtail/api/v2/、wagtail/api/v3/、尊重自定义用户模型的权限体系、以及is_creatable标志wagtail/models/pages.py。理解这一版本等于理解了当前 Wagtail 查询层、搜索层与 API 层的共同起点而对于仍在使用旧版本的维护者两条升级注意事项SearchPromotion模型迁移与is_creatable替换至今仍是阅读该版本说明时最需要核对的操作项。【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址: https://gitcode.com/GitHub_Trending/wa/wagtail创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
