Problem/Motivation

If inline images are resized in CKeditor, the image will not enlarge in photoswipe since data-pswp-width and data-pswp-height are populated with the height and width of the displayed image from the dom, not the natural height and width of the image

Steps to reproduce

Insert an inline image and resize it

Proposed resolution

There needs to be a way to pick up the intrinsic, natural dimensions of the image to populate the data-pswp-width/height values. The current $dom = Html::load($text); doesn't do the trick because it can't know the actual dimensions of the image. The URLs of the images need to be parsed out and the intrinsic size determined from the file

Remaining tasks

User interface changes

API changes

Data model changes

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

atratus created an issue. See original summary.

atratus’s picture

This works for me, but it is problematic since it assumes allow_url_fopen is on for images that aren't in the local filesystem, and I took out the test for an existing class attribute on the image. I'm not sure why that was there, but I assume you had a reason. I'm posting this not as a solution, but as an idea toward a solution.

foreach ($elements as $element) {
  $a = $dom->createElement('a');
  $element->parentNode->insertBefore($a, $element);
  $a->appendChild($element);
  $src = $element->getAttribute('src');
  if (isset(parse_url($src)['host'])) {
    list($img_width, $img_height, $type, $attr) = getimagesize($src);
  } else {
    $path = urldecode(strtok($src,'?'));
    list($img_width, $img_height, $type, $attr) = getimagesize(DRUPAL_ROOT.$path);
  }
  if (($img_width=='')||($img_height=='')) {
    $img_width = $element->getAttribute('width');
    $img_height = $element->getAttribute('height');
  }
  $a->setAttribute('href', $element->getAttribute('src'));
  $a->setAttribute('class', 'photoswipe');
  $a->setAttribute('data-pswp-width', $img_width);
  $a->setAttribute('data-pswp-height', $img_height);
}
ivnish’s picture

Looks like a project-specific issue. I think you need to disable this contrib module and use own text filter in custom code

atratus’s picture

No, I think you are missing the point of the problem. If an inline image is resized in the WYSIWYG editor, your code as it is picks up the height and width of the resized image from the html img attributes, not the intrinsic size of the image, so clicking on the image just brings up the same small version of the image in Photoswipe instead of the full-sized image, which is the point of using Photoswipe. What I have given you fixes that for both locally and remotely hosted images.

Consider this scenario: say I insert an inline image in a post that's 4000px x 3000px intrinsically, and I scale it down in the WYSIWYG editor so it is 200 x 150. A user clicks on the image expecting a larger version, but with your code all they get is the same 200 x 150 pixel scaled image, whereas with what I have done the image fills the window as expected and they can further zoom to the intrinsic size.

ivnish’s picture

Thanks, now I can confirm it

bramdriesen’s picture

I also bumped into this problem. The problem is that the data-pswp-width and data-pswp-height are being calculated from the image in the ckeditor, but not the source image.

This needs an issue fork,

bramdriesen’s picture

Status: Active » Needs work
bramdriesen’s picture

Version: 1.0.0 » 1.0.x-dev
Assigned: Unassigned » bramdriesen
bramdriesen’s picture

Title: Size problem » Image size problem

bramdriesen’s picture

Status: Needs work » Needs review

Updated logic, cleaned up the variable names to be in line with best practices, added a simple test which checks the image size.

bramdriesen’s picture

Assigned: bramdriesen » Unassigned

  • ivnish committed d831b620 on 1.0.x authored by bramdriesen
    [#3500993] feat: Image size problem
    
    By: atratus
    By: ivnish
    By:...
ivnish’s picture

Status: Needs review » Fixed

Thanks!

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.