test(e2e): Cover delivery through a custom domain (CNAME) by utkarshcloudinary · Pull Request #1353 · cloudinary/cloudinary_wordpress

utkarshcloudinary · 2026-11-02T12:17:29Z

Adds an e2e spec for delivery through a custom domain (CNAME). The spec connects with a fake domain in the connection string and checks that the image block, the Gallery widget and the Cloudinary video player use it. It also checks that private_cdn=false keeps the cloud name in the path.

Approach

cloudinary-cname-delivery.spec.js (@serial) connects with ?cname=cdn.e2e-cloudinary.test before the upload, as the ticket suggests. The plugin only checks the domain format and never resolves it.
routeCnameToCloudinary() sends requests for the fake domain on to res.cloudinary.com, and adds the cloud name to the path for a private CDN. So the images really load, and the Gallery widget reaches data-ready="true". This also proves that the path the plugin builds is a valid Cloudinary path.
Image block: the src and every srcset URL use the domain, and the path does not start with /<cloud_name>/. Lazy load is off and breakpoints are on, so the server writes a Cloudinary srcset to check.
Gallery: shows 3 images, and every widget <img> URL uses the domain.
Video (optional criterion): the Cloudinary player iframe gets cloudinary[cname], cloudinary[secure_distribution] and cloudinary[private_cdn].
private_cdn=false: the URLs use the domain, and the path starts with /<cloud_name>/. A test.fixme covers the Gallery widget in this mode: Gallery always sends privateCdn: true when a custom domain is set and ignores private_cdn, so the widget leaves the cloud name out and no image loads.
afterAll connects without the domain first, then restores the settings and deletes the posts and attachments. So the other delivery specs in the same serial run get plain res.cloudinary.com URLs.
ensureCloudinaryConnected() accepts { cname, privateCdn }. It now fails if the plugin does not save the new connection string, which the plugin does when the API test of the string fails.
expectCloudinaryUrl() accepts { host, cloudName, privateCdn }. A plain cloud name still works as before.
The gallery helpers move to tests/e2e/utils/gallery.js. The gallery spec uses them and works as before.

QA notes

npm run test:e2e:serial -- cloudinary-cname-delivery
npm run test:e2e:serial (the other delivery specs must still pass after this spec in the same run)

Move galleryBlock(), openGallery() and collectImageUrls() out of the gallery delivery spec into tests/e2e/utils/gallery.js, so the custom domain spec can render the Gallery block the same way.

- ensureCloudinaryConnected() accepts { cname, privateCdn } and adds them to the connection string. It now fails when the plugin does not save the new string. - expectCloudinaryUrl() accepts { host, cloudName, privateCdn }. - routeCnameToCloudinary() sends requests for a fake custom domain on to res.cloudinary.com, so the images still load.

Connect with a fake custom domain and check that the image block, the Gallery widget and the Cloudinary video player use it. Check that private_cdn=false keeps the cloud name in the path. Restore the plain connection in afterAll. Refs WPP-1240

Replace the local saveSettings() copy with the one in tests/e2e/utils/settings.js.

gabrielcld2

This is looking good 👍 A few comments and suggestions, but nothing major.

gabrielcld2 · 2026-11-10T07:29:55Z

+			expect( params.get( 'cloudinary[private_cdn]' ) ).toBe( 'true' );
+		} );
+
+		test( 'with private_cdn=false the path keeps the cloud name', async ( {


Should this test cover the gallery too? Gallery always sends privateCdn: true when a cname is set (php/media/class-gallery.php, in get_config() and in the block attributes), whatever private_cdn says in the connection string. So with private_cdn=false I'd expect the widget to leave the cloud name out of its URLs, and a CNAME that isn't a private CDN can't serve those.

If that's right, it's a plugin bug and this spec is a good place to catch it, even as a test.fixme until it's fixed. If it's intended, a short comment here explaining why the gallery is left out would help.

You're right, it's a plugin bug. Gallery sets privateCdn: true whenever a cname is set and ignores private_cdn. I confirmed it locally: with private_cdn=false the widget renders 0 of 3 images, because its URLs leave out the cloud name. Added in 4399523 as test.fixme( 'gallery widget path keeps the cloud name' ) inside the private_cdn=false block, with a comment pointing at class-gallery.php. It can become a plain test once the plugin is fixed.

gabrielcld2 · 2026-11-10T07:29:55Z

+		test( 'with private_cdn=false the path keeps the cloud name', async ( {
+			page,
+		} ) => {
+			ensureCloudinaryConnected( { cname: CNAME, privateCdn: false } );


This switches the connection to private_cdn=false, and only afterAll switches it back. So any test added after this one would run with private_cdn=false too. Could we switch it back at the end of the test (try/finally with ensureCloudinaryConnected( { cname: CNAME } ))? Or at least add a comment saying this test has to stay last.

Done in 4399523. The private_cdn=false tests are now in their own describe block: its beforeAll switches to private_cdn=false and its afterAll switches back to the plain cname. A test added outside the block keeps the private CDN connection.

gabrielcld2 · 2026-11-10T07:29:55Z

+}
+
+module.exports = {
+	GALLERY_CONTAINER,


Nit: nothing imports GALLERY_CONTAINER or WIDGET_TIMEOUT, and the same goes for CLOUDINARY_HOST in utils/delivery.js. Fine to keep them if you expect to need them soon. Otherwise we could remove them from the exports.

Removed in 4399523. GALLERY_CONTAINER, WIDGET_TIMEOUT and CLOUDINARY_HOST are still used inside their own files, just no longer exported.

Switch to private_cdn=false in a describe block's beforeAll and back in its afterAll, so a test added later does not inherit it. Add a gallery test for private_cdn=false as test.fixme. Gallery always passes privateCdn: true to the widget when a custom domain is set, so the widget leaves the cloud name out of its URLs and no image loads. Remove exports that nothing imports.

Lint failed in CI because the gallery fixme test was formatted with an older local prettier than the one in package-lock.json.

utkarshcloudinary marked this pull request as draft November 2, 2026 12:17

utkarshcloudinary changed the base branch from develop to test/responsive-breakpoints-lazy-load-e2e November 2, 2026 12:23

utkarshcloudinary marked this pull request as ready for review November 2, 2026 12:24

utkarshcloudinary added this pull request to stack #1354 November 2, 2026 12:24

utkarshcloudinary force-pushed the test/WPP-1240-cname-delivery-e2e branch from 2dd4986 to ef58d3a Compare November 2, 2026 14:18

utkarshcloudinary mentioned this pull request Nov 2, 2026

test(e2e): Add breakpoints and lazy load spec #1342

Merged

Base automatically changed from test/responsive-breakpoints-lazy-load-e2e to develop November 5, 2026 06:56

PatelUtkarsh added 4 commits November 5, 2026 07:56

refactor(e2e): Move gallery helpers to a shared util

bc511a9

Move galleryBlock(), openGallery() and collectImageUrls() out of the gallery delivery spec into tests/e2e/utils/gallery.js, so the custom domain spec can render the Gallery block the same way.

test(e2e): Use shared settings helper in CNAME spec

4513a60

Replace the local saveSettings() copy with the one in tests/e2e/utils/settings.js.

gabrielcld2 force-pushed the test/WPP-1240-cname-delivery-e2e branch from ef58d3a to 4513a60 Compare November 5, 2026 06:56

gabrielcld2 reviewed Nov 10, 2026

View reviewed changes

PatelUtkarsh added 2 commits November 10, 2026 14:05

style(e2e): Format CNAME spec with prettier 3.9

6299635

Lint failed in CI because the gallery fixme test was formatted with an older local prettier than the one in package-lock.json.

Navigation Menu

Repository navigation

test(e2e): Cover delivery through a custom domain (CNAME) - #1353

test(e2e): Cover delivery through a custom domain (CNAME)#1353
utkarshcloudinary wants to merge 6 commits into
developfrom
test/WPP-1240-cname-delivery-e2e

utkarshcloudinary commented Nov 2, 2026 •

edited

Loading

Uh oh!

gabrielcld2 left a comment

Uh oh!

gabrielcld2 Nov 10, 2026

Uh oh!

utkarshcloudinary Nov 10, 2026

Uh oh!

gabrielcld2 Nov 10, 2026

Uh oh!

utkarshcloudinary Nov 10, 2026

Uh oh!

gabrielcld2 Nov 10, 2026

Uh oh!

utkarshcloudinary Nov 10, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

utkarshcloudinary commented Nov 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Approach

QA notes

Uh oh!

gabrielcld2 left a comment

Choose a reason for hiding this comment

Uh oh!

gabrielcld2 Nov 10, 2026

Choose a reason for hiding this comment

Uh oh!

utkarshcloudinary Nov 10, 2026

Choose a reason for hiding this comment

Uh oh!

gabrielcld2 Nov 10, 2026

Choose a reason for hiding this comment

Uh oh!

utkarshcloudinary Nov 10, 2026

Choose a reason for hiding this comment

Uh oh!

gabrielcld2 Nov 10, 2026

Choose a reason for hiding this comment

Uh oh!

utkarshcloudinary Nov 10, 2026

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

utkarshcloudinary commented Nov 2, 2026 •

edited

Loading