3.2.0 Update not showing up

[humptydumpty]

@girish you published package 3.2.0, but it's not showing up in my CR dashboard even when manually searching for an update. I'm on 3.1.2. (org.wordpress.unmanaged.cloudronapp@3.1.2).

Cloudron server v7.5.0 (Ubuntu 22.04.1 LTS)

[girish]

@humptydumpty that was an oversight, please try again now.

[humptydumpty]

Yep, working now. Thank you!

[humptydumpty]

@girish One of my sites gets stuck at "starting" after upgrading to 3.2.0. I reverted to a backup, and manually upgraded WP to 6.3.0 from the WP dashboard after confirming the issue was theme related (needed an upgrade beforehand). The site runs fine until I upgrade the Cloudron WP package to 3.2.0. Thoughts?

[girish]

@humptydumpty Can you check in the logs where i gets stuck? I have seen this happen if a site is compromised. Can you check the contents of wp-config.php or wp-include.php before updating? Often, it has a suspcious include line.

[girish]

@humptydumpty Do you see any message like Error: A foreign object cache drop-in was found. To use Redis for object caching, run: wp redis update-dropin. ?

[humptydumpty]

Yes, that was one of the things that stood out. There was also something like connection refused that repeated like 50 times. Then, health check failed after 7000 (m)s?

At first, there was a mention of an error in the theme php file and I got that sorted out. It still refused to start though. My other sites are fine. I'm not using the redis plugin that Cloudron preinstalls on all my sites as I'm using W3TC's redis on some of my sites.

[humptydumpty]

@girish OK, so both sites that are failing use W3TC's Redis feature and not Redis Object Cache. The sites that do use Redis Object Cache updated just fine.

[girish]

@humptydumpty thanks, I am pushing a fix.

[humptydumpty]

@girish Great. I was about to try the CLI "wp redis update-dropin" thing. But here's a copy paste in case something else is at play.

Aug 10 22:17:09 Connection refused
Aug 10 22:17:17 => Healtheck error: Error: Timeout of 7000ms exceeded
Aug 10 22:17:27 => Healtheck error: Error: Timeout of 7000ms exceeded
Aug 10 22:17:37 => Healtheck error: Error: Timeout of 7000ms exceeded
Aug 10 22:17:47 => Healtheck error: Error: Timeout of 7000ms exceeded
Aug 10 22:17:50 => Healtheck error: Error: connect EHOSTUNREACH 172.18.19.156:80

[girish]

wp redis update-dropin works but this happens because you are using some other object cache. Running that command will disable your current object cache.

[humptydumpty]

I think I made the switch for performance reasons. It's been a while and I forgot the specifics. Anyway, I'll switch back to Redis Object Cache in the morning.

[girish]

@humptydumpty Can you check with the latest package?

[humptydumpty]

In short, package 3.2.0-2 has no breaking issues but requires manual enabling of Redis and manual updating of WP 6.3. See below for details.

---

Enabling Redis Manually

On the W3TC sites, the update installed Redis Object Cache and disabled W3TC's object cache with a message (Object Cache is disabled via filter.). However, Redis wasn't enabled in Redis Object Cache by default, I had to manually do that to get it going.

---

Updating WP to 6.3 Manually

I have a staging site (non-W3TC, but is using that problematic theme I mentioned yesterday), Redis Object Cache was/is installed and enabled. I applied the package update 3.2.0-2 today. However, it didn't update WP to 6.3. I'm still seeing the update message in WP dash:

Edit: I forgot to mention that these sites were still on package 3.1.2 and did not have 3.2.0-1 installed (I reverted to a backup and disabled auto-updates yesterday). Perhaps that's why it didn't update WP 6.3?

[girish]

@humptydumpty said in 3.2.0 Update not showing up:

manual updating of WP 6.3

Note that with developer edition package, this is/was always the case. You have to update WP yourself from within the app.

[humptydumpty]

On an unrelated note, there's an option in WP dash > Updates to have it auto-install new releases. I noticed some of my sites have that enabled and some don't. It's not a problem, but I mention it because maybe that should be disabled/hidden somehow since this should be handled by the packaging updates.

Edit: just noticed your latest reply, so I guess WP was auto-updating most of my sites and I thought the packaging was doing that.