After following the various pages on tasks I tried to recreate the task.
It seems there is something wrong and this fails.
Anyone else tried this? Is it all correct for v9.1.3
When I updated Extreme Clean to use tasks for v9, the core docs were incomplete and the best info came from the folks in Japan. I can’t remember the details of where/what I read (was over a year ago) and things may well have changed since.
I am just looking for a task I can delete pages that I am dynamically generating. So I don’t end up with hundreds of pages.
If the pages are essentially the same, boilerplate + fill in the gaps, maybe you could use a single page or one regular page with a custom block. Either could use the remainder of the URL to generate the fill-in details from data. Then you only need to do crud on the data rather than on pages.
I’ve followed the documentation for creating tasks pretty successfully, is there a specific spot where you got stuck?
The project is using a widget and the service keeps caching the content to the URL. So the only way around it is to create a new page every time you need to use the widget as the content you give it changes.
It’s a hard one to explain.
I will go back over it with a clean install. So I can give the errors. Might be easier to fix it then correct any docs if needed.
Would conventional cache busting approaches of extending the URL with a random \segment\ or
?query or #fragment fool the widget service?
?query, and #fragment don’t seems to work.
\segment\ would work, but I have one page that many users would need to use, so not sure how that would work.
If you look at how the page list block accepts extra url fragments from the various blog filtering blocks, that would be the basis of creating a minimal block to trick the service widget.
Solution 1.
If you can dynamically configure the widget each time with a path //path/to/page/random_segment, then all you need is a block on the page to accept the /random_segment/ and discard it.
Solution 2.
If not, you may still be able to fool the widget if it will follow a 302 redirect.
Create a minimal block that, when the page loads:
if (//path/to/page/ does not end with a /segment/)
---- 302 redirect to self with a random segment so //path/to/page/random_segment/
else (there is a segment)
---- let the page render as normal
Or if you need to tie the page content to a user, maybe it could use a hash of the user_id or a hash of the session_id for the segment.