Paul Biron

Thanx Pedro!

I just tested a PDF replace (in Windows, don’t have time at the moment to test Linux), and it seems to work now.

Thanx Pedro!

I’ve done a few tests (in the same environment as my original message, except WP is now updated to 6.1.1 and the OS is Win11 Pro f/ Workstations [22H2, 22621.819]), and it seems to be working great.

I tested with both Just replace the file or Replace the file, use the new file name, and update all links, as well as replacing a PNG with A JPG and vice versa.

Trac Ticket 56855 has been opened for this and there is a patch on that ticket

I’m seeing the same problem. Here’s some info I’ve discovered while stepping thru both the 3.6.3 and 4.0.0 code in a debugger:

1. the problem seems to be in the new FileModel class (just like the problem I reported in regression in 4.0.0 on windows. Same class, but different problem and in this case the problem is not Windows-specific)

2. the emrFile::__construct() method in 3.6.3 uses wp_check_filetype_and_ext() to get the mime type of the file (the “sourceFile” in this case); whereas, FileModel::getMime() in 4.0.0 uses wp_get_image_mime(), which only works for images.

It is because of #2 that version 4.0.0 only knows what the mime type of the sourceFile (i.e., the existing file that is being replaced) when it is an image file…and not when it’s a “document” (e.g., a PDF, XLSX, etc). I came across the problem when trying to replace an XLSX file.

Here’s the environment info: on Windows (where I stepped thru things in the debugger):

OS: Win11 Pro for Workstations (21H2, 22000.918)
PHP: 7.4.29
WP: 6.0.2
Apache: 2.4.53
MySQL: 5.7.38

And on Linux (where I first discovered the problem on a live site):

OS: CentOS 7
PHP 7.4.27
WP: 6.0.2
Apache: 2.4.6
MySQL: 5.7.36

thanx for the update.

I don’t believe that the WP Plugin Directory Guidelines prohibit a plugin from “forcing” itself to be auto-updated. I just think it is bad practice to take that choice away from the site admin/owner.

I can understand plugin authors wanting to make sure that site admins/owners are always using the latest version of their plugins…but that decision should really be in their control (and ultimately, it is…since they can always define the AUTOMATIC_UPDATER_DISABLED constant to true and then no auto-updates will happen, and there are several other means to disable auto-updates across the board).

If you want to encourage site admins/owners to auto-update your plugin I think the better means would be to add your plugin to the auto_update_plugins option (which is what the Auto-Update UI does). But if you go that route, be sure you don’t corrupt the value of that option…as doing so would interfere with all of the other conscious choices the site admins/owners have about whether to auto-update other plugins.

If you don’t mind my asking: why do you want to force your plugin to be auto-updated?

I just opened a PR which fixes this problem. Hopefully James will merge it soon.

OK, good to know. Thanx.

Sorry, been busy.

The plugin that I think is causing the conflict is Polylang (free).

Thank you.

You are correct and I have discovered the plugin that is causing the problem.

I will contact the author of that plugin and see if I can resolve this with them.

Please keep this topic open for a little bit while I try to reach the author of that other plugin.

To quote Homer Simpson, “D’Oh!!!”

I hasn’t even noticed until now that line further down in the changelog about MYSQLI_CLIENT_SSL support. When I originally, scanned the changelog I saw WAF and SQL, opened this topic and didn’t read any further in the changelog ??

> Added MYSQLI_CLIENT_SSL support to WAF database connection

Cool!! That’s specifically why I asked my original question. I knew you were working on support encrypted connections with the MySQLi storage engine and was wondering if that’s what the changelog entry was about.

Thanx for following up! I’ll dig in some more and see if this releases solves a problem I’ve had in that regard.

I just wanted to make sure it wasn’t a change related to the WAF MySQLi Storage Engine.

thanx

Plugins can be installed both by uploading a *.zip file and through the UI, so unzip appears to be working fine.

When the Zip module is not present, WordPress will try to use the zlib module as a fallback. I suspect that zlib is installed/enabled, which is why uploading *.zip files worked fine.

Glad I could help!