Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Locations of populated images are not recognized by the CMS #4

Open
anselmdk opened this issue Mar 11, 2014 · 9 comments
Open

Locations of populated images are not recognized by the CMS #4

anselmdk opened this issue Mar 11, 2014 · 9 comments

Comments

@anselmdk
Copy link
Contributor

anselmdk commented Mar 11, 2014

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:
screenshot 2014-03-11 22 08 10

Even though it should have appeared in this directory (that's also where it's placed):
screenshot 2014-03-11 22 08 23

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

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/8466846-locations-of-populated-images-are-not-recognized-by-the-cms?utm_campaign=plugin&utm_content=tracker%2F668165&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F668165&utm_medium=issues&utm_source=github).
@anselmdk
Copy link
Contributor Author

Right now I'm fixing this by adding Filesystem::sync(); to requireDefaultRecords on a model that's being built after populate.

@patricknelson
Copy link

Is this still an issue? I haven't tried this module yet. If so, is it fully fixed using your technique (Filesystem::sync())?

@anselmdk
Copy link
Contributor Author

I havent worked on that project for while, but I believe it solved my issue then.

@patricknelson
Copy link

Ok no problem, just curious. Either way, thanks for not only posting about the issue but documenting your fix (for the rest of us)!

@wilr
Copy link
Member

wilr commented Jun 9, 2015

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.

@patricknelson
Copy link

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!

@wilr
Copy link
Member

wilr commented Jun 9, 2015

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.

@patricknelson
Copy link

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"].

@patricknelson
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants