Add pretty permalinks for service worker#289
Conversation
| function _pwa_activate_plugin() { | ||
| pwa_add_rewrite_rules(); | ||
| flush_rewrite_rules( false ); | ||
| } | ||
|
|
||
| register_activation_hook( PWA_PLUGIN_FILE, '_pwa_activate_plugin' ); |
There was a problem hiding this comment.
The flushing is only happening upon activation. What about on network-activted multisite?
There was a problem hiding this comment.
I've just inquired the same on wp-sitemaps: GoogleChromeLabs/wp-sitemaps#205
There was a problem hiding this comment.
Haven‘t really tested Multisite, will take a look.
There was a problem hiding this comment.
There was a problem hiding this comment.
cc @felixarntz for Multisite expertise.
There was a problem hiding this comment.
I don't think this will work since $wp_rewrite->extra_rules_top['^wp-service-worker\.js$'] will always be set by pwa_add_rewrite_rules on init.
There was a problem hiding this comment.
Good point. In that case, perhaps pwa_add_rewrite_rules() should check to see if it actually added anything to the array, and if so, set a flag that can be accessed somewhere?
There was a problem hiding this comment.
👋 y'all!
FWIW, since that post was written I've had success with the method posted by Thorsten on this ticket: https://core.trac.wordpress.org/ticket/18450
I've used it on init when the rewrite rules were very important, but it could be used on admin_init as well.
There was a problem hiding this comment.
Thanks for the input! Yes, I'd say this qualifies as being very important since if the PWA plugin is network-activated, all the network sites would try to install the service worker. But if the rewrite rule is not present, then they'd fail to install.
Nevertheless, we're currently blocked on using rewrite rule, at least using .js file extension since various hosts will short-circuit such requests from going to WordPress to instead try to go straight to the filesystem: #287 (comment)
There was a problem hiding this comment.
Now that we have /wp.serviceworker as the route, the only thing left here is making sure that the route will be detected across a network before rewrite rules have been flushed.
Here's an idea: en lieu of waiting for someone to log-in to each site to cause rewrite rules to be flushed, we can implement a fallback route of sorts.
I think I've got a good solution for that in 043beb8.
|
Since this PR will result in an apparent static JS file being served, let's add a comment to the response to make it clear that the file is dynamically-generated. So in the line after: Add something like: echo '/* ';
/* translators: %s is the WordPress action hook */
printf( __( 'Note: This JS file is dynamically-generated with PHP. To manipulate the contents of this file, use the "%s" action in WordPress.', 'pwa' ), is_admin() ? 'wp_admin_service_worker' : 'wp_front_service_worker' ) );
echo " /*\n\n"; |
|
Sounds good. Does this also need a second rewrite rule for the admin scope service worker? 🤔 |
|
No, the admin service worker is served via |
Co-authored-by: Weston Ruter <westonruter@google.com>
…/sw-rewrite-rule * 'develop' of github.com:GoogleChromeLabs/pwa-wp: (30 commits) Bump prettier from 2.1.0 to 2.1.1 Bump grunt from 1.2.1 to 1.3.0 Avoid constructing asset versions with HTML entities in context of SW Bump grunt-wp-deploy from 2.0.0 to 2.1.2 Bump prettier from 2.0.5 to 2.1.0 Add support for additional version args [Security] Bump dot-prop from 4.2.0 to 4.2.1 Update the way a navigation route is registered Bump eslint from 7.6.0 to 7.7.0 Fix version handling for precached assets Update tested up to 5.5 Bump grunt from 1.2.0 to 1.2.1 Bump eslint from 7.4.0 to 7.6.0 Update wording. The serverOffline message was being shown even though the site was online & working perfectly fine while it was an issue with the client's connection (while they weren't necessarily considered offline.) Bump lodash from 4.17.14 to 4.17.19 CR Allow HTTPS detection and UI to be disabled Add manifest-URL helper Bump grunt from 1.1.0 to 1.2.0 Bump eslint from 7.3.1 to 7.4.0 ...
westonruter
left a comment
There was a problem hiding this comment.
To avoid the problem of wp-service-worker.js bypassing PHP and being routed straight to the file system by web servers, how about we just use wp.serviceworker.
See #287 (comment).
Co-authored-by: Weston Ruter <westonruter@google.com>
|
This is working well according to #287 (comment). Any additional needed changes anyone sees prior to merging? |
|
@westonruter I check wp.org today, but the version is still 0.5 ... |
|
@hideokamoto No, as you can see at https://github.com/GoogleChromeLabs/pwa-wp/milestone/6 version 0.6 is not yet complete. |
|
@swissspidy Thanks ! |
Fixes #287.
To-do: