Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

File Decorator not working from /framework/cli-script.php dev/tasks/FilesystemSyncTask


Go to End


4 Posts   539 Views

Avatar
blueman

Community Member, 2 Posts

22 December 2014 at 4:03pm

I successfully created a File Decorator with an onAfterWrite() function that works fine if files are uploaded through the cms, but doesn't work from /framework/cli-script.php dev/tasks/FilesystemSyncTask. Is there a way to get the Decorator to be accessible there as well?

I added it to the config through yml:
File:
extensions:
- FileDecorator

and the decorator is:
class FileDecorator extends DataExtension {
...
}

Avatar
camfindlay

Forum Moderator, 267 Posts

23 December 2014 at 8:11am

does that FilesystemSyncTask work if you do it via the browser? http://localhost/dev/tasks/FilesystemSyncTask

Does running it in the CLI return any error messages?

Avatar
blueman

Community Member, 2 Posts

24 December 2014 at 3:28am

Well, after reviewing the code in FileSystem::Sync() and Folder::syncChildren() it seems that the sync is done using raw queries which would explain why my onAfterWrite() extension isn't getting called from the sync. The onAfterWrite() did however work perfectly if the file was uploaded through the Assets Admin interface.

I worked around this by forking the FilesystemSyncTask and creating a custom task so I can do what I need once the sync is complete. Not as elegant as an onAfterWrite() but not much I can do since the sync functionality doesn't appear to be extensible.

Avatar
camfindlay

Forum Moderator, 267 Posts

24 December 2014 at 11:24am

I can probably understand the rationale behind using raw sql as it is probably faster than invoking the whole ORM part of the Framework (just less easy to write). If it's syncing a tonne of files and images from the file system this we be of benefit.