Sentynel

Logged back into Jetpack and the issue is still happening. Double checked the settings in the database for the mobile theme are correct.

I’m having the same issue – updated to 4.6 and the corresponding Jetpack updates last night, and the mobile theme isn’t working. I’ve tried turning off the mobile theme in Jetpack settings and turning it back on. We do use WP Super Cache with the Jetpack plugin enabled, but I’ve confirmed it’s correctly generating separate mobile cache files as before, it’s just that the desktop theme is being served to all browsers.

Have tried turning the Jetpack plugin itself off and back on; currently waiting for the person with the Jetpack account to log it back in.

Site is https://www.angrymetalguy.com/.

It’s not that issue – the update script thinks it’s succeeded, and everything seems to be working. But the commentmeta table remains in utf8 mode, not utf8mb4, and I’m concerned about potential future problems from the charset not being what WordPress thinks it is. Attempting to manually run the alter table commands simply results in the same error:

MariaDB> alter table wp_redacted_commentmeta convert to character set utf8mb4 collate utf8mb4_unicode_ci;
ERROR 1071 (42000): Specified key was too long; max key length is 1000 bytes

Never mind, I fixed it. Now needs this in the nginx config (I’m not sure why it was working without this previously and now needs it):
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

Okay, after further debugging, there’s a bug with the makeUrlHttps function. I haven’t tried to debug it fully because the function is huge and there’s no obvious trigger (for example, some scripts included on pages are broken, but some others work properly). I just have the following workaround inserted before the return statement in that function and everything is now working correctly (including the redirect to wp-login):
$string = str_replace('https://www.example.com', 'https://secure.example.com', $string);

Workaround: I added a filter on ‘wp_redirect’ that just does a str_replace for ‘https://www.example.com’ to ‘https://secure.example.com’. I did have a go at working out which function from WordPress HTTPS I should be calling, but the ones I tried didn’t quite do what I expected.

Of course, I’ve just realised that my workaround doesn’t work if you request the secure /wp-admin/ while not logged in, because that still sends you to the www URL for the login page, and thus breaks. This needs fixing in the plugin.