Assets file not returning path with subfolder created within Assets

[bryantAXS]

Hey Rob,

So I have a directory "uploads" configured as a normal EE file upload directory, and I have Assets configured to use that directory. Within Assets itself the client has created several subdirectories, which each store various images, and which Assets creates real directories in the file system for. My issue is that these directories Assets creates are not reflected in the URL or Path variables returned by the Assets Collection.

Does that make sense? Thoughts?

Thanks!

ps: I'm using Deep 1.1

[rsanchez]

Can you look up a row in exp_assets_files table for a file which has subdirectories and send me a SQL insert for it? In Sequel Pro you can right click a row and there's an option to copy as SQL insert query.

[bryantAXS]

INSERT INTO `exp_assets_files` (`file_id`, `folder_id`, `source_type`, `source_id`, `filedir_id`, `file_name`, `title`, `date`, `alt_text`, `caption`, `author`, `desc`, `location`, `keywords`, `date_modified`, `kind`, `width`, `height`, `size`, `search_keywords`)
VALUES
    (519, 8, 'ee', NULL, 1, 'Pep.jpg', NULL, 1387564434, NULL, NULL, NULL, NULL, NULL, NULL, 1387564434, 'image', 200, 200, 16658, 'Pep.jpg');

[rsanchez]

One more, can you send me the insert from exp_assets_folders where folder_id is 8?

[bryantAXS]

wow you're fast :)

INSERT INTO `exp_assets_folders` (`folder_id`, `source_type`, `folder_name`, `full_path`, `parent_id`, `source_id`, `filedir_id`)
VALUES
    (8, 'ee', 'Product_Cart_Images', 'Product_Cart_Images/', 1, NULL, 1);

[rsanchez]

OK I believe I have this solved. Can you composer update rsanchez/deep and let me know if that fixes it for you?

[bryantAXS]

Hmm, still isn't returning the full path. I see in the Asset model where you updated this line

return $this->uploadPref->url.$this->full_path.$this->file_name;

For all my files, when I dump out $this->full_path it's giving me null.

[rsanchez]

What version of Illuminate/Database do you have installed?

[bryantAXS]

I believe 4.1

The composer for my addon is on the left, and within Deep is on the right.

http://cl.ly/image/001m05152330/Screen%20Shot%202014-08-14%20at%209.17.40%20AM.png

[rsanchez]

I should’ve posted this before: you should run composer show -i to display a list of what’s installed and the exact version installed. If you have illuminate/database 4.1.x installed, that’s the issue. I need to bump the version requirement in Deep’s composer.json. If you have illuminate/database 4.2.x installed, then it must be something else.

[bryantAXS]

Ah I see, thanks. It actually says I've got illuminate/database v4.2.8

[bryantAXS]

This may be obvious but it doesn't seem like that default join of the assets_folders and assets_files join is actually propagating. None of the assets_folders fields are available on the model.

[rsanchez]

What version does show -i say for rsanchez/deep? Would it be possible for you to send me a DB dump I could test on? info at robsanchez dot com

[bryantAXS]

Yep no problem. Sending now.

rsanchez/deep 1.1.x-dev 6e34a3e

On Thu, Aug 14, 2014 at 9:47 AM, Rob Sanchez notifications@github.com wrote:

What version does show -i say for rsanchez/deep? Would it be possible for you to send me a DB dump I could test on? info at robsanchez dot com

— Reply to this email directly or view it on GitHub https://github.com/rsanchez/Deep/issues/17#issuecomment-52192806.

Bryant Hughes bryant@thegoodlab.com www.thegoodlab.com @thegoodlab http://www.twitter.com/thegoodlab

[bryantAXS]

I was plugging around a little more and it doesn't look like the bootJoinableTrait method is being called when the model is being instantiated, and thus not joining the default tables. I wasn't sure where that was supposed to be called though... I thought maybe in the Assets hydrator, but calling it from within there was having errors on its own.

[rsanchez]

That’s actually Laravel-native stuff: http://laravel.com/docs/eloquent#global-scopes

So Eloquent should be calling this automatically. This is where it’s all supposed to happen: https://github.com/laravel/framework/blob/4.2/src/Illuminate/Database/Eloquent/Model.php#L300-L360

Maybe hack around in your local copy of Illuminate/Database/Eloquent/Model.php a bit?

[rsanchez]

Can you post your query? Entries::channel('foo')->get() or whatever it may be.

[bryantAXS]

return Entries::channel('favorites')->get();

On Fri, Aug 15, 2014 at 5:23 PM, Rob Sanchez notifications@github.com wrote:

Can you post your query? Entries::channel('foo')->get() or whatever it may be.

