public function fetchDuration(DurationProviderInterface $durationProvider): WidgetProviderInterface
{
return $this;
}
public function getDataCacheKey(DataProviderInterface $dataProvider): ?string
{
// Returns a fixed key to keep the cache working, but with controlled behavior
return 'gumDataProvider-' . md5('G1RSSFeed');
}
public function getDataModifiedDt(DataProviderInterface $dataProvider): ?Carbon
{
// Returns the current date/time to force the cache to always be refreshed
return Carbon::now();
}
So with each update from my Android client to the CMS, that is, every 5 minutes I should update this module, right? More repair that continues to use the same data as if the cache was not updated. Even getDataModifiedDt returning as it does now. Is there anything else I’m doing wrong?
When the module has a data provider, should this update happen automatically? Do I need to open the Layout and save for this to happen?
Is XTR and the Widget Sync task running in your CMS installation? Data is kept up to date in the background via XTR, if it isn’t running then you won’t see any updates.
My installation was done using Docker, so from what I understand I wouldn’t need to create a routine on my server to run xtr as one would already be configured?
I believe it is in fact something in my data provider that is not updating, because when using the native RSS ticjer module with an external RSS the updates worked normally, seeing the RSS module code is with
public function getDataModifiedDt(DataProviderInterface $dataProvider): ?Carbon
{
return null;
}
tentei fazer isso no meu modulo cutomizado, mais infelizmente sem atualização ainda.
@dan Unfortunately, so far I haven’t achieved anything. Follow my current full provider. It’s just the problem of updating that doesn’t happen, only if you open the Layout and save manually, otherwise it always displays the same content in the player.
Not yet, the documentation isn’t very helpful. I’d appreciate some guidance.
It only updates if you open and close the Layout, but not automatically with Player calls. @dan The documentation for developers could be improved. Or provide clearer guidance on how the CMS updates the contents of these modules with dates?
I’ll assume you’re testing this in a local environment. If so, CMS tasks like the Widget Sync task don’t run automatically. To trigger it, while your Layout is scheduled to the Player, run:
Change web to match the name of the container you are using.
The reason it is not working on your local setup is that the CMS is responsible for refreshing the data and passing it on to the Player, and this is done by the Widget Sync task. On a production system this task runs automatically, but in a local setup it usually does not run unless you start it yourself. That is why you do not see updates until you intervene. Running the command above simply forces the Widget Sync task to run so the Player can receive the updated data.
I created two more modules based on Ticker RSS, and I’m facing the same problem. Custom “article”/rss/ticker modules are not being updated by the widget sync task (which, yes, is running).
Facing the same problem as Henrique with my custom RSS module.
It only updates when I manually save the layout.
FYI: the provider is basically a copy of the original RSS provider, the difference is that it uses pre-set links instead of the user inserting them in the layout editor.
In short, it seems that XTR doesn’t reach the custom modules.
Can you help us clarify how the widgetsync task currently updates RSS feeds?
How can I add my custom module to be updated by this task?
If that’s not possible, how can I create a task to automatically fetch these custom feeds?
The documentation on creating tasks is very basic at the moment. Could you please provide some feedback?
Thank you!
========
Edit:
Checking logs using:
set LOG_TO_CONSOLE=true && “php.exe” -f MYCMSPATH\bin\run.php 9
And found that error:
[2026-02-02 12:57:25] CONSOLE.CRITICAL: Setting value in cache caused exception. {“exception”:"[object] (Stash\Exception\WindowsPathMaxLengthException(code: 0): Cache path exceeds Windows PHP MAX_LENGTH of 260 characters.
Trying to enable Windows Long path, this may be the cause in my case.
Don’t know it’s the same with docker as @Henrique_Lucas told us