Greasemonkey: 添加备份/恢复

创建于 2017-12-05  ·  29评论  ·  资料来源: greasemonkey/greasemonkey

使用旧的greasemonkey,实际上不需要导出脚本/首选项功能,因为用户只需将gm_scripts 目录从一个配置文件/计算机移动到另一个配置文件/计算机:但现在这不再可能,因此请考虑将这样的功能添加到greasemonkey 4将来。

最有用的评论

所以我实现了三种不同的导入方法。

  1. 合并。 不要接触任何已安装的脚本。 只有当前不存在的脚本[1] 才会被添加到数据库中。
  2. 代替。 卸载所有当前脚本并将它们替换为导入的脚本。
  3. 覆盖。 与合并类似,但如果发现冲突[1],则导入的脚本优先。

在提交之前等待其他 PR。

[1] 我通过脚本的id确定唯一性。

所有29条评论

好吧,Firefox 及其问题。 所以,我正在实现这个(当然还有一个“导入”功能)。 我快完成了,但有一个阻碍。 它仅在您打开browser toolbox并选择“不自动关闭弹出窗口”时才有效。 导入是通过<input type="file"> (这是唯一的方法),但是,在浏览窗口的焦点上,弹出窗口通常会关闭,因此窗口被破坏并且没有执行任何功能。 相关错误:
https://bugzilla.mozilla.org/show_bug.cgi?id=1292701
https://bugzilla.mozilla.org/show_bug.cgi?id=1366330

在一个半途而废的环境中工作真是太烦人了。

也适用于#2612。 哪个可以同时解决这个问题。

@Sxderp如果弹出窗口关闭是一个问题,解决/变通的正常方法是打开一个选项卡或窗口(指向扩展中的 HTML 页面),您可以在其中执行您需要执行的任何操作。 此类选项卡/窗口不会自动关闭并呈现与弹出窗口相同的环境。 虽然这可能不像在浏览器弹出窗口中那样干净,但它应该是功能性的。

我可以做到。 这将涉及移动一堆代码。 有时间我再研究一下。

我已经完成了导入/导出的东西。 没有测试,也很少有错误处理。 但它有效。 不过,为了简单起见,我这样做是为了导入会覆盖整个数据库。 当然有确认提示。

我认为理想情况下,用户可以选择替换或合并导入。 Stylus 只会合并,这也是糟糕的 IME。 用户选择,使用可能有效的默认值,似乎是最好的。

当然,但后来我们遇到了很多条件。 我想看一个关于合并的 _exact_ 性质的流程图。

主要是在冲突方面。 覆盖内容,覆盖键/值(是的,那些也被导出了),提示所有内容(这似乎是一个糟糕的用户体验),等等?

我的意思只是:导入文件中的每个脚本(并完全覆盖该状态),但不要触摸/删除不在文件中的脚本。

哦。 那要简单得多。 是的,这听起来不错。

所以我实现了三种不同的导入方法。

  1. 合并。 不要接触任何已安装的脚本。 只有当前不存在的脚本[1] 才会被添加到数据库中。
  2. 代替。 卸载所有当前脚本并将它们替换为导入的脚本。
  3. 覆盖。 与合并类似,但如果发现冲突[1],则导入的脚本优先。

在提交之前等待其他 PR。

[1] 我通过脚本的id确定唯一性。

那这个呢?

  1. 更新。 仅导入(覆盖)已存在的脚本。

这是对 1. 合并的补充

  1. 覆盖。 与合并类似,但如果发现冲突[1],则导入的脚本优先。

@Sxderp我猜,“像合并”不包括约束“仅当前不存在的脚本”......
(这个限制在这里没有意义)这意味着,覆盖 = 导入所有脚本,冲突脚本被存档覆盖......

VM、TM 或其他方式提供哪些(更新/合并/等)选项?

  1. 更新。 仅导入(覆盖)已存在的脚本。

当然,这应该是可行的。

这意味着,覆盖 = 导入所有脚本,冲突脚本被存档覆盖...

正确的。

VM、TM 或其他方式提供哪些(更新/合并/等)选项?

实际上不确定。 但这引起了我的另一个担忧。 与档案的兼容性。 假设这些插件支持完整的数据库导出(脚本 + 数据),那么理想情况下,导入应该相互兼容。

更新。 仅导入(覆盖)已存在的脚本。

现在我想到了这个(大约 3 分钟),我有一个担忧。 关联数据 (get/setValue) 怎么样? 当前存储的数据是否应该保留? 导入的数据是否应该优先? 某种合并? 然后向用户清楚地表示此选项/状态。 这实际上比乍一看要棘手一些。

做了一些快速检查,这不是 100% 彻底,但提供了一个总体概述,以及我可能应该在实施方面做出哪些改变。

VM 和 TM 都导出为 zip 文件。 在 zip 文件中,您可以找到每个脚本的.user.js文件。 但是,至于导出存储/实现特定的细节,它们的做法略有不同。 VM 将实现特定的细节和脚本数据(对于所有脚本一样)包装到单个文件violentmonkey 。 TM 更理智地做到了这一点。 每个脚本的具体实现细节被导出到.options.js文件,而脚本数据被导出到.storage.json

