use SilverStripe\ORM\DataObject;
class Event extends DataObject {
...
}
use Page;
use SilverStripe\StaticPublishQueue\Contract\StaticPublishingTrigger;
class Trip extends Event implements StaticPublishingTrigger {
public function objectsToUpdate($context) {
return Page::get()->First(); // return 1 or an array of multiple publishable objects you would like to regenerate the static cache for
}
public function objectsToDelete($context) {
return 1; // Return 1 or an array of publishable objects for which you would like to purge the statically cached variant
}
}
I understand your frustration with getting StaticPublishingTrigger to work. Let’s try to troubleshoot this step by step:
Confirm Configuration:
Double-check your YAML configuration for the StaticPublishingTrigger. Ensure it matches the documentation or examples provided in the Silverstripe docs. A minor indentation issue in the YAML file can cause problems.Example configuration:
Permissions:
Ensure that your web server has write permissions to the directory where static files are being published. If permissions are insufficient, the trigger won’t work correctly.
Trigger Events:
Have you confirmed that the events you’re relying on (e.g., onAfterPublish) are firing as expected? You could try adding a simple log message or debug statement in the trigger to see if it’s being executed.
Queue Jobs Module:
Since StaticPublishingTrigger works in conjunction with queued jobs, verify that the queued jobs module is installed and functioning correctly. You can check your job queue through the CMS under “Jobs”.
Testing Manually:
To isolate the issue, you can attempt to manually run the static publishing job. Use the dev/tasks URL or CLI tools provided by Silverstripe to see if the publishing process completes without the trigger.
Debugging:
Enable debugging logs to monitor what’s happening when you try to use the trigger. You can do this by modifying your .env file to set:
makefile
SS_LOG_LEVEL=DEBUG
Then check the logs for any relevant errors or warnings.
If you’re working on a project such as a Dubai ecommerce website, it’s important to ensure the integration of static publishing aligns with performance needs. This can help improve user experience and loading times.
If none of the above resolves the issue, please share:
Thanks for your help and suggestions - much appreciated.
I’m using SS5.3, silverstripe/staticpublishqueue 6.2.2
I’m able to queue and run other jobs through the Queue Jobs Module (or via dev/tasks, CLI etc) and a job appears in the jobs list when I republish a page. The job then runs via cron (or when using CLI sake dev/tasks/ProcessJobQueueTask or dev/tasks) and replaces the republished page in the cache. The problem is that saving changes to an associated DataObject is not triggering a page to republish. The config I’m using, is as per the documentation:
and the following implementation on the associated DataObjhect (again as per the documentation):
use SilverStripe\ORM\DataObject;
class Event extends DataObject {
...
}
use Page;
use SilverStripe\StaticPublishQueue\Contract\StaticPublishingTrigger;
class Trip extends Event implements StaticPublishingTrigger {
public function objectsToUpdate($context) {
return Page::get()->First(); // return 1 or an array of multiple publishable objects you would like to regenerate the static cache for
}
public function objectsToDelete($context) {
return 1; // Return 1 or an array of publishable objects for which you would like to purge the statically cached variant
}
}
anywhere in the documentation, but I tried it anyway with no result.
I also cannot find any reference to SS_LOG_LEVEL=DEBUG but am able to log to an error file and can see that the objectsToUpdate function never gets called.
I’ve given up trying to get this working and instead have used the following on the DataObject I wish to update a page (ie. not using StaticPublishingTrigger at all):
public function onBeforeWrite() {
// republish page to update this event's dates
if ($this->Page()->exists()) {
$this->Page()->write();
$this->Page()->publishRecursive();
}
parent::onBeforeWrite();
}
This seems to work just fine as it republishes the affected page, which is then adds a queued job for cron to run.