通过浏览器后退按钮访问表单未触发 "Confirm form resubmit"
Accessing form via browser back button is not triggering "Confirm form resubmit"
我有一个由 MediaWiki 提供支持的公司 Wiki。我编写了代码来添加页面锁定功能，这样当用户编辑页面时，他们会在页面上获得 15 分钟的锁定时间，他们可以在过期前的任何时候续订。
如果用户编辑了一个页面，然后点击保存，然后点击浏览器的后退按钮 return 到编辑表单，一切看起来都很正常，用户认为一切都很好，但问题在于：它不会在页面上创建新锁。告诉用户页面上有锁的消息，但我认为这只是因为它是页面的缓存版本；消息中的过期时间是他们第一次编辑时锁定的过期时间，不是使用后退按钮。
我尝试在 head 标签内的页面中添加 HTML meta 标签以使 cache/not 缓存编辑页面无效，但这不起作用因为 MediaWiki PHP 页面生成器覆盖了它。
现在我有一个非常草率的修复；我使用 JavaScript 来模拟按下浏览器前进按钮，例如在编辑页面上向前推进历史。如果不存在较新的历史记录项（例如，他们单击了实际的 "edit" 按钮而不是使用浏览器后退按钮）它什么都不做，但是如果他们通过后退按钮访问编辑页面，它会短暂显示页面大约一秒钟，直到 JavaScript 加载，然后在历史记录中向前重定向（将它们放回到点击后退按钮之前的位置）。是的，这可行，但在我看来，这是一个非常糟糕的解决方案，因为它不是很 seamless/user 友好，可能会使用户感到困惑或让他们认为他们的浏览器有问题。
更好的解决方案是强制用户重新提交表单，从而打开编辑页面的 "fresh" 版本，实际上我不确定为什么它还没有这样做。我的意思是，当用户通过浏览器后退按钮访问编辑页面时，我希望它显示 "Confirm Form Resubmit" 错误页面。 Google Chrome 例如：
我认为这将通过强制重新提交表单来解决问题，我相信这将创建一个 actual 页面锁定。如果我错了请纠正我。
我不认为很多页面锁定代码是非常相关的，因为问题的原因只是后退按钮将它们带到页面的缓存版本而不是 "fresh"版本，但如果您不这么认为，请随时索取。请告诉我 post 的代码部分，我会添加它们。
我认为@devpro 的评论与你的问题有关，但它的意思应该反过来。 Mediawiki 已经 具有防止用户在稍后单击 "refresh" 或 "back" 按钮时看到 "resubmit" 警告的机制 - 在提交表单后，它会重定向用户 (通过 302 重定向）到被编辑的页面。
这样，如果用户决定在编辑后立即刷新页面，或者如果他发布了表单，然后导航到另一个页面并按下 "back" 按钮 - 他将不会再次重新提交表单。
改变这种行为几乎是不可能的（它深深地埋藏在 Mediawiki 核心中），但是，如果可能的话——你不应该这样做，除非你想让你的编辑完全困惑。
后端没有解决方案，因为表单页面是从浏览器缓存加载的，但是您仍然可以使用 js 来防止这种情况，而 Mediawiki JS 接口可以帮助解决这个问题：
创建将 JS 脚本添加到 'view' 操作的扩展，使其跟踪变量 wgPostEdit（see more) which gets populated only after page was saved. Once this variable is set - use this trick 在用户尝试返回时显示警告。
找到一些可以为您提供 OuputPage 的挂钩（我不太熟悉它们，但也许 OutputPageBeforeHTML？）并在编辑页面上调用 OuputPage::enableClientCache(false)。
我有一个由 MediaWiki 提供支持的公司 Wiki。我编写了代码来添加页面锁定功能，这样当用户编辑页面时，他们会在页面上获得 15 分钟的锁定时间，他们可以在过期前的任何时候续订。
如果用户编辑了一个页面，然后点击保存，然后点击浏览器的后退按钮 return 到编辑表单，一切看起来都很正常，用户认为一切都很好，但问题在于：它不会在页面上创建新锁。告诉用户页面上有锁的消息，但我认为这只是因为它是页面的缓存版本；消息中的过期时间是他们第一次编辑时锁定的过期时间，不是使用后退按钮。
我尝试在 head 标签内的页面中添加 HTML meta 标签以使 cache/not 缓存编辑页面无效，但这不起作用因为 MediaWiki PHP 页面生成器覆盖了它。
现在我有一个非常草率的修复；我使用 JavaScript 来模拟按下浏览器前进按钮，例如在编辑页面上向前推进历史。如果不存在较新的历史记录项（例如，他们单击了实际的 "edit" 按钮而不是使用浏览器后退按钮）它什么都不做，但是如果他们通过后退按钮访问编辑页面，它会短暂显示页面大约一秒钟，直到 JavaScript 加载，然后在历史记录中向前重定向（将它们放回到点击后退按钮之前的位置）。是的，这可行，但在我看来，这是一个非常糟糕的解决方案，因为它不是很 seamless/user 友好，可能会使用户感到困惑或让他们认为他们的浏览器有问题。
更好的解决方案是强制用户重新提交表单，从而打开编辑页面的 "fresh" 版本，实际上我不确定为什么它还没有这样做。我的意思是，当用户通过浏览器后退按钮访问编辑页面时，我希望它显示 "Confirm Form Resubmit" 错误页面。 Google Chrome 例如：
我认为这将通过强制重新提交表单来解决问题，我相信这将创建一个 actual 页面锁定。如果我错了请纠正我。
我不认为很多页面锁定代码是非常相关的，因为问题的原因只是后退按钮将它们带到页面的缓存版本而不是 "fresh"版本，但如果您不这么认为，请随时索取。请告诉我 post 的代码部分，我会添加它们。
我认为@devpro 的评论与你的问题有关，但它的意思应该反过来。 Mediawiki 已经 具有防止用户在稍后单击 "refresh" 或 "back" 按钮时看到 "resubmit" 警告的机制 - 在提交表单后，它会重定向用户 (通过 302 重定向）到被编辑的页面。
这样，如果用户决定在编辑后立即刷新页面，或者如果他发布了表单，然后导航到另一个页面并按下 "back" 按钮 - 他将不会再次重新提交表单。
改变这种行为几乎是不可能的（它深深地埋藏在 Mediawiki 核心中），但是，如果可能的话——你不应该这样做，除非你想让你的编辑完全困惑。
后端没有解决方案，因为表单页面是从浏览器缓存加载的，但是您仍然可以使用 js 来防止这种情况，而 Mediawiki JS 接口可以帮助解决这个问题：
创建将 JS 脚本添加到 'view' 操作的扩展，使其跟踪变量 wgPostEdit（see more) which gets populated only after page was saved. Once this variable is set - use this trick 在用户尝试返回时显示警告。
找到一些可以为您提供 OuputPage 的挂钩（我不太熟悉它们，但也许 OutputPageBeforeHTML？）并在编辑页面上调用 OuputPage::enableClientCache(false)。