我想我将重新设计我的实现以遵循 TM。 总的来说,我认为这是一个更好的标准,因为它将实现细节与数据分开。

至于“导入方法”(在我上面的帖子中描述):

TM 提供了“选择每个脚本”的界面。 导入存档时,您可以选择是否要导入每个特定脚本。 如果您选中它,它将覆盖该脚本的所有数据。

VM 似乎只提供我上面描述的“覆盖”。 但是,有一个选项可以不导入关联的脚本数据(所有脚本都是全局的)。 从 UI 的角度来看,我认为在 GM 中实现该选项会很困难。 但是,如果我们采用 TM 方法导出/导入数据库,那么用户只需打开存档并删除.storage.json文件即可。

如果有人想测试,我已经更新了我的分支sxderp:import-export-database-merge ,以包含我之前讨论过的.zip功能。 我没有实现@Eselce建议的update选项,因为我仍然不确定细节。

@Sxderp感谢您开发此功能。 我已经构建了该包并将其安装在 Firefox Developer Edition 中(以便安装未签名的扩展)。 我使用该浏览器版本升级了现有的配置文件,覆盖了现有的 GreaseMonkey 安装并顺利导出了我的数据库。

但是,在安装了此 GreaseMonkey 的情况下导入新的 Firefox 配置文件会导致问题。 似乎一个非常大的特定用户脚本(user.js 和 gm_details.js 都在 230K 左右导致导入问题。更换数据库后 GM 停止工作。单击 GM 图标打开一个空下拉列表(约 10x10 平方)。

我宁愿不公开共享特定的用户脚本。 使用这个技巧,我找到了你的电子邮件地址,我会通过这种方式向你发送消息。

编辑:让 GM 在它中断后工作的唯一方法是删除扩展程序,重新启动 Firefox 并再次添加它。

GMexport_20180 2 17_164139.zip ???

从 3.4 MB 的 zip 文件中导入了一大堆(部分)大型脚本(> 20),没有任何抱怨。 虽然没有详细检查...

  return 'GMexport_'
       + date.getFullYear().toString()
       + date.getMonth().toString().padStart(2, '0')
       + date.getDate().toString().padStart(2, '0')
       + '_'
       + date.getHours().toString().padStart(2, '0')
       + date.getMinutes().toString().padStart(2, '0')
       + date.getSeconds().toString().padStart(2, '0')
       + '.zip'

IIRC, getMonth()从 0 开始... ;丢失...

IIRC, getMonth() 从 0... 开始; 失踪...

RIP

我有一段时间没有在这个分支上工作了。 我今天要重新使用 master 并进行大量清理。

我已经在 master 上重新建立了我的分支,并对布局进行了一些重大更改,我认为这提供了更好的可读性。
@ArmEagle在我更新的分支上,我能够导入您发送的文件。 如果您仍然遇到问题,请告诉我,我会进一步调查。

与 7fe8bfe94efbadeb1da1a6491aaf424fc8275f09 中的更改合并。 重新开放以跟踪/讨论我看到的一些问题。

重新开放以跟踪/讨论我看到的一些问题。

问题是什么?

是一次性快速测试,我不确定,我希望安装的一些脚本没有列出。 但我想重复一遍,仔细跟踪,写下结果。 有很多可能的情况。

我终于调查了一下。

它仅备份.user.js和“详细信息”。 碰巧不小心包含了需要的内容,但错过了资源(JSON 将 blob 序列化为{} )。 AFAICT 它将.setKnownResources()与空/破碎的斑点,因此无法工作。

如果每个脚本都有自己的文件夹看起来会更好,该文件夹包含主.user.js ,每个@require@resource ,然后可能是剩余的 parsed/自定义详细信息和存储的值。 我认为这甚至可能更好,以至于我会放弃任何跨平台兼容性。

完全同意。 就像将文档保存为“网页”一样,这将创建一个htm -document 加上一个具有相同(基本)名称的文件夹和依赖项...

碰巧不小心包含了需要的内容......

不是偶然的。 有意包括它,用于可能发生的任何本地更改。 我将资源/要求视为“实施细节”,因此作为“细节”导出。 TM 甚至不导出资源/需要。

但错过了资源(JSON 将 blob 序列化为 {})。 AFAICT 它将 .setKnownResources() 带有空/损坏的 blob,因此无法工作。

有一个 TODO 可以确定 blob 是否可以很好地字符串化。 在我为其提交 PR 之前,此功能在技术上已合并。

目前,Blob 问题将通过 #2937 解决。

至于在备份存档中创建更多文件,我认为这不会带来所有好处。 虽然将资源和要求以及任何内容归档到单独的文件中可能在提取时看起来不错,但这样做可能会使代码更加复杂,因为您正在处理许多小事情而不是简单的转储。

这是 4.4 的“大功能”,所以我真的希望尽快完成/改进。

第二个想法,这是功能性的。 我想跟踪一些改进,但每个针对这些目标更改的问题将更容易管理。

此页面是否有帮助?
0 / 5 - 0 等级