Regression - Missing Languages update section

[selven99]

Hello,

Since I updated my websites to Wordpress 4.9, Languages Update section disappears in Dashboard > Updates section!

After some debug, I found the issue with the new capabilities added in this version.

​https://github.com/WordPress/WordPress/blob/4.9-branch/wp-includes/capabilities.php#L443

Here:

<?php
    if ( ! wp_can_install_language_pack() ) {
        $caps[] = 'do_not_allow';
    } elseif ( is_multisite() && ! is_super_admin( $user_id ) ) {
        $caps[] = 'do_not_allow';
    } else {
        $caps[] = 'install_languages';
    }

The first line will check if FTP (or SFTP/SSH) details are corrects and if wordpress can access to filesystem. But, creditentials are not provided in this step, we can fill them only after click to "Update translations" button (that is missing...).

So, I think this implementation is incorrect and should be:

<?php
    if ( ! wp_is_file_mod_allowed( 'can_install_language_pack' ) ) {
        $caps[] = 'do_not_allow';
    } elseif ( is_multisite() && ! is_super_admin( $user_id ) ) {
        $caps[] = 'do_not_allow';
    } else {
        $caps[] = 'install_languages';
    }

What do you think about this?

Thanks! :-)

[dd32]

Hey @selven99 and welcome to Trac.

Thanks for reporting this, for reference, the changes related to this were introduced in [41268] via #39677.
Pinging @flixos90 for investigation.

Marking as 4.9.2 for tracking purposes only.

[Presskopp]

related #42767

[dd32]

#42767 was marked as a duplicate.

[flixos90]

Thanks @selven99 for the ticket and also suggestion to fix. I applied it in 42697.diff​, including related adjustments:

• By using wp_is_file_mod_allowed(), we make the capability check for install_languages less restrictive. It was indeed wrong before, as a user should still be able to have the capability, even when language packs cannot be automatically installed. The automatic installation part is separate from that now.
• Another benefit from that change is that we don't need to load the related admin files on the fly in the frontend.
• The "downside" is that of several conditionals now need to check for both the capability and whether language packs can be installed without asking for credentials. However, I'd only consider this a downside because of more code. The two checks actually need to be separate things, for the above reasons.

[obenland]

The "downside" is that of several conditionals now need to check for both the capability and whether language packs can be installed without asking for credentials. However, I'd only consider this a downside because of more code. The two checks actually need to be separate things, for the above reasons.

Would this be something that could be moved into map_meta_cap()?

[dd32]

Apologies for the delay in reviewing @flixos90
Looking at 42697.diff​ the capability change looks correct, however I question the changes to show_available_translations.

It seems to me that this is probably expected as-is, if it can't install the language it'd do it on the next time it does have access. The user-experience of that would be pretty bad though - They'd either a) Select it and it not take immediate effect or b) not be able to change languages to a non-installed one at all.

For this ticket, it seems that a) is probably okay, although not great. Further enhancement is needed for it to instead trigger the FTP credentials request to install the language selected IMHO.

[flixos90]

@obenland It was in there before, but that’s what ended up not working, as you should generally be able to install languages even if you need to provide FTP credentials for it.

@dd32 The original behavior was using wp_can_install_language_pack() in show_available_translations (see [41268]). While I agree with you that this is far from optimal, I think we should add it back in for now to fix the regression, with further changes being part of a new enhancement ticket.

[dd32]

Replying to flixos90:

The original behavior was using wp_can_install_language_pack() in show_available_translations (see [41268]). While I agree with you that this is far from optimal, I think we should add it back in for now to fix the regression, with further changes being part of a new enhancement ticket.

Got it, that makes sense to me then!

[dd32]

Bumping to 4.9.3 due to 4.9.2s release

[SergeyBiryukov]

In 42606:

Role/Capability: Make install_languages capability check less restrictive.

A user should still be able to have the capability, even when language packs cannot be automatically installed. The automatic installation part is separate from that now.

Props flixos90.
Fixes #42697.

[SergeyBiryukov]

In 42607:

Role/Capability: Make install_languages capability check less restrictive.

A user should still be able to have the capability, even when language packs cannot be automatically installed. The automatic installation part is separate from that now.

Props flixos90.
Merges [42606] to the 4.9 branch.
Fixes #42697.