philbee

Thanks Dean for clearing that up.

I thought this is by design, since it also happens on your own demo page https://thriveweb.com.au/the-lab/PhotoSwipe/ — Safari, Firefox and Chromium load the 21 photos in 500×333 as well as 1800×1200 sizes.

I’ll retry on a new blank dev site with a different theme, see what happens.

@tyrannous Ah yes, thanks a lot for the heads-up, this of course works as you said.
Now I’m fiddling with all the other settings ??

P3 is probably not compatible with PHP7.
Changing back to PHP 5.x enabled P3 to measure plugin impact again on my local server.

(I actually wonder if this is some sort of known bug.
Didn’t find anything yet relating to “known limitations of WP_SITEURL” or somesuch.)

Thanks a lot for your inputs, Jack!

Found it!

The culprits are the

define( 'WP_SITEURL', ' https://xxx/' );
define( 'WP_HOME', ' https://xxx/' );

settings in wp-config.php.

Set these in WordPress proper or in phpmysql, and delete or comment out in wp-config, and all is well.

Phew.

Yes, everything is set to 755.

Since this setting did not change between using WP on the domain (targeted in installatron) and the preview domain (changed in wp-config and then manually in phpmysql), I still think it must be some well-hidden place where mydummydomain.com ist still active.

The subdomain itself can’t be what’s messing Customizer up, I think.

One of the working installs of this client website I have on myclient.mydomain.com, and things work as expected there.

Just tested: created a https://mydummy.hosting.link preview domain for https://mydummydomain.com, changed WordPress to use this as siteurl and home (adding to wp-config.php), logged in to WordPress.

Everything seems to work, except image selection in Customizer > Header.

Now searching in phpmyadmin for mydummydomain.com URLs.

I’m pretty sure the preview URL thing is what messes with Customizers image selection.

Does not work:

• install WordPress using Installatron to a clients domain: https://myclient.com
• Because DNS for https://myclient.com still points to their old server, create a Preview domain using hosters service: https://myclient.hosting.link
• change WordPress to use https://myclient.hosting.link as base URL by adding to wp-config.php: define( ‘WP_SITEURL’, ‘ https://myclient.hosting.link/’ );
  define( ‘WP_HOME’, ‘ https://myclient.hosting.link/’ );
• move all Plugins and theme files using FTP
• copy all database and media content using Migrate DB Pro
• Change $table_prefix = ‘clienttableprefix_’; in wp-config.php
• Login to WordPress as admin
• Everything in WordPress works, except for saving image selections in Customizer > Header

Does work:

• install WordPress using Installatron to an additional test domain: https://mydummydomain.com
• move all Plugins and theme files using FTP
• copy all database and media content using Migrate DB Pro
• Change $table_prefix = ‘clienttableprefix_’; in wp-config.php
• Login to WordPress as admin
• Everything in WordPress works, including saving image selections in Customizer > Header

Somewhere, WordPress Customizer probably has some remains of https://myclient.com and stumbles.

So far, I have not been able to trace what Ajax is sending back to WordPress when I click on save in Customizer > Header. I would not be surprised to see something going wrong there.

That would be great – I’m extremely curious.

My guess is it’s something really silly. Silly, but well-hidden.

BTW: the only thing I can think of that is different for this install is that it currently runs on a preview URL, which I set in wp-config.php after installing WordPress. Maybe there’s a residue of the original domain targeted by the install somewhere. If so, I’ve been unable to find it in phpmyadmin.

Tried that this afternoon, and right now again: all Plugins off, set Theme to twentyfifteen, use a new browser that never had this page open, so no caching.

Makes no difference whatsoever.

This is what get written into Customizer, time after time after time:

data-customize-image-value="" data-customize-header-image-data="{"attachment_id":3915,"url":"","thumbnail_url":"","alt_text":"","width":954,"height":1300,"timestamp":["1464109068"]}"

Customizer can select the images, crop ’em, display them, but not save them.
I never liked the Customizer, but now I’m beginning to hate it.

Fun fact: things like “unused widgets” do get written into wp_options > theme_mods_mytheme. It’s only the header image informations that stubbornly only display live in the customizer, but then are not written into the options field.

I’m looking through it all right now.
There were a few funny guid in wp_posts, but apart from that, so far I’ve not seen anything strange.

Some of the header images are even flagged as such in the Media listing, so somewhere WordPress seems to be aware of something.

Looks like I found the solution:
uncheck Sync Custom Fields in Polylang
add only the Custom Fields one needs to be synched

add_filter('pll_copy_post_metas', 'merge_post_metas');
function merge_post_metas($metas,$sync) {
      return array_merge($metas, array('event_date','event_starting_time','member_first_name','member_last_name'));
}

Seems to work so far. Maybe this should be added to the Filter documentation, for clarity’s sake?

Maybe I should add: I deleted WPML (sitepress-multilingual-cms) and all its other PlugIns, so it’s not any old wpml-config.xml that’s messing things up.
Also, with no pll_copy_post_metas active, all custom fields are being synchronized, which is obviously better than having them empty in the translated CPT (event or member), but not ideal.