Make WordPress Core

Opened 7 years ago

Closed 5 years ago

Last modified 3 years ago

#40537 closed defect (bug) (reported-upstream)

PDF tests cannot be tested on Travis

Reported by: johnbillion's profile johnbillion Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Media Keywords: has-patch dev-feedback
Focuses: Cc:


PDF support is not available on Travis, so the tests in the Tests_Image_Functions class that rely on PDF support get skipped.

Example output:

3) Tests_Image_Functions::test_wp_generate_attachment_metadata_pdf
Rendering PDFs is not supported on this system.

What needs to be installed on Travis to get this working?

Should it be installed as part of the test bootstrap? Any other suggestions?

Attachments (3)

40537.patch (933 bytes) - added by desrosj 7 years ago.
Install Imagick on Travis builds.
40537.2.patch (933 bytes) - added by desrosj 7 years ago.
40537.3.patch (2.1 KB) - added by johnbillion 7 years ago.

Download all attachments as: .zip

Change History (26)

#2 @kirasong
7 years ago

Yes, agreed, we should be testing this on Travis.

For PDF support to work, GhostScript, ImageMagick, and Imagick are necessary.

In theory, any other stack that results in Imagick/Imagemagick returning support for PDF rendering should also work with WordPress, but that stack is the one at most supporting hosts.

I suspect @danielbachhuber has pinpointed the Travis specific issue, but if those are not all available on the versions other than PHP 7, that's what will need to be installed, if it's not installed already.

7 years ago

Install Imagick on Travis builds.

#3 @desrosj
7 years ago

  • Keywords has-patch needs-testing added; needs-patch needs-unit-tests removed

I was able to get Imagick to install on PHP 5.4+ in Travis (version 3.4.3 of Imagick requires PHP >= 5.4). Looks like ImageMagick and GhostScript are already installed on the Travis images.

You can see the build for this patch here:

There is only one failure in Travis when Imagick is installed.

There was 1 failure:
1) Tests_Image_Editor_Imagick::test_image_preserves_alpha_on_rotate
Failed asserting that 1.0 matches expected 0.0.

For context, when running phpunit --group wp-image-editor-imagick locally using VVV, there are currently 14 tests with 43 total assertions.

#4 follow-up: @johnbillion
7 years ago

I'd be happy enough to get the Travis tests running on newer PHP versions without worrying too much about 5.2 or 5.3.

#5 in reply to: ↑ 4 @joemcgill
7 years ago

Thanks @desrosj for taking a crack at this!

Replying to johnbillion:

I'd be happy enough to get the Travis tests running on newer PHP versions without worrying too much about 5.2 or 5.3.

I agree. With a few exceptions, our Imagick tests shouldn't really be specific to PHP version, so I'd be happy to have 2 of our versions (one older one new) running with Imagick installed so we catch most of the issues. If we find this isn't sufficient, we can reevaluate.

#6 @desrosj
7 years ago

I can make adjustments to the patch tonight and I will try to figure out why that single test is failing on Travis but not locally.

How far back would we look to backport this, if we would? I could also prepare patches for each version branch that we desire this to be added to.

7 years ago

#7 @desrosj
7 years ago

Updated patch installs Imagick only on the PHP 5.4 & 7.1 builds. I still can not replicate the failing of test_image_preserves_alpha_on_rotate() test locally, though.

Updated build:

Last edited 7 years ago by desrosj (previous) (diff)

This ticket was mentioned in Slack in #core-media by joemcgill. View the logs.

7 years ago

#9 @johnbillion
7 years ago

  • Keywords needs-patch added; has-patch removed

It appears that the failing test_image_preserves_alpha_on_rotate() test is due to the old version of ImageMagick which gets installed on Travis, due to everything running on Ubuntu 12.04.

Following @gitlost's example for the wp media command, I've gotten a branch that installs a newer version of ImageMagick and the image tests which use ImageMagick now pass. Work in progress still.

#10 @johnbillion
7 years ago

One concern I have is that it looks like ImageMagick doesn't retain download for older versions. For example, the download for version 6.9.8-3 has already been removed and replaced with 6.9.8-4. cc @gitlost.

7 years ago

#11 @johnbillion
7 years ago

  • Keywords has-patch dev-feedback added; needs-testing needs-patch removed

Latest patch which installs ImageMagick 6.9 and Imagick when running PHP 5.4+. All tests pass.

My only concern remains whether or not the ImageMagick package for 6.9.8-4 will disappear when 6.9.8-5 or 6.9.9 is released and cause the build to fail.

#13 @gitlost
7 years ago

Good stuff! I suppose for the disappearing release issue one could set the ImageMagick release to download from the site eg

IMAGEMAGICK_VERSION=`curl | grep 'href="ImageMagick-6.9.8-[^.]*.tar.gz"' -o | grep '6.9.8-[^.]*' -o`

A further consideration is which release to use, as using the latest and greatest isn't what's out there in the field, so it might be better to try to use the lowest one can get away with or something...

#14 @netweb
7 years ago

I'm not that familiar with ImageMagick, though Travis CI includes it in their docs that it's available as a library for Ubuntu 12.x builds

Happy to dig around further and/or ask Travis CI for more info if that'd be helpful

#15 @johnbillion
7 years ago

Yeah it's available but it's an older version (6.6.x) as I mentioned in comment:9. AFAICT this exhibits the bug that causes test_image_preserves_alpha_on_rotate() to fail whereas 6.9.x doesn't.

Could do with some more testing, but that's where I've gotten so far.

#16 @gitlost
7 years ago

After setting up a Precise virtualbox locally, traced test_image_preserves_alpha_on_rotate back (laboriously) to failing on ImageMagick 6.6.9-10 and working on ImageMagick 6.7.0-10, so it's an ImageMagick bug, perhaps connected with, though it's hard to tell with old pre-git ImageMagick stuff.

I couldn't reproduce the media-command behat seg faults, which was disappointing, but typical for memory bugs I suppose.

See for a version that runs Imagick for all PHP versions, with a variety of ImageMagick versions ranging from 6.5.4-10 to 6.9.7-10, chosen to hit various issues and cover some of the hoary versions out in the field as mentioned in eg #36534. It skips test_image_preserves_alpha_on_rotate if the ImageMagick version is < 6.7.0-10, and skips various ImageEditor tests for PHP 5.2 that use ReflectionProperty::setAccessible().

#17 @netweb
7 years ago

Related: #41148 Test for ticket 39875 can throw PHP error

#18 follow-up: @danielbachhuber
7 years ago

I ran into this bug (and a variety of error notices) in the wild on a DreamPress box. Here's a summary

3) Tests_Image_Intermediate_Size::test_get_intermediate_sizes_by_name
ImagickException: exif_read_data(waffles-1.jpg): Incorrect APP1 Exif Identifier Code
13) Tests_Image_Meta::test_utf8_iptc_tags
ImagickException: exif_read_data(test-image-iptc.jpg): Illegal IFD size
14) Test_Image_Resize_GD::test_resize_bad_image
ImagickException: imagecreatefromstring(): Data is not in a recognized format
16) Tests_Image_Editor_Imagick::test_image_preserves_alpha_on_rotate
Failed asserting that 1.0 matches expected 0.0.

Full report in:

[wp581415]$ convert --version
Version: ImageMagick 6.6.9-7 2016-06-01 Q16

It'd be good to get ImageMagick running in Travis so we have visibility into these sorts of failures.


#19 in reply to: ↑ 18 @danielbachhuber
7 years ago

Replying to danielbachhuber:

I ran into this bug (and a variety of error notices) in the wild on a DreamPress box.

As it turns out, the box is running Imagick 3.4.1 and thus suffers from this issue

#20 follow-up: @peterwilsoncc
5 years ago

With the switch to Docker in [45762], does this become easier?

#21 in reply to: ↑ 20 @noisysocks
5 years ago

Replying to peterwilsoncc:

With the switch to Docker in [45762], does this become easier?

Potentially! I created to track adding Imagick to the docker images we're now using.

#22 @pento
5 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to reported-upstream
  • Status changed from new to closed

Imagick (as well as ghostscript and exif) are now in the Docker images, so all of these tests run and pass.

Here's a recent build that I restarted to use the new images:

Since there's nothing to change in Core, I'm going to close this ticket.

#23 @johnbillion
3 years ago

#40536 was marked as a duplicate.

Note: See TracTickets for help on using tickets.