silverstripe-populate
silverstripe-populate copied to clipboard
silverstripe
Locations of populated images are not recognized by the CMS
I've started using the "Default assets". I love the concept, though it seems images that are placed in a directory are not properly picked up by the CMS.
It takes for me to sync assets via the cms for this to happen. See screenshots of the issue:
Image appears in the root of assets - with no title:
Even though it should have appeared in this directory (that's also where it's placed):
Initially I thought I could fix this by adding the following to PopulateFactory.php before returning the object, as to my knowledge that's what needs to be triggered, it's not working though, so I'm a little lost:
//making sure to update file system after adding/editing files and images
if(isset($data['PopulateFileFrom'])) {
$obj->updateFilesystem();
}
This is my yml:
Image:
demo3a:
Filename: assets/immodb/demos/demo3a.jpg
PopulateFileFrom: immodb/images/demos/demo3/3761870901_953b1c54c9_b.jpg
PopulateMergeMatch:
- Filename
Right now I'm fixing this by adding Filesystem::sync(); to requireDefaultRecords on a model that's being built after populate.
Is this still an issue? I haven't tried this module yet. If so, is it fully fixed using your technique (Filesystem::sync())?
I havent worked on that project for while, but I believe it solved my issue then.
Ok no problem, just curious. Either way, thanks for not only posting about the issue but documenting your fix (for the rest of us)!
Looks like it's just not populating the file name? @patricknelson I can take another look at this over this week but if you come across a fix let me know. Running filesystem::sync() is one, but would be interested to work out why it's out of sync in the first place.
I actually posted my comment above when researching tools to assist in provisioning content on the site I'm working on but I end up just writing a bash script. It just synchronized our development environments with a central server to keep our dev's working with the same files & database. So, I haven't taken time to look into this myself since I've never even tried this module!
Ha yes we had a similar situation and the reason this exists. 8 devs on the team, 2 testers, 1 code base. Populate was super useful, git pull and do a dev/build and you'd all be on the same page. Easy to share state around.
5 devs, 1 tester and 0 (to -1) time.
Ok, I decided to test this. Got the same result.
Reading through this code though my hunch is that it's probably not setting the title, which is why the title isn't set. It sounds facetious but I'm not seeing any mechanism here throughout which would do anything to set that title. The Filename, sure. Not the title, hence null.
So, I was looking through Filesystem::sync() to try and figure out why the hell you get inconsistent results here. Like, you create a File instance and the data model should intuit a title if you don't set one. It does not. Also, somehow, you still get Title's when you run this ::sync(), but apparently:
It does this without actually using the object model, as this starts messing with all the data. Rather, it does a direct database insert.
Wat? Ok... why not just work with the DataObject model? Is it really that messy or that big of a deal? If you've got good separation of concerns then doing simple tasks wouldn't be so damned complicated and things just fall into place :) Maybe I'm just being a bitter old man.
Anyway -- https://github.com/dnadesign/silverstripe-populate/blob/master/code/PopulateFactory.php#L113
$obj = parent::createObject($class, $identifier, $data);
That raw $data array is all I see going in there so maybe calling setters there would help a bit. That and calling ->setName(...) with the filename (to initialize a default) would do, for now. Or you can just set $data["Title"] = $data["Filename"].
By the way I get that comment above from Folder's ->constructChild() method here: https://github.com/silverstripe/silverstripe-framework/blob/3.1/filesystem/Folder.php#L218