Hi-
Our client would like to let people sign up to receive emails when pages in the Pages plugin are updated.
Is there some existing functionality we can use to implement this, or do we need to build something custom?
let visitors sign up for email updates when Pages are updated in Pages plugin
Wed, 2016-07-13 09:51
#1
let visitors sign up for email updates when Pages are updated in Pages plugin
What you're describing seems very similar to what the Rules plugin currently does for Resources. Unfortunately, Rules has not yet been extended to support non-Resource schemas. Doing so is on our roadmap for an, but we don't yet have any definitive timeline for when that might be completed.
I'd suggest writing a custom plugin that hooks EVENT_RESOURCE_MODIFY looking for changes to Pages and calling out to Mailer::SendEmail() when it finds changes.
So, the Pages plugin fires an event upon adding or editing? What event does it fire? I didn't see it in the Pages plugin code.
Ugh, sorry. I was consuing Pages and CalendarEvents, the latter of which fires EVENT_RESOURCE_MODIFY whenver a resource is modified (by virtue of using EditResource for editing). Pages has a custom editing interface which doesn't fire EVENT_RESOURCE_MODIFY (though, I suspect it should. We'll discuss amonst ourselves about changing that).
In the meanwhile, maybe consider something similar to how Rules::PeriodicRuleCheck() works. Namely, hook a function to EVENT_PERIODIC that runs with a configurable delay, that tracks when it was last run, and that uses Mailer::SendEmail() to fire notifications about any Pages changed based on the Date Last Modified field in the Pages schema.
Version 3.9.1 will signal
EVENT_RESOURCE_MODIFYwhen pages are edited.Great, thank you!
Can I ask why it will fire EVENT_RESOURCE_MODIFY since Pages are not a Resource? I am probably just missing something :)
In recent versions, pages are Resources (i.e. the
Pages_Pageclass is descended fromResource), as are events (CalendarEvents_Event), and blog posts (Blog_Entry) - they each have their own metadata schema, viewable and editable via the Metadata Field Editor. In part, it's what allows the search engine to find and display all of those disparate types of content in a unified interface.Oh ... got it now :)
It didn't used to be that way, but the code was refactored, out of a need for sanity. :-)