— Reply to this email directly or view it on GitHub https://github.com/rsanchez/Deep/issues/17#issuecomment-52367037.

Bryant Hughes bryant@thegoodlab.com www.thegoodlab.com @thegoodlab http://www.twitter.com/thegoodlab

[rsanchez]

Can you try composer update rsanchez/deep again (it should install 1060d85) and let me know if that makes a difference? Running your db with that latest version is working on my end.

[rsanchez]

FWIW, this is the script I'm running on the command line (php test.php) with your db: https://gist.github.com/rsanchez/0930f299c664179cd2ac

[bryantAXS]

Hey Rob, still no luck.

Those tests that you setup are all hitting images that are inside the "root" directory with folder_id = 1, so yes those paths are technically correctly, but the issue is that images not in that directory (and levels deeper) are not being given their full path correctly.

When I just double checked output of some of these images, the fullpath property is still null for them.

[bryantAXS]

Actually, wait, it might be working. Now I'm seeing mixed results.

[rsanchez]

Can you send me a query that has an Asset with the null full_path issue? Send me an updated DB if you need to.

[bryantAXS]

This is pretty strange, there must be a discrepancy with the Capsule implmemetnation between my code and your tests.

I updated your test to use this code and am running it locally and having success

$entries = Entries::channel('favorites')->get();

foreach ($entries as $entry){

  foreach($entry->favorite_products as $product)
  {

    $full_product = Entries::entryId($product->entry_id)->first();

    foreach($full_product->product_image as $image) var_dump($image->toArray()["url"]);

  }

}

Results:

string 'http://dimos.local/content/uploads/Product_Cart_Images/Pep.jpg' (length=62)
string 'http://dimos.local/content/uploads/Product_Cart_Images/Mexicoke.jpg' (length=67)
string 'http://dimos.local/content/uploads/Product_Cart_Images/Martinellis.jpg' (length=70)
string 'http://dimos.local/content/uploads/Product_Cart_Images/Philly_Circle.jpg' (length=72)
string 'http://dimos.local/content/uploads/Product_Cart_Images/TPesto.jpg' (length=65)
string 'http://dimos.local/content/uploads/Product_Cart_Images/VeganBrownie.jpg' (length=71)

When I'm running that exact same code within my module via an action url, it doesn't return the full path.

Results:

string 'http://dimos.local/content/uploads/Pep.jpg' (length=42)
string 'http://dimos.local/content/uploads/Mexicoke.jpg' (length=47)
string 'http://dimos.local/content/uploads/Martinellis.jpg' (length=50)
string 'http://dimos.local/content/uploads/Philly_Circle.jpg' (length=52)
string 'http://dimos.local/content/uploads/TPesto.jpg' (length=45)
string 'http://dimos.local/content/uploads/VeganBrownie.jpg' (length=51)

[rsanchez]

In both of those tests, are you using the exact same composer vendor/ folder? I'm wondering if maybe your composer installation is messed up somehow. Shot in the dark.

[bryantAXS]

Hmm, so I'm importing the autoload based on my addon, but I'm also adding the autoload from the Store addon's vendor directory so I have access to some of it's internals. I bet that's the issue.

Is there anyway to cherry pick what is being imported from an autoload file?

On Mon, Aug 18, 2014 at 9:39 AM, Rob Sanchez notifications@github.com wrote:

In both of those tests, are you using the exact same composer vendor/ folder? I'm wondering if maybe your composer installation is messed up somehow. Shot in the dark.

— Reply to this email directly or view it on GitHub https://github.com/rsanchez/Deep/issues/17#issuecomment-52501328.

Bryant Hughes bryant@thegoodlab.com www.thegoodlab.com @thegoodlab http://www.twitter.com/thegoodlab

[bryantAXS]

Actually, I'm not sure that's the issue, when I comment out my other Store require statement, I'm still seeing the issue.

[rsanchez]

Don't rule that out yet, maybe Store is requiring itself in a hook somewhere. Maybe sessions_start or core_template_route, something early. It sounds like your code is getting run through illuminate/database 4.1 (from Store) instead of 4.2 as Deep requires.

It might be tricky to get this working right. I guess you’d have to copy the "autoload"(w/ updated paths to store's src files, relative to your root composer.json) and "require" from Store’s composer.json to your root composer.json, and then composer install. Then make sure that Store never loads its autoloader (by commenting it out or however). Might wanna ping the guys at expressodev to see if they have any advice for running Store from your own vendor folder.

[bryantAXS]

Hmm Ok I'll put out a few questions to the Store guys and see if I can get it figured out. In the meantime, I just created a small service class to handle the issue, but it seem like you've resolved it in the active codebase.

thanks again for all the help!