尧图网站建设 
CMS后端【免费下载链接】django-cmsThe easy-to-use and developer-friendly enterprise CMS powered by Django项目地址https://gitcode.com/gh_mirrors/dj/django-cms点击查看免费下载django CMS 2.2 是一次以工程化收敛为核心的版本升级它把django-mptt从内嵌代码改为正式外部依赖、用django-sekizai取代旧的插件媒体框架、把工具栏渲染方式从中间件注入改为模板标签显式输出并首次为页面引入面向用户与用户组的查看权限View permissions。本文以官方 2.2 release notes 为主线结合当前仓库源码逐条拆解每一项变更的动机、影响面与升级操作帮助你在升级前完成依赖清理、模板改造与权限规划。阅读本文后你将能够按官方流程移除旧mptt包并安装django-mptt 0.5.1将模板迁移到django-sekizai的js/css命名空间与{% cms_toolbar %}标签理解页面查看权限在底层模型与判定函数中的实现方式并对照 2.2 中所有向后不兼容变更清单完成自查。一、2.2 新特性一览django-mptt 成为正式依赖版本冲突成为历史2.2 之前django CMS 将 django-mptt 的代码直接打包在自身发行版中导致任何同时使用 django CMS 与其他依赖 django-mptt 应用的 Django 项目都极易出现版本冲突。2.2 起 django-mptt 被改为正式的外部依赖由setup.py在安装时自动拉取django CMS 2.2 要求django-mptt 0.5.1。升级必做在升级前务必手动删除 Python site-packages 目录中的旧mptt包否则旧代码会与新安装的django-mptt并存造成重复模块注册问题。官方给出的删除位置是site-packages/mptt目录。从当前仓库看mptt 仍然支撑着页面树的层级结构操作。例如 cms/utils/mptree.py 封装了树操作工具cms/test_utils/runners.py 等测试基础设施也依赖它完成测试数据构造。可见它至今仍是 django CMS 树形结构的地基2.2 把这块地基从内嵌改为外引是为了让生态内所有应用共享同一个权威版本。Django 1.3 支持django CMS 2.2 同时支持Django 1.2.5 与 Django 1.3。其中 Django 1.3 带来的django.contrib.staticfiles应用是本次静态文件目录迁移见下文的直接驱动力。页面查看权限View permissions2.2 首次允许你为**用户users和用户组groups**授予 django CMS 页面的前端查看权限。这是权限模型的一次实质扩充其底层设计一直延续至今可以在当前仓库中看到完整的实现。在 cms/models/permissionmodels.py 的AbstractPagePermission抽象基类中can_view字段被定义为can_view models.BooleanField( _(can view restricted pages), defaultFalse, help_text_( Grants frontend view access. Note: as soon as any user or group is given view access to a page, that page becomes restricted — only users/groups with view access can then see it on the frontend. ), )注意help_text中强调的关键语义一旦有任何用户或用户组被授予某页面的查看权限该页面就自动变成受限页面只有被明确授权的用户/用户组才能在站点前端看到它。这解释了 2.2 之后常见的为什么我给了某个人权限其他人都看不到这个页面了的现象。AbstractPagePermission派生出的GlobalPagePermissioncms/models/permissionmodels.py与PagePermissioncms/models/permissionmodels.py分别承载全局与单页粒度的授权。页面模型的has_view_permission与has_view_restrictions方法cms/models/pagemodel.py则把判定委托给权限工具函数def has_view_permission(self, user): from cms.utils.page_permissions import user_can_view_page return user_can_view_page(user, pageself) def has_view_restrictions(self, site): restrictions PagePermission.objects.for_page(self).filter(can_viewTrue) ...最终的判定核心位于 cms/utils/page_permissions.py 的user_can_view_pagedef user_can_view_page(user, page, siteNone): ... public_for get_cms_setting(PUBLIC_FOR) can_see_unrestricted public_for all or (public_for staff and user.is_staff) is_restricted page.has_view_restrictions(site) if not is_restricted and can_see_unrestricted: # Page has no restrictions and project is configured # to allow everyone to see unrestricted pages. return True elif not user.is_authenticated: # Page has restrictions or project is configured # to require staff user status to see pages. return False ...判定逻辑依次为超级用户直接放行 → 无限制页面且PUBLIC_FOR允许所有人all或允许 staffstaff时放行 → 未登录用户一律拒绝 → 有全局查看权限则放行 → 有页面编辑权限则自动获得查看权 → 最后按页面级can_view授权精确判定。相应的PUBLIC_FOR配置项如CMS_PUBLIC_FOR all可以在 cms/tests/settings.py 中看到测试项目的设置样例。二、向后不兼容变更Backwards incompatible changesdjango-sekizai 取代 PluginMedia这是 2.2 影响面最大的变更。旧的插件媒体框架PluginMedia因状态不佳被整体移除取而代之的是更稳定、更灵活的django-sekizai它成为 django CMS 2.2 的新增依赖。受影响的CMSPluginBase成员定义于 cms/plugin_base.py包括cms.plugins_base.CMSPluginBase.PluginMediacms.plugins_base.CMSPluginBase.pluginmediacms.plugins_base.CMSPluginBase.get_plugin_media任何访问上述属性或方法的代码都会抛出cms.exceptions.Deprecated异常——该异常类定义在 cms/exceptions.pyclass Deprecated(Exception): pass同时被移除的还有cms.middleware.media.PlaceholderMediaMiddleware中间件。但作为替代你必须在TEMPLATE_CONTEXT_PROCESSORS设置中加入 sekizai 的上下文处理器TEMPLATE_CONTEXT_PROCESSORS [ ... sekizai.context_processors.sekizai, ... ]并且CMS_TEMPLATES中列出的所有模板都必须至少包含js与css两个 sekizai 命名空间典型的模板骨架如下{% load cms_tags sekizai_tags %} html head {% render_block css %} /head body {% cms_toolbar %} ... {% render_block js %} /body /html{% render_block css %}/{% render_block js %}是 sekizai 的区块输出标签插件与工具栏声明的 CSS/JS 资源会在渲染时被集中收集并注入到这两个位置。当前仓库中工具栏模板 cms/templates/cms/toolbar/structure.html 依然沿用这一机制{% render_block css %} ... {% render_block js %}cms_tags模板标签库与 sekizai 的集成也在源码中有直接体现CMSToolbar标签继承自 sekizai 的RenderBlock并复用SekizaiParser见 cms/templatetags/cms_tags.py 与同文件第 34 行的from sekizai.templatetags.sekizai_tags import RenderBlock, SekizaiParser。关于自定义插件如何在新框架下处理媒体资源可参考 docs/how_to/09-custom_plugins.rst 中的插件编写指南。工具栏必须在模板中显式启用2.2 之前工具栏由中间件在响应阶段偷偷注入到 HTML 中这导致工具栏出现在很多本不该出现的地方。2.2 起这一行为被彻底移除工具栏必须通过cms_tags标签库中的{% cms_toolbar %}模板标签在模板中显式启用并且应放在 HTML 的body.../body内部{% load cms_tags %} body {% cms_toolbar %} ... /bodyCMSToolbar标签的现代实现cms/templatetags/cms_tags.py逻辑为从context[request]获取工具栏实例仅在toolbar.show_toolbar为真时执行toolbar.init_toolbar(request)并渲染工具栏结构否则原样渲染 nodelist。这保证了非编辑状态下页面开销最小也杜绝了误注入。静态文件迁移到 /static/静态文件CSS/JavaScript/图片从/media/迁移到了/static/以配合 Django 1.3 新增的django.contrib.staticfiles应用。这意味着你的服务器必须同时托管 static 文件与 media 文件二者的 URL 前缀与文件系统位置不同。Django 1.2.x 用户特别注意1.2 没有django.contrib.staticfiles需要安装django-staticfiles反向移植包backport来提供等价能力。当前仓库的静态资源按static/cms/组织例如 cms/static/cms/css、cms/static/cms/js、cms/static/cms/img并可通过 Django 的collectstatic机制收集发布。三、2.2 中弃用的特性django-dbgettext 支持被彻底移除django-dbgettext数据库级 gettext 方案的支持在 2.2 中被完全移除多语言能力统一收敛到 django CMS 内置的多语言机制CMS_LANGUAGES、djangocms-admin-style与django-parler等生态组件共同支撑的国际化体系。如果你此前依赖 dbgettext 做翻译升级 2.2 前需要完成翻译数据的迁移改用内置多语言能力。四、升级核对清单综合 2.2 release notes升级到 django CMS 2.2 前请逐项核对检查项操作说明依赖清理删除 site-packages 中的旧mptt目录避免与django-mptt 0.5.1冲突依赖安装安装 django-mptt 0.5.1、django-sekizai2.2 的新增外部依赖由setup.py声明上下文处理器加入sekizai.context_processors.sekizai缺少会导致 sekizai 标签无法工作模板改造所有CMS_TEMPLATES模板补上{% render_block css %}与{% render_block js %}缺少命名空间会抛错或丢失资源工具栏在body内显式添加{% cms_toolbar %}不再由中间件自动注入中间件移除PlaceholderMediaMiddleware2.2 已删除该中间件插件代码检查自定义插件是否引用PluginMedia/pluginmedia/get_plugin_media访问将抛出cms.exceptions.Deprecated静态文件服务器同时托管/static/与/media/Django 1.2.x 需装django-staticfiles反向移植国际化迁移 dbgettext 翻译数据到内置多语言机制dbgettext 支持已被移除五、延伸阅读页面权限体系的现代实现cms/models/permissionmodels.py、cms/utils/page_permissions.py工具栏标签与 sekizai 集成cms/templatetags/cms_tags.py、cms/templates/cms/toolbar/structure.html异常体系含Deprecatedcms/exceptions.py插件开发与媒体处理docs/how_to/09-custom_plugins.rst其他升级版本说明docs/upgrade/index.rst赞分享CMS后端【免费下载链接】django-cmsThe easy-to-use and developer-friendly enterprise CMS powered by Django项目地址https://gitcode.com/gh_mirrors/dj/django-cms点击查看免费下载相关推荐django CMS 3.1.1 升级指南新功能、工具栏配置项与向后不兼容变更深度解析django CMS 3.1.1 升级指南新功能、工具栏配置项与向后不兼容变更深度解析 本指南以 django CMS 官方 3.1.1 版本发布说明 doCMS后端mold 依赖解析oneTBB API/ABI 变更日志全解读与升级兼容性指南mold 依赖解析oneTBB API/ABI 变更日志全解读与升级兼容性指南 oneTBBoneAPI Threading Building Blocks开发工具构建工具系统编程Apache DolphinScheduler 升级避坑指南3.0.0 至 3.5.0 不向前兼容变更全解析Apache DolphinScheduler 升级避坑指南3.0.0 至 3.5.0 不向前兼容变更全解析 本文以 Apache DolphinSchedu任务调度数据编排工作流自动化后端大数据上一篇魔兽争霸3卡顿闪退终极解决方案Warcraft Helper完全指南下一篇魔兽争霸3玩家必看告别画面拉伸与卡顿的终极优化指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 django CMS 2.2 升级指南：依赖重构、权限增强与向后不兼容变更全解析
CMS后端【免费下载链接】django-cmsThe easy-to-use and developer-friendly enterprise CMS powered by Django项目地址https://gitcode.com/gh_mirrors/dj/django-cms点击查看免费下载django CMS 2.2 是一次以工程化收敛为核心的版本升级它把django-mptt从内嵌代码改为正式外部依赖、用django-sekizai取代旧的插件媒体框架、把工具栏渲染方式从中间件注入改为模板标签显式输出并首次为页面引入面向用户与用户组的查看权限View permissions。本文以官方 2.2 release notes 为主线结合当前仓库源码逐条拆解每一项变更的动机、影响面与升级操作帮助你在升级前完成依赖清理、模板改造与权限规划。阅读本文后你将能够按官方流程移除旧mptt包并安装django-mptt 0.5.1将模板迁移到django-sekizai的js/css命名空间与{% cms_toolbar %}标签理解页面查看权限在底层模型与判定函数中的实现方式并对照 2.2 中所有向后不兼容变更清单完成自查。一、2.2 新特性一览django-mptt 成为正式依赖版本冲突成为历史2.2 之前django CMS 将 django-mptt 的代码直接打包在自身发行版中导致任何同时使用 django CMS 与其他依赖 django-mptt 应用的 Django 项目都极易出现版本冲突。2.2 起 django-mptt 被改为正式的外部依赖由setup.py在安装时自动拉取django CMS 2.2 要求django-mptt 0.5.1。升级必做在升级前务必手动删除 Python site-packages 目录中的旧mptt包否则旧代码会与新安装的django-mptt并存造成重复模块注册问题。官方给出的删除位置是site-packages/mptt目录。从当前仓库看mptt 仍然支撑着页面树的层级结构操作。例如 cms/utils/mptree.py 封装了树操作工具cms/test_utils/runners.py 等测试基础设施也依赖它完成测试数据构造。可见它至今仍是 django CMS 树形结构的地基2.2 把这块地基从内嵌改为外引是为了让生态内所有应用共享同一个权威版本。Django 1.3 支持django CMS 2.2 同时支持Django 1.2.5 与 Django 1.3。其中 Django 1.3 带来的django.contrib.staticfiles应用是本次静态文件目录迁移见下文的直接驱动力。页面查看权限View permissions2.2 首次允许你为**用户users和用户组groups**授予 django CMS 页面的前端查看权限。这是权限模型的一次实质扩充其底层设计一直延续至今可以在当前仓库中看到完整的实现。在 cms/models/permissionmodels.py 的AbstractPagePermission抽象基类中can_view字段被定义为can_view models.BooleanField( _(can view restricted pages), defaultFalse, help_text_( Grants frontend view access. Note: as soon as any user or group is given view access to a page, that page becomes restricted — only users/groups with view access can then see it on the frontend. ), )注意help_text中强调的关键语义一旦有任何用户或用户组被授予某页面的查看权限该页面就自动变成受限页面只有被明确授权的用户/用户组才能在站点前端看到它。这解释了 2.2 之后常见的为什么我给了某个人权限其他人都看不到这个页面了的现象。AbstractPagePermission派生出的GlobalPagePermissioncms/models/permissionmodels.py与PagePermissioncms/models/permissionmodels.py分别承载全局与单页粒度的授权。页面模型的has_view_permission与has_view_restrictions方法cms/models/pagemodel.py则把判定委托给权限工具函数def has_view_permission(self, user): from cms.utils.page_permissions import user_can_view_page return user_can_view_page(user, pageself) def has_view_restrictions(self, site): restrictions PagePermission.objects.for_page(self).filter(can_viewTrue) ...最终的判定核心位于 cms/utils/page_permissions.py 的user_can_view_pagedef user_can_view_page(user, page, siteNone): ... public_for get_cms_setting(PUBLIC_FOR) can_see_unrestricted public_for all or (public_for staff and user.is_staff) is_restricted page.has_view_restrictions(site) if not is_restricted and can_see_unrestricted: # Page has no restrictions and project is configured # to allow everyone to see unrestricted pages. return True elif not user.is_authenticated: # Page has restrictions or project is configured # to require staff user status to see pages. return False ...判定逻辑依次为超级用户直接放行 → 无限制页面且PUBLIC_FOR允许所有人all或允许 staffstaff时放行 → 未登录用户一律拒绝 → 有全局查看权限则放行 → 有页面编辑权限则自动获得查看权 → 最后按页面级can_view授权精确判定。相应的PUBLIC_FOR配置项如CMS_PUBLIC_FOR all可以在 cms/tests/settings.py 中看到测试项目的设置样例。二、向后不兼容变更Backwards incompatible changesdjango-sekizai 取代 PluginMedia这是 2.2 影响面最大的变更。旧的插件媒体框架PluginMedia因状态不佳被整体移除取而代之的是更稳定、更灵活的django-sekizai它成为 django CMS 2.2 的新增依赖。受影响的CMSPluginBase成员定义于 cms/plugin_base.py包括cms.plugins_base.CMSPluginBase.PluginMediacms.plugins_base.CMSPluginBase.pluginmediacms.plugins_base.CMSPluginBase.get_plugin_media任何访问上述属性或方法的代码都会抛出cms.exceptions.Deprecated异常——该异常类定义在 cms/exceptions.pyclass Deprecated(Exception): pass同时被移除的还有cms.middleware.media.PlaceholderMediaMiddleware中间件。但作为替代你必须在TEMPLATE_CONTEXT_PROCESSORS设置中加入 sekizai 的上下文处理器TEMPLATE_CONTEXT_PROCESSORS [ ... sekizai.context_processors.sekizai, ... ]并且CMS_TEMPLATES中列出的所有模板都必须至少包含js与css两个 sekizai 命名空间典型的模板骨架如下{% load cms_tags sekizai_tags %} html head {% render_block css %} /head body {% cms_toolbar %} ... {% render_block js %} /body /html{% render_block css %}/{% render_block js %}是 sekizai 的区块输出标签插件与工具栏声明的 CSS/JS 资源会在渲染时被集中收集并注入到这两个位置。当前仓库中工具栏模板 cms/templates/cms/toolbar/structure.html 依然沿用这一机制{% render_block css %} ... {% render_block js %}cms_tags模板标签库与 sekizai 的集成也在源码中有直接体现CMSToolbar标签继承自 sekizai 的RenderBlock并复用SekizaiParser见 cms/templatetags/cms_tags.py 与同文件第 34 行的from sekizai.templatetags.sekizai_tags import RenderBlock, SekizaiParser。关于自定义插件如何在新框架下处理媒体资源可参考 docs/how_to/09-custom_plugins.rst 中的插件编写指南。工具栏必须在模板中显式启用2.2 之前工具栏由中间件在响应阶段偷偷注入到 HTML 中这导致工具栏出现在很多本不该出现的地方。2.2 起这一行为被彻底移除工具栏必须通过cms_tags标签库中的{% cms_toolbar %}模板标签在模板中显式启用并且应放在 HTML 的body.../body内部{% load cms_tags %} body {% cms_toolbar %} ... /bodyCMSToolbar标签的现代实现cms/templatetags/cms_tags.py逻辑为从context[request]获取工具栏实例仅在toolbar.show_toolbar为真时执行toolbar.init_toolbar(request)并渲染工具栏结构否则原样渲染 nodelist。这保证了非编辑状态下页面开销最小也杜绝了误注入。静态文件迁移到 /static/静态文件CSS/JavaScript/图片从/media/迁移到了/static/以配合 Django 1.3 新增的django.contrib.staticfiles应用。这意味着你的服务器必须同时托管 static 文件与 media 文件二者的 URL 前缀与文件系统位置不同。Django 1.2.x 用户特别注意1.2 没有django.contrib.staticfiles需要安装django-staticfiles反向移植包backport来提供等价能力。当前仓库的静态资源按static/cms/组织例如 cms/static/cms/css、cms/static/cms/js、cms/static/cms/img并可通过 Django 的collectstatic机制收集发布。三、2.2 中弃用的特性django-dbgettext 支持被彻底移除django-dbgettext数据库级 gettext 方案的支持在 2.2 中被完全移除多语言能力统一收敛到 django CMS 内置的多语言机制CMS_LANGUAGES、djangocms-admin-style与django-parler等生态组件共同支撑的国际化体系。如果你此前依赖 dbgettext 做翻译升级 2.2 前需要完成翻译数据的迁移改用内置多语言能力。四、升级核对清单综合 2.2 release notes升级到 django CMS 2.2 前请逐项核对检查项操作说明依赖清理删除 site-packages 中的旧mptt目录避免与django-mptt 0.5.1冲突依赖安装安装 django-mptt 0.5.1、django-sekizai2.2 的新增外部依赖由setup.py声明上下文处理器加入sekizai.context_processors.sekizai缺少会导致 sekizai 标签无法工作模板改造所有CMS_TEMPLATES模板补上{% render_block css %}与{% render_block js %}缺少命名空间会抛错或丢失资源工具栏在body内显式添加{% cms_toolbar %}不再由中间件自动注入中间件移除PlaceholderMediaMiddleware2.2 已删除该中间件插件代码检查自定义插件是否引用PluginMedia/pluginmedia/get_plugin_media访问将抛出cms.exceptions.Deprecated静态文件服务器同时托管/static/与/media/Django 1.2.x 需装django-staticfiles反向移植国际化迁移 dbgettext 翻译数据到内置多语言机制dbgettext 支持已被移除五、延伸阅读页面权限体系的现代实现cms/models/permissionmodels.py、cms/utils/page_permissions.py工具栏标签与 sekizai 集成cms/templatetags/cms_tags.py、cms/templates/cms/toolbar/structure.html异常体系含Deprecatedcms/exceptions.py插件开发与媒体处理docs/how_to/09-custom_plugins.rst其他升级版本说明docs/upgrade/index.rst赞分享CMS后端【免费下载链接】django-cmsThe easy-to-use and developer-friendly enterprise CMS powered by Django项目地址https://gitcode.com/gh_mirrors/dj/django-cms点击查看免费下载相关推荐django CMS 3.1.1 升级指南新功能、工具栏配置项与向后不兼容变更深度解析django CMS 3.1.1 升级指南新功能、工具栏配置项与向后不兼容变更深度解析 本指南以 django CMS 官方 3.1.1 版本发布说明 doCMS后端mold 依赖解析oneTBB API/ABI 变更日志全解读与升级兼容性指南mold 依赖解析oneTBB API/ABI 变更日志全解读与升级兼容性指南 oneTBBoneAPI Threading Building Blocks开发工具构建工具系统编程Apache DolphinScheduler 升级避坑指南3.0.0 至 3.5.0 不向前兼容变更全解析Apache DolphinScheduler 升级避坑指南3.0.0 至 3.5.0 不向前兼容变更全解析 本文以 Apache DolphinSchedu任务调度数据编排工作流自动化后端大数据上一篇魔兽争霸3卡顿闪退终极解决方案Warcraft Helper完全指南下一篇魔兽争霸3玩家必看告别画面拉伸与卡顿的终极优化指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考