[wp-trac] [WordPress Trac] #45528: load_script_textdomain() doesn't load translations when WP installed in a subdirectory with custom content dir

[WordPress Trac]

#45528: load_script_textdomain() doesn't load translations when WP installed in a
subdirectory with custom content dir
-------------------------------------------------+-------------------------
 Reporter:  fierevere                            |       Owner:  herregroen
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  5.0.2
Component:  I18N                                 |     Version:  5.0
 Severity:  normal                               |  Resolution:
 Keywords:  has-screenshots has-patch has-unit-  |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------
Changes (by dimadin):

 * keywords:  has-screenshots has-patch has-unit-tests fixed-5.0 => has-
     screenshots has-patch has-unit-tests


Comment:

 ''Let me start by saying that JavaScript translations feature was rushed,
 without consideration what backward compatibility it will break (like
 mentioned in comment:10:ticket:45425 or #45530), and since WP 5.0 is
 rushed, without having a chance for proper testings.''

 I discovered this problem while testing [44232] that is included in
 5.0.2-RC1. Accidentally, site I was testing had activated
 [https://wordpress.org/plugins/commonwp/ plugin] I made just recently and
 it turned out that it prevented JavaScript translations for block editor
 from loading with 5.0.2-RC1 while it didn't do that with 5.0 and 5.0.1.
 Since plugin uses `script_loader_src` filter, it was obviously something
 related to [44209], and I decided to investigate `load_script_textdomain`
 function and how it actually gets relative path it uses.

 ''few hours later''

 So what `load_script_textdomain` does is gets handle's `_WP_Dependency`
 object and from object's `src` property (handle's source) tries to get
 relative path. It assumes that handle's source is in WordPress
 installation, if it's not, it fails.

 Problem is that (as far as I can see) `load_script_textdomain`
 unnecessarily applies `script_loader_src` filter on handle's source before
 it starts getting relative path. Why unnecessarily? Because
 `script_loader_src` filter should change handle's source just before it's
 printed on a page, while `load_script_textdomain` function needs raw
 handle's source, like when it was registered, it doesn't depend on final
 source used for printing. If source is not on WP, it'll fail anyway. With
 filter, we are only increasing chances of source not being on WP and
 failing.

 In any case, `$src` parameter that `load_script_textdomain` function
 passes to `script_loader_src` filter is different than one that is
 [https://core.trac.wordpress.org/browser/branches/5.0/src/wp-
 includes/class.wp-scripts.php?rev=43898#L332 originally] passed to the
 filter in  `WP_Scripts::do_item()` method: it lacks `ver` query argument.
 Pre-[44209] it also didn't make full URL for handle's source when it's
 relative path, this is the reason why I didn't notice problem before
 (source wasn't full URL).

 After removing `script_loader_src` filter, I didn't see any problem.

 > Building the proper relative path also fails when the assets are served
 from another server, like for example for Jetpack CDN.

 This is only true for plugins, like Jetpack, that don't use filters to
 change source and instead
 [https://github.com/Automattic/jetpack/blob/49dda1a6e4f0f55ed93f81bd9e7d558e551bf0ae/modules
 /photon-cdn.php#L64 forcefully change] `src` property of handle's
 `_WP_Dependency` object. We shouldn't require that now all plugins that
 use `script_loader_src` filter also need to use
 `load_script_textdomain_relative_path` filter, this is backward
 incompatible and unannounced, and it kinda punishes those that used
 standard way from the start because some didn't.

 **tl;dr** I propose to remove `script_loader_src` filter from
 `load_script_textdomain` function.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/45528#comment:40>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform