GrapesJS 问题

GJS Helper

感谢您在GrapesJS TypeScript声明文件中报告了这个错别字错误。你说得完全正确;dist/index.d.ts的第8053/8054行确实有个拼写错误。 根本原因 问题在于一个简单的拼写错误，dist/index.d.ts文件中的PropertyProps接口定义中使用了proeperty而不是property。该文件是自动从GrapesJS源代码生成的，意味着拼写错误源自生成该声明的源TypeScript/JSDoc注释。 具体来说，相关系列包括： 影响 这...

artf

@gitpugal如果有任何问题，请使用讨论区

GJS Helper

GrapesJS 提供了一个灵活的面板和命令系统，允许你通过自定义部分扩展其界面，类似于默认的块管理器和样式管理器的操作方式。要添加额外的自定义块管理器类标签或部分并填充特定块，你需要利用 GrapesJS的面板管理器、命令管理器和块管理器。 这个解决方案包括创建一个新面板来存放自定义方块，在主 views-container （左侧侧边栏标签页）添加一个按钮来激活该面板，并定义一个命令，只渲染你自定义类别中的方块。 逐步解决方案 1.初始化 GrapesJS 并定义自定义...

artf

我需要选择别的，而不是普通 是的，如果没有值，默认界面会预选“默认值”，但这很容易更新 “''js 编辑。StyleManager.getProperty（'typography'， 'font-weight'）.set（{ 默认： ' ' }）; ``` 所以我猜这不是核心漏洞，而是“意外预期”的行为 🥲

lexoyo

哦，明白了，我以为你会希望默认值是预期的行为 😃 谢谢你的回答

GJS Helper

你好！感谢你报告这个问题。你准确指出了GrapesJS风格管理器中关于默认CSS属性值的一个常见混淆点和合理的可用性问题，尤其是在处理继承时。这种行为并不是指GrapesJS故障的bug，而是默认属性呈现方式上的设计选择，可能具有误导性。 根本原因解释 GrapesJS风格管理器定义属性时，defaults值。对于像font-weight这样的属性，默认定义通常包括defaults: 'normal'。当编辑器中选中元素且没有显式font-weight样式时，样式管理器的f...

bernesto

太棒了，@artf你是摇滚明星！

artf

谢谢@bernesto演示方面其实还有更新要做。 我已经准备好了更改，下次发布时会修正。

GJS Helper

你已经指出了关于GrapesJS预览模式的一个常见困惑点。你观察到的行为——组件轮廓（虚线边框）在预览模式下依然存在——确实不是想要一个干净、最终用户视图的用户体验。虽然GrapesJS移除了大部分管理UI元素，但负责这些轮廓的gjs-dashed类在预览时可能不会自动从body元素中移除。这可能导致预览不够精致。好消息是，用GrapesJS的事件系统解决这个问题很简单。 根本原因 GrapesJS编辑器会对body元素或编辑器的主容器应用一个全局类，通常为gjs-dash...

artf

如果你需要复制 traits，我建议简单地做这个操作：'JSON.parse（JSON.stringify（editor.getSelected（）.getTraits（））'。 我不记得文档里提到过克隆特征，所以我建议避免使用非公开API。

GJS Helper

你发现了GrapesJS中一个合理的漏洞，调用component.get('traits').clone()会抛出一个TypeError。这个问题源于Traits集合的clone()方法，内部依赖Backbone.Collection.prototype.clone()，尝试用new this.constructor(this.models)实例化一个新的Traits集合。Traits集合的构造函数或调用的内部方法有特定的依赖关系，或者期望某个上下文，但以这种方式调用时未被...

GJS Helper

你准确指出GrapesJS文档与content属性类型定义之间的差异BlockProperties。这确实是类型定义中的一个bug，因为content属性设计成接受比当前在Block.ts中声明的更灵活的值。 根本原因 GrapesJS块的content属性旨在高度多功能，允许开发者定义拖曳到画布上的组件初始结构。根据文档和实际运行时行为，content可以接受： 一个普通的 HTML 字符串（例如 "<div>Hello World</div>"）。 单个Componen...

artf

感谢报告，将在下次发布中修复（https://github.com/GrapesJS/grapesjs/commit/a54f213c33ee90549ef06f3b505c455f1abfc323）。

Mauzer93

我最近也遇到了同样的问题。

GJS Helper

你遇到的问题，链接标题无法编辑，很可能源于对GrapesJS如何处理链接组件不同部分的普遍误解，特别是对链接的可见文本和其HTMLtitle属性的区别。 让我们澄清并提供两种情况的解决方案： 1.编辑链接的可见文本（内部HTML） 它是什么： 这指的是显示在<a>标签内的文本，例如<a href="#">Click Here</a>Click Here。 *在 GrapesJS: 中的预期行为 默认情况下，链接组件的可见文本是内联可编辑的。你应该可以在画布中点击链接，然后再...

bernesto

你好，@artf， 根本问题是我们试图将弹出调色板绝对放置在页面任意位置的另一个元素之上。即使原点元素不在编辑器容器节点之外，我们也需要这样做。 为满足此要求，弹出调色板不能包含在“offsetParent”的任何位置，且必须处于最高的z指数。否则，它将受其“offsetParent”可见区域的影响，并按父节点的“z-index”排序。 在我之前的补丁中，这似乎是可行的，因为示例编辑器占用了整个窗口，因此编辑器元素内的“left： 0”和“top： 0”也在正体内部是“le...

artf

@bernesto你能检查一下这个吗？因为它似乎和[你的更改]（https://github.com/GrapesJS/grapesjs/pull/5704）有关。

bernesto

是的，我明白问题所在。逻辑需要考虑父节点在容器外的情况。让我看看能不能做。

bernesto

我觉得预读解析师这个选项是个很好的主意。它坚持“按功能插入”的概念。 那更新“fromElement”以接受字符串元素ID或布尔值怎么样？如果 bool == true，则和现在一样，解析容器 HTML。 如果字符串 ID，它会使用元素的内容，容器则像现在一样成为编辑器。然后我们可以更新文档，支持HTML脚本模板用于开发。这样可以防止刹车变化，并促进正确的使用。 “''js const editor = Grapesjs.init（{ 容器：“#gjs”， fromElem...

artf

完全同意@bernesto的观点，无论我们多么努力让它安全，都永远不够，我也不想让人觉得库“非常安全”，以至于缺少服务器端验证。 当前选项（例如“allowUnsafeAttr”、“allowUnsafeAttrValue”）只避免了基本的常见内容。

bernesto

使用“fromElement”从激活的DOM元素加载时，这种情况是不可避免的。页面元素同步加载和执行。GrapesJS 永远没有机会处理和解除 XSS 的 html。 这个问题需要通过阻止恶意代码永远加载来解决。这应该在服务器存档时处理。但如果客户端需要处理，可以通过用脚本标签包裹代码，然后在加载到编辑器前对代码进行净化，就像这样： https://jsfiddle.net/bernesto/5gcxa0jm/1/ 我确实看到，在初始化时通过“components”属性加载...

bernesto

是的，我做了所有常规的事情。锁定文件、更新、各种导入方式（{}、require、*、full path 等） 不知道为什么，但我弄坏东西的时候，会弄得很厉害。永远是2级或3级辅助，哈哈。 我确实认为问题出在CLI，或者......配合 Backbone-Undo。也许是路径相关的，或者是符号链接，或者...... ̄\(ツ)/ ̄ 总之，我明白“时间”的含义。我已经花了太多时间了，如果你有兴趣告诉我，哈哈

bernesto

说得好。我还没试过其他版本的Node。我会试试这个方法。

artf

是的，构建/服务是由CLI管理的（我们把问题移到那里），但我不确定问题出在哪里（因为没有Windows可以测试🥲）。