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
On my site where I'm using WordPress in a wp subdirectory (i.e. my WP Admin is not under /wp-admin, but rather /wp/wp-admin), I consistently get JS errors like when browsing my WP Admin:
Uncaught (in promise) bad-precaching-response: bad-precaching-response :: [{"url":".../wp-admin/images/wheel.png","status":404}]
It's different WordPress core images depending which admin screen I visit, but the underlying problem is that the PWA plugin does not consider the correct admin URL. I believe this problem happens due to
, where the code assumes the wp-admin folder is in the root of the domain.
A possible solution would be to rely on the site_url() function to get the right location: If WordPress is in a subdirectory, the site URL would include that. So if it does, that directory should be added to the actual folder as a prefix.
(FWIW since that method is also used for image files in wp-includes, the bug is probably present there as well. The same approach I suggested above should fix that problem too.)
The text was updated successfully, but these errors were encountered:
On my site where I'm using WordPress in a
wp
subdirectory (i.e. my WP Admin is not under/wp-admin
, but rather/wp/wp-admin
), I consistently get JS errors like when browsing my WP Admin:It's different WordPress core images depending which admin screen I visit, but the underlying problem is that the PWA plugin does not consider the correct admin URL. I believe this problem happens due to
pwa-wp/integrations/class-wp-service-worker-admin-assets-integration.php
Line 156 in 56b3d8d
wp-admin
folder is in the root of the domain.A possible solution would be to rely on the
site_url()
function to get the right location: If WordPress is in a subdirectory, the site URL would include that. So if it does, that directory should be added to the actual folder as a prefix.(FWIW since that method is also used for image files in
wp-includes
, the bug is probably present there as well. The same approach I suggested above should fix that problem too.)The text was updated successfully, but these errors were encountered: