Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-21448

images using embed-inline style in ezoe are not displayed on same row in frontend

    Details

      Description

      add 2 images in ezoe, next to each other. set their view mode as embed-inline.

      Expected result: images display next to each other, both while editing, while viewing in backoffice and while viewing in frontend

      Actual result: images display next to each other while editing, and one above the other while viewing in backoffice and while viewing in frontend.

      Root cause:

      • the tpl used to render the "embed" xml-tag always puts a DIV in the html around the actual embedded content. Also it seems that embed-inline.tpl is never used.

      Example fix (ugly but works):

      {if ne('embed-inline', $view)}
      <div class="{if $object_parameters.align}object-{$object_parameters.align}{/if}{if ne($classification|trim,'')} {$classification|wash}{/if}"{if is_set($object_parameters.id)} id="{$object_parameters.id}"{/if}>
      {/if}
      {content_view_gui view=$view link_parameters=$link_parameters
          object_parameters=$object_parameters
          content_object=$object classification=$classification}
      {if ne('embed-inline', $view)}
      </div>
      {/if}
      

      NB: there is also the same pbl in reverse:
      when editing, 2 embeds side by side are always displayed inline even when they should be shown as block-level elements

      Steps to reproduce
      • In an eZ Publish 5.1, with eZFlow (legacy) design
      • In an article's description field insert a couple of images, side by side, setting them as inline
      • In front end, open that article and verify that the images are not showed side by side

        Issue Links

          Activity

          Hide
          André Rømcke added a comment - - edited

          There seems to be some mix up of embed-inline tag, and embed-inline view here.
          Given names are reused like this, and given ezoe does not give a good indication on difference it is fully understandable.

          Actually I'm a bit surprised the element stack next to each other in the editor when plain embed tag is used, cause internally it uses div for this, while embed-inline tag uses span. But for many possibly good reasons I guess these divs are set to be block-inline, which explains why this is possible, the idea being they should flow good inside text most likely.

          Show
          André Rømcke added a comment - - edited There seems to be some mix up of embed-inline tag, and embed-inline view here. Given names are reused like this, and given ezoe does not give a good indication on difference it is fully understandable. Actually I'm a bit surprised the element stack next to each other in the editor when plain embed tag is used, cause internally it uses div for this, while embed-inline tag uses span. But for many possibly good reasons I guess these divs are set to be block-inline, which explains why this is possible, the idea being they should flow good inside text most likely.
          Show
          Łukasz Serwatka added a comment - This problem was fixed in Online Editor 5.2 LS https://github.com/ezsystems/ezpublish-legacy/commit/e1589dc13c2501f6f2de62fc3fbb2514f3ba9d77#diff-5a9de1a9b54944e4210479fcb7923ce1
          Show
          Łukasz Serwatka added a comment - Fixed in ezpublish-legacy master as: https://github.com/ezsystems/ezpublish-legacy/commit/e1589dc13c2501f6f2de62fc3fbb2514f3ba9d77#diff-5a9de1a9b54944e4210479fcb7923ce1
          Hide
          André Rømcke added a comment -

          This has already been fixed and backported, see linked issue.

          Show
          André Rømcke added a comment - This has already been fixed and backported, see linked issue.

            People

            • Assignee:
              Unassigned
              Reporter:
              Gaetano Giunta (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 4 hours
                4h