Someone installs your WordPress PWA, opens a product list that still shows yesterday’s stock, and looks for a refresh control that does not exist. Browser chrome is gone in standalone display mode. Pull gestures fight sticky headers. The overflow menu is a mystery. They force-close the tile, reopen it, and still wonder whether the data is fresh. Native apps taught people that a quick shake can mean “try again.” Your PWA can offer that same muscle memory when Progressify’s shake to refresh is on.
Progressify includes shake to refresh as part of the app-like UI: a gesture that refreshes the current view when the visitor shakes the device. It layers over the theme you already run. You do not rebuild templates for a floating refresh icon. You enable the Progressify control and let the gesture do the reload work people already expect from phones.
Progressify is the DaftPlug PWA plugin. This post is only about shake to refresh. Not pull to refresh as a deep dive, not wake lock, not haptics as a deep dive, not the native share button, not splash screen or theme colour, not the bottom tab bar, not dark mode, not smooth page transitions, not idle detection, not push notifications, not offline cache, not install prompts, not Android or iOS store builds, not skeleton loaders, not toast messages, not background sync, not autosave forms. Those live elsewhere. For an adjacent app-like action after install, keep WordPress PWA native share button nearby.
What Progressify actually ships here
Stay inside the real feature set:
- Shake to refresh as a device gesture that refreshes the current view (the shake path, not a custom pull-to-refresh essay)
- App-like UI layered over the theme you already run, so the gesture sits with the rest of Progressify chrome rather than living as a theme fork
- Theme-agnostic behavior: Progressify works with any theme or plugin stack you already use
- A settings-level enablement path inside Progressify rather than inventing accelerometer scripts in
footer.php
This post does not invent undocumented motion thresholds, per-page shake allowlists Progressify does not publish, analytics claims for shake events, or promises that desktop browsers without motion sensors behave like phones. The product promise is shake to refresh as part of the app-like UI layer. Stay there. Pull to refresh, wake lock, haptics, share, splash, tab bar, and offline are parallel tools, not this article’s job.
Why shake to refresh matters on a WordPress PWA
Standalone mode hides the browser refresh button. After Add to Home Screen, people often lose the address bar and the familiar reload icon. Without a deliberate refresh path, stale lists feel broken even when the site is fine. A shake gesture restores a known phone habit without painting a permanent floating button over your CTAs.
Commerce and membership views go stale fast. Cart counts, ticket availability, course progress, and dashboards change while the app stays open. Waiting for a full relaunch trains people to distrust the tile. Shake gives a low-friction “get me the latest” without teaching a custom toolbar.
It matches how people already treat phones. Shake-to-undo and shake-to-refresh show up across OS and app cultures. You are not inventing a weird gesture. You are meeting an expectation Progressify already exposes in the app-like UI set.
Theme rebuilds are the wrong fix. Agencies sometimes add a circular refresh icon in the header for PWA-only CSS. That icon drifts every redesign. Progressify’s shake control lives in the product settings, not in a child theme that three freelancers will overwrite.
It complements, not replaces, other refresh stories. Pull to refresh may exist as a sibling in the same UI family. This post stays on shake. You can enable one gesture, verify it, then decide whether a second refresh path helps or confuses. Bundling every UI toggle on day one makes failures hard to attribute.
How to enable shake to refresh in wp-admin
Assume Progressify is installed, HTTPS works, and the PWA can already install (manifest, service worker, basic icons). Shake is a phone story. Desktop DevTools helps you confirm settings. A real device confirms the gesture.
1. Decide which screens deserve a refresh habit
Shake helps most on lists and dashboards that change: shop archives, account pages, event calendars, support ticket views, and content hubs with frequent updates. It helps less on long static essays where a shake mid-read is surprise reload. Mentally mark the templates where you will verify after enablement. You are not inventing undocumented Progressify exclusions. You are planning the smoke test.
2. Open Progressify and enable shake to refresh
In wp-admin, open Progressify. Find shake to refresh among the app-like UI options Progressify exposes. Enable it. Keep the first pass boring: turn on shake to refresh alone, leave pull to refresh, wake lock, haptics, share, tab bar, dark mode, transitions, idle detection, skeletons, and toasts alone until shake is verified. Five toggles at once create mystery regressions.
3. Confirm it layers over the theme instead of fighting it
Progressify is theme-agnostic. Shake should refresh the current view as part of the Progressify UI layer, not require a custom template. On a phone, open a busy archive, shake once, and confirm the page reloads cleanly. Watch sticky headers and fixed cart bars. A reload should not leave a broken overlay. If a page builder already injects its own refresh widget, decide which story wins.
4. Smoke-test the gesture on a real device
Desktop motion simulation is incomplete. A phone in your hand is truth.
- Install or open the PWA on a phone over HTTPS.
- Navigate to a public list or dashboard URL that is safe to reload.
- Shake the device firmly once (not a tiny wrist flick).
- Confirm the view refreshes and the URL you meant is still the one on screen.
- Repeat after scrolling mid-page so you know a deep scroll does not strand the visitor in a weird state.
- Try once in portrait and once in landscape if your theme reflows aggressively.
- Compare iOS and Android once. Motion permission and sensitivity differ by platform. Progressify’s job is to offer the shake refresh path. Your job is to notice if a page is a bad candidate (multi-step forms mid-entry, payment screens).
If a page holds unsaved form input, do not market shake as a casual habit there. Refresh is not a save system.
5. Keep install presentation and shake as separate wins
If the cold open still shows a blank white tile, fix splash, theme colour, and display mode first in their own pass. Shake is the verb after the app already feels intentional. Shipping a solid shake into a browser-chrome shell is still progress, but the full app story is branding plus gestures.
6. Document the enablement for the next teammate
Write one line in your internal runbook: “Progressify shake to refresh enabled on [date]. Verify after theme or header redesigns and after major WooCommerce template updates.” Gesture UX gets blamed when designers ship a new sticky bar or when people report “the app reloads randomly” during bumpy commutes. Knowing the control lives in Progressify saves an hour of hunting theme JS.
Who this is for
WooCommerce and product marketers whose catalogs and stock views change while the installed app stays open.
Membership and course sites where dashboards and lesson lists should feel current without a full relaunch.
Content hubs and news-style blogs that publish often and want readers in the installed app to pull fresh home or archive views quickly.
Agencies shipping PWAs for clients who asked for “app-like” and expect phone gestures next to share and tab bar stories.
Anyone tired of explaining “swipe down somewhere, or kill the app” in support tickets when visitors cannot find a reload control in standalone mode.
This is less urgent for pure brochure sites that rarely change, or for desktop-first tools where motion gestures never fire. Even then, your mobile install audience may still thank you.
What good looks like
- Shaking a real phone refreshes the current PWA view, not a random tab in the background browser.
- The gesture works over your existing theme without a child-theme refresh icon.
- Lists and dashboards feel current after shake without forcing a home-screen relaunch.
- Pull to refresh, wake lock, haptics, share, splash, theme colour, tab bar, dark mode, transitions, idle detection, push, offline, install prompts, store builds, skeletons, toasts, background sync, and autosave forms were not required for this win.
- You did not invent custom accelerometer thresholds or claim every desktop browser matches mobile shake UX.
- A teammate can install the PWA, open an archive, shake once, and describe the flow in one sentence.
If settings look enabled but a real device does nothing, confirm HTTPS, confirm you are in the installed PWA or a supporting mobile browser, confirm shake to refresh is still enabled after a settings save, and confirm the page is not a weird preview URL. Stale admin assumptions cause more false alarms than service workers for this feature.
Pitfalls (the ones that bite)
Confusing shake to refresh with pull to refresh. Both may exist in the wider Progressify UI family. This article is the shake path. Verify one gesture before you debate the other.
Enabling every app-like toggle at once. If shake, share, tab bar, and dark mode all land together, you cannot tell which change moved a CTA or caused a surprise reload. Enable shake, verify, then add the next piece.
Putting shake energy on multi-step checkout. Accidental shakes on a bus should not wipe a payment form mid-flow. Prefer list and dashboard verification first. Treat checkout as a careful exception.
Leaving a custom theme refresh button active. Duplicate refresh stories confuse people. Pick Progressify shake or the theme icon, not both forever.
Promising motion analytics Progressify does not advertise. Stay at product level: shake to refresh, app-like UI, works with any theme.
Treating shake as a Core Web Vitals fix. Shake is refresh UX. It does not replace caching, image work, or deferred scripts.
Ignoring bumpy-commute false positives. If support hears “the app reloads when I walk,” re-test sensitivity expectations on real devices and decide whether those templates should rely on shake at all.
Practical checklist before you call it done
- Confirm the PWA installs on a real phone over HTTPS.
- Enable Progressify shake to refresh by itself.
- Open a public archive or dashboard in the installed app and shake once.
- Confirm the view refreshes and the URL remains correct.
- Repeat after a mid-page scroll.
- Avoid celebrating the win on unsaved forms or payment steps until you have a policy.
- Spot-check iOS and Android once.
- Disable or hide any redundant theme refresh widget if it fights the Progressify story.
- Leave pull to refresh deep-dives, wake lock, haptics deep-dives, share, splash work, tab bar, dark mode, transitions, idle detection, push, offline, install prompts, store builds, skeletons, toasts, background sync, and autosave forms for separate passes if they are not already stable.
- Re-test after the next header or theme redesign. Floating UI and gesture expectations drift.
Takeaway
A WordPress PWA that hides browser chrome still needs a way to fetch a fresh view. Force-closing the tile is friction. A custom header icon is maintenance. The cleaner path is Progressify’s shake to refresh: a phone gesture layered over your theme, available without rebuilding templates for every redesign.
Progressify handles shake to refresh alongside the rest of the PWA stack, without asking you to maintain accelerometer snippets in the theme. Enable it once. Test on a phone you actually hold. Keep other UI features as separate enablement work.
One Pro membership unlocks Progressify plus Lightify, Generatify, Rankify, and Snapshotify. New Pro plugins join existing memberships. Plans differ by site count only (Pro $37.99 for 1 site, Pro Plus $74.99 for 5, Pro Max $138.99 for 100), with a 14-day money-back guarantee. See pricing when the installed app should refresh with a shake instead of a force-quit.
Enable shake to refresh. Open a list that changes. When a real shake reloads the view you meant, the PWA finally behaves like the rest of the apps in someone’s pocket.