You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I installed the latest version (3.2.2) of https://wordpress.org/plugins/duplicate-post/ to my WordPress. While running plugin checksum with cli version 1.5.1 I get the following error:
| duplicate-post | duplicate-post-jetpack.php | File is missing |
| duplicate-post | duplicate-post-wpml.php | File is missing |
Those files are indeed missing, but they are not in the original plugin zip either. It seems that they've been moved into compat/ folder a few releases ago.
It seems that https://downloads.wordpress.org/plugin-checksums/duplicate-post/3.2.2.json still returns those two moved files and their checksums in the root of the plugin. Could there be some issue in the cheksum endpoint so that it keeps deleted files in it even though they do not exist anymore?
Yes, that will indeed be the case, given how the current checksum generation on the server works.
The main problem is that plugin authors can do arbitrary changes to a plugin without modifying the version number. This creates a lot of edge cases that we need to take care of.
We currently do indeed miss a mechanism to define a file as having been removed. This is something that we will need to implement upstream in the generation code and then adapt the checking logic here in the command afterwards.
The plugin wp-accessibility, as of version 1.6.4, also has this issue. In the last update, it moved to a stable branch (which is where the download is coming from). The checksums .json still points to the trunk, however. Are they doing something wrong or is WP-CLI looking in the wrong place for the checksums?
| duplicate-post | duplicate-post-jetpack.php | File is missing |
| duplicate-post | duplicate-post-wpml.php | File is missing |
Plugin checksums cannot be used in this way, File is missing is not a valid error. Unexpected file exists on disk IS an error, but File is missing is not supported by checksums.
In future, someday, you'll be able to say File is optional and exists via https://meta.trac.wordpress.org/ticket/6275 but likely never will be able to say File should be here but is missing.
Activity
schlessera commentedon Apr 25, 2018
Yes, that will indeed be the case, given how the current checksum generation on the server works.
The main problem is that plugin authors can do arbitrary changes to a plugin without modifying the version number. This creates a lot of edge cases that we need to take care of.
We currently do indeed miss a mechanism to define a file as having been removed. This is something that we will need to implement upstream in the generation code and then adapt the checking logic here in the command afterwards.
timkite commentedon Sep 5, 2018
The plugin wp-accessibility, as of version 1.6.4, also has this issue. In the last update, it moved to a stable branch (which is where the download is coming from). The checksums .json still points to the trunk, however. Are they doing something wrong or is WP-CLI looking in the wrong place for the checksums?
rajcz commentedon Jan 25, 2023
Hello, classic editor or ninja-forms too. After years any update with this?
dd32 commentedon Oct 2, 2024
Just to confirm from a meta-side of things.
Plugin checksums cannot be used in this way,
File is missingis not a valid error.Unexpected file exists on diskIS an error, butFile is missingis not supported by checksums.In future, someday, you'll be able to say
File is optional and existsvia https://meta.trac.wordpress.org/ticket/6275 but likely never will be able to sayFile should be here but is missing.schlessera commentedon Nov 1, 2024
Fixed via #131