Drip-fed content that’s not releasing on its configured schedule — a lesson staying locked past its release date, or unlocking early — usually points to the schedule’s underlying trigger (a fixed date, or days since enrolment) not calculating correctly against a specific member’s actual data.
Check one affected member’s actual enrolment date against the schedule
Find a specific member whose content hasn’t unlocked as expected and check their actual enrolment date against the drip rule’s stated delay. A schedule based on days-since-enrolment fails differently than one based on a fixed calendar date, so knowing which type is configured narrows this down quickly.
Content dripping schedule repair
Drip-fed content stuck on the wrong schedule, traced to the actual date or timezone calculation behind it.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| Drip-fed content isn’t releasing on schedule for specific members | This fix covers it |
| You want a drip schedule configured for the first time, not an existing one fixed | Membership level & drip content configuration |
| The issue is broader access permissions, not specifically drip timing | Course & lesson access permission errors |
| Two plugins are both trying to control drip timing and conflicting | Access rule conflict between plugins |
What you are seeing
- Content staying locked past its intended release date
- Content unlocking earlier than scheduled
- The issue affecting only members who enrolled after a specific date
- Correct behaviour for some members but not others on the same drip rule
Common causes
- A days-since-enrolment calculation using the wrong enrolment date field
- A fixed-date rule not accounting for a timezone difference
- A plugin update changing how drip timing is calculated
- A caching issue serving a stale, pre-unlock version of the content page
- A membership upgrade or downgrade mid-course resetting the drip clock instead of preserving original progress timing
What we do
- Reproduce the specific scheduling discrepancy with an affected member
- Review the drip rule’s configuration against its intended logic
- Correct the underlying calculation or caching issue
- Verify the fix against the originally affected member
- Check for the same pattern across other members on the same rule
What is included
- The drip scheduling issue identified and corrected
- Verification against the originally affected member
- A check across other members on the same rule
- The pre-fix backup, kept for 30 days
Not included
- Configuring a drip schedule from scratch — a separate, related fix
- Broader access permission issues unrelated to drip timing — a separate, related fix
- Resolving a conflict between two plugins both controlling drip timing — a separate, related fix
- Ongoing monitoring for future scheduling issues
Questions about this fix
Why would this affect only members who joined after a certain date?
If the underlying cause is tied to how a specific enrolment date field is read, a change to how that field gets populated (from a plugin update, for instance) would only affect accounts created after that change.
Could a timezone difference really cause content to unlock early or late?
Yes, if a fixed-release-date rule doesn't correctly account for the site's configured timezone versus the server's own clock, content can release up to a day off from what was intended.
Will this affect content that's already correctly unlocked for other members?
No, we specifically target the identified discrepancy — members whose content unlocked correctly are unaffected.
Is this urgent if members are complaining about locked content they've paid for?
Worth prioritising if paying members are being denied content they're entitled to on schedule, since that has a direct impact on their experience.
How is this different from a general access permission fix?
This specifically concerns timing — content that will eventually be visible but isn't following its schedule; a general access issue is about content being wrongly visible or invisible regardless of any schedule.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.