在MailChimp模板中使用mc:edit时如何维护图像类?

时间:2014-03-19 07:58:56

标签: email html-email mailchimp

我尝试使用mc创建一个可以编辑图像的MailChimp模板:编辑

以下是代码:

<img class="flexibleImage" mc:edit="top_image">

这似乎都很好,但是一旦我使用MailChimp编辑器编辑这个图像,我就失去了原来的类&#34; flexibleImage&#34;以及与该img元素相关的所有其他类和样式信息。

如何使用可编辑图像创建模板并维护(或添加)该类?

3 个答案:

答案 0 :(得分:4)

对于有问题的其他人,这个答案是基于MailChimp支持的回复:

  

看起来不可能将自定义类附加到   可编辑的图像。你应该做的是申请课程   到图像的包含元素。因此,如果图片位于<div>,请添加   flexibleImage div,然后更新您的CSS规则以指向   .flexibleImage>img

答案 1 :(得分:0)

这是因为您要编辑的图片位于mc:repeatable块内,而mc:repeatable块又位于另一个Linker script is below--> /* Script for ld -r: link without relocation */ OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64") OUTPUT_ARCH(i386:x86-64) /* For some reason, the Solaris linker makes bad executables if gld -r is used and the intermediate file has sections starting at non-zero addresses. Could be a Solaris ld bug, could be a GNU ld bug. But for now assigning the zero vmas works. */ SECTIONS { /* Read-only sections, merged into text segment: */ .interp 0 : { *(.interp) } .note.gnu.build-id : { *(.note.gnu.build-id) } .hash 0 : { *(.hash) } .gnu.hash 0 : { *(.gnu.hash) } .dynsym 0 : { *(.dynsym) } .dynstr 0 : { *(.dynstr) } .gnu.version 0 : { *(.gnu.version) } .gnu.version_d 0: { *(.gnu.version_d) } .gnu.version_r 0: { *(.gnu.version_r) } .rela.init 0 : { *(.rela.init) } .rela.text 0 : { *(.rela.text) } .rela.fini 0 : { *(.rela.fini) } .rela.rodata 0 : { *(.rela.rodata) } .rela.data.rel.ro 0 : { *(.rela.data.rel.ro) } .rela.data 0 : { *(.rela.data) } .rela.tdata 0 : { *(.rela.tdata) } .rela.tbss 0 : { *(.rela.tbss) } .rela.ctors 0 : { *(.rela.ctors) } .rela.dtors 0 : { *(.rela.dtors) } .rela.got 0 : { *(.rela.got) } .rela.bss 0 : { *(.rela.bss) } .rela.ldata 0 : { *(.rela.ldata) } .rela.lbss 0 : { *(.rela.lbss) } .rela.lrodata 0 : { *(.rela.lrodata) } .rela.ifunc 0 : { *(.rela.ifunc) } .rela.plt 0 : { *(.rela.plt) } .init 0 : { KEEP (*(SORT_NONE(.init))) } .plt 0 : { *(.plt) *(.iplt) } .hot 0 : { *(.text.hot) } .text 0 : { /* merge .text.* sections into the .text segment in the first pass link so that all static functions are in the same segment and the relative offsets reported by nm/readelf can be used to determine the final absolute address of the function in the image. */ *(.text .stub .text.* .gnu.linkonce.t.*) /* .gnu.warning sections are handled specially by elf32.em. */ *(.gnu.warning) } .fini 0 : { KEEP (*(SORT_NONE(.fini))) } .rodata 0 : { *(.rodata) } .rodata1 0 : { *(.rodata1) } .eh_frame_hdr : { *(.eh_frame_hdr) } .eh_frame 0 : ONLY_IF_RO { KEEP (*(.eh_frame)) } .gcc_except_table 0 : ONLY_IF_RO { *(.gcc_except_table .gcc_except_table.*) } /* These sections are generated by the Sun/Oracle C++ compiler. */ .exception_ranges 0 : ONLY_IF_RO { *(.exception_ranges .exception_ranges*) } /* Adjust the address for the data segment. We want to adjust up to the same address within the page on the next page up. */ /* Exception handling */ .eh_frame 0 : ONLY_IF_RW { KEEP (*(.eh_frame)) } .gcc_except_table 0 : ONLY_IF_RW { *(.gcc_except_table .gcc_except_table.*) } .exception_ranges 0 : ONLY_IF_RW { *(.exception_ranges .exception_ranges*) } /* Thread Local Storage sections */ .tdata 0 : { *(.tdata) } .tbss 0 : { *(.tbss) } .preinit_array 0 : { KEEP (*(.preinit_array)) } .jcr 0 : { KEEP (*(.jcr)) } .dynamic 0 : { *(.dynamic) } .got 0 : { *(.got) *(.igot) } .got.plt 0 : { *(.got.plt) *(.igot.plt) } .data 0 : { *(.data) } .data1 0 : { *(.data1) } .bss 0 : { *(.dynbss) *(.bss) *(COMMON) /* Align here to ensure that the .bss section occupies space up to _end. Align after .bss to ensure correct alignment even if the .bss section disappears because there are no input sections. FIXME: Why do we need it? When there is no .bss section, we don't pad the .data section. */ } .lbss 0 : { *(.dynlbss) *(.lbss) *(LARGE_COMMON) } .lrodata 0 : { *(.lrodata) } .ldata 0 : { *(.ldata) } /* Stabs debugging sections. */ .stab 0 : { *(.stab) } .stabstr 0 : { *(.stabstr) } .stab.excl 0 : { *(.stab.excl) } .stab.exclstr 0 : { *(.stab.exclstr) } .stab.index 0 : { *(.stab.index) } .stab.indexstr 0 : { *(.stab.indexstr) } .comment 0 : { *(.comment) } /* DWARF debug sections. Symbols in the DWARF debugging sections are relative to the beginning of the section so we begin them at 0. */ /* DWARF 1 */ .debug 0 : { *(.debug) } .line 0 : { *(.line) } /* GNU DWARF 1 extensions */ .debug_srcinfo 0 : { *(.debug_srcinfo) } .debug_sfnames 0 : { *(.debug_sfnames) } /* DWARF 1.1 and DWARF 2 */ .debug_aranges 0 : { *(.debug_aranges) } .debug_pubnames 0 : { *(.debug_pubnames) } /* DWARF 2 */ .debug_info 0 : { *(.debug_info) } .debug_abbrev 0 : { *(.debug_abbrev) } .debug_line 0 : { *(.debug_line) } .debug_frame 0 : { *(.debug_frame) } .debug_str 0 : { *(.debug_str) } .debug_loc 0 : { *(.debug_loc) } .debug_macinfo 0 : { *(.debug_macinfo) } /* SGI/MIPS DWARF 2 extensions */ .debug_weaknames 0 : { *(.debug_weaknames) } .debug_funcnames 0 : { *(.debug_funcnames) } .debug_typenames 0 : { *(.debug_typenames) } .debug_varnames 0 : { *(.debug_varnames) } /* DWARF 3 */ .debug_pubtypes 0 : { *(.debug_pubtypes) } .debug_ranges 0 : { *(.debug_ranges) } /* DWARF Extension. */ .debug_macro 0 : { *(.debug_macro) } .gnu.attributes 0 : { KEEP (*(.gnu.attributes)) } } 块内

答案 2 :(得分:0)

即使四年后,这仍然是一个问题。

另一种方法是将mc:edit放在父容器上,并在那里管理图像,但是会丢失“图像上载器”框,这会降低用户体验。

上传新图像并将尺寸放入其中后,您可以进入“设置”。虽然不理想,但应归咎于Mailchimp(Campaign Monitor模板上没有此类问题)。