search

wp-cli / language-command

Installs, activates, and manages language packs.
MIT License
13 stars 21 forks source link

Tests break on WP `trunk` - `ls: cannot access - no such file or folder` #81

Closed schlessera closed 5 years ago

schlessera commented 5 years ago

The tests currently fail on WP trunk with the following error:

ls: cannot access /tmp/wp-cli-test-suite-cache-language-core.feature.4-5cb78382e69bd8.76370729/translation: No such file or directory

It seems to have for core language, plugin languages and theme languages.

Here's one example of where that is happening: https://travis-ci.org/wp-cli/language-command/jobs/521353616#L720

Related https://github.com/wp-cli/wp-cli/issues/5192

swissspidy commented 5 years ago

It's weird that this only happens to trunk. I can't think of any changes there that might have caused anything in that regard.

The error message indicates that packages are not cached by WP-CLI for some reason, causing the translation folder not to be created in the first place.

schlessera commented 5 years ago

Were there changes with the filesystem abstraction, maybe?

swissspidy commented 5 years ago

These classes haven't changed in almost a year except for documentation changes, at least at first glance.

Then, there was this change to the language upgrader recently: https://github.com/WordPress/wordpress-develop/commit/4052571ed7805dd86a3b48c8d8249844558b0442

Introduces Language_Pack_Upgrader::clear_destination() to clear existing translations before installing new translations. Ensures that unused translations in JSON format are cleaned up.

schlessera commented 5 years ago

Could be related to https://core.trac.wordpress.org/changeset/45262

Disables signature tests for Plugins, Themes, and Translations, leaving only core updates.

swissspidy commented 5 years ago

You mean the disabled signature tests or the whole signature thing in general?

schlessera commented 5 years ago

If I understand correctly, WP added signature tests to translations as well, even though they should now be disabled.

That means the code path for downloading the translations must have changed for that too.

swissspidy commented 5 years ago

@schlessera I think you're right. In the current nightly build, signature verification in download_url() is on by default. https://core.trac.wordpress.org/changeset/45262 disabled it.

So perhaps we just need to wait for the newest nightly to be built and explicitly disable signature verification everywhere.

That core changeset changes some method signatures, so we might want to update our child classes accordingly.

swissspidy commented 5 years ago

Also, the code seems to silently swallow that signature verification error message / WP_Error, which we also might want to improve.

schlessera commented 5 years ago

Also, the code seems to silently swallow that signature verification error message / WP_Error, which we also might want to improve.

I suspected something like that might be the case, and the ls being triggered on a non-existing directory is just a symptom of the error not being checked.

We should fix the error detection first.