把 HTML 变成
可编辑的 Elementor 页面

两种常规做法的问题

当你手上已有一个做好的 HTML 页面、又需要把它放进 WordPress 时,通常只有两条路,而且都不好走。第一条是把整段标记贴进一个 HTML 小部件。页面能正常渲染,但 Elementor 把它当成一个不透明的整块:你没法点击标题改字号,没法换图标,客户想改一句话也得打开代码。页面待在 Elementor 里,却不属于 Elementor。

第二条路是逐个区块手工重建。结果地道且完全可编辑,但对一个长营销页来说要花几个小时,而且要精确还原原稿的间距和排版,既枯燥又容易出错。

转换是第三条路。它不保留标记原样,也不靠手工重建,而是像浏览器那样读取页面——用真实的计算样式——再把每个部分映射到最合适的 Elementor 组件上。

为什么读计算样式,而不是样式表

转换器不会去解析你的 CSS。页面在一个隔离的框架里被真实渲染,然后按浏览器实际解析出的结果测量每一个元素。这个区别比听起来重要得多。

这意味着基于 class 的 CSS、层叠、继承、自定义属性和简写全都天然可用,因为读到的值就是最终值。写成 CSS 变量的颜色,拿到的是它解析后的颜色;用 clamp 写的字号,拿到的是它实际生效的大小。不存在一个会和你的浏览器意见相左的 CSS 解析器。

它也带来一个值得理解的问题——下文那些小心处理大多源于此:浏览器会把相对值解析成绝对像素。百分之百的宽度报告出来是一个像素数;auto 左右边距报告出来是当时恰好让元素居中的那几个像素;写成分数的网格列报告出来是像素宽度。若直接照抄这些数字,你的布局就会被冻结在转换恰好运行时的那个宽度上。

所以相对意图是被重建的,而不是被照抄的。图片按其容器的百分比来表达,满宽图片则完全不写固定宽度。带 max-width 且左右 auto 边距对称的块会被识别为居中,转成 Boxed 容器,在任何屏幕尺寸下原生居中。相等的网格轨道会做数值比较(容忍亚像素舍入),再写回成分数单位,网格依然能自适应回流。

结构:容器,以及知道何时不该造容器

标记里的每个块级包裹层都会变成一个 Elementor 容器,带着它的内边距、背景、边框、圆角、阴影以及 flex 或 grid 设置。这是忠实的映射,但照字面执行会产生很深的树:section 套 wrapper 套 row 套 column,还没碰到标题就已经四层容器了。

有两件事在给它减负。毫无视觉或布局作用的包裹层——没有背景、边框、内边距、阴影、最大宽度、最小高度,也不是 flex 或 grid——会被折叠,因为去掉它什么都不会变。而那种本质上只是给单一内容套了个样式外框的卡片,会被整体压平:外框直接落到组件自己身上。

正是第二条规则,让五张图片卡组成的一行变成「一个网格装五个 Image Box 组件」,而不是「一个网格装五个容器、每个容器再装一个组件」。这正是熟练的 Elementor 用户手工搭建时会用的结构,日后重新调整样式也容易得多。

识别的是模式,不只是标签

把标题映射成 Heading 组件是显而易见的,真正有用的工作在于识别形状。一个装着一枚图标、一个标题和一小段文字的容器,是 Icon Box;装着一张图片、一个标题和一段文字的容器,是 Image Box;由重复行组成、每行恰好一枚图标加一段文字的列表,是 Icon List,每行对应一个可编辑条目。

这些识别是刻意从严的。如果卡片里除了标题和段落还有别的文字——步骤编号、角标、价格——模式就不套用,区块保持为普通容器,因为丢掉那些文字比树深一层糟糕得多。可以信赖的保守识别,比每次都得人工复查的激进识别更有价值。

按钮同理。真实世界里的行动号召大多是套了 CSS 的链接,不是 button 元素,所以只有当多个信号一致时,链接才会被当成按钮:文字短、没有块级子元素、有背景或边框、有圆角、有真实内边距、display 类似块级。单看其中任何一条,都会产生误判。

图标与图片:两件需要你做决定的事

图标可以变成 Elementor 图标库里的真实条目,之后能直接在图标选择器里替换。前提是源码用的是图标字体 class。如果用的是手绘内联 SVG,图形根本进不了图标控件;而依赖页面 CSS 定尺寸和描边的 SVG,一旦离开页面也会丢掉那些样式。按名字匹配不到的图标,控件会被有意留空,而不是塞进一个错误的猜测。

图片是另一个要做的决定。data-URL 图片或本地文件路径没法变成 WordPress 媒体附件,所以它们会变成空槽位——每个槽位把原图的 alt 文字留作说明,你能知道哪张图该放哪。若源码引用的是真实已上传的图片 URL,则完全无需手动处理,直接导入。先把图片传好,是最能减少导入后工作量的一个改变。

什么转不过来,坦白说

脚本会被移除,所以一切由自定义 JavaScript 驱动的东西都会以静态标记的形式到达,应当用对应的原生组件重建。表单的提交动作会被剥掉,因为把端点带过来,访客数据就会被发往一个你没有选择的地方。导航菜单必须指向一个真实的 WordPress 菜单。悬停和聚焦状态无法从静止页面读出,需要事后设置。动画、过渡和吸附行为,用 Elementor 自带的控件重新做效果更好。

伪元素值得单独一提,因为它们最让人意外。用 before 和 after 画出来的装饰形状、引号、下划线点缀根本不是 DOM 节点,所以不可能变成组件。转换后若发现某个设计细节不见了,先查这里。

拿到最干净的结果

转换质量主要取决于你喂进来的标记。语义化标签的映射毫无歧义;每个区块只有一层包裹的浅 DOM 能让树保持可编辑;内联或集中在单个 style 块里的 CSS 才真正测得到,而一份永远加载不了的框架样式表,留给转换器的只是一个没有样式的页面;用 gap 设置的间距会变成一个控件,而不是一堆。

每次导出前,花十五秒看一眼结构映射都值得。它显示组件数量、最大嵌套深度和置信度分布,还有一个与树联动的实时预览。如果深度偏高,或有好几行被保留成了 HTML,那么修源码再转一次,始终比在 Elementor 里修补输出更快。

长页面就一次搬一个区块。在想要的区块上设置复制根,只有那棵子树会被导出,页面的外层包裹、页头页脚都留在原地。小单元验证起来容易得多,以后还会用到的东西,顺手存进模板库就是了。