Hazel moving entire folder instead of folder contents

Hey, I've followed the "How to get Hazel to go into subfolders" thread, but I just can't get it working properly.

Here's the basic example provided in that thread:

And here are the rules I've set up:

The rules are basically identical, the only difference being that I am additionally checking the folder name.

Hazel, however, moved the entire folder instead of its contents. I don't understand why this is not working.

It's moving the folder because the conditions match a folder (Kind is folder). Read the sticky article again as it warns about combining logic for different things (folders and the files within) into a single rule. Try separating it into two rules. One that matches folders (and goes into them) and one that matches the files within that you want to move.

Thanks for your reply. I've re-read the thread a number of times and I think I should probably present some more context. It seems to me that it's impossible to apply the suggestions there.

I'm trying to auto-sort a stock photo archive from the weekly unsplash.com newsletter into my media manager (Ember, which monitors an auto-import folder). I want to be able to start the download and have Hazel do the rest for me. So this would be the order:

Manually download .zip file
Hazel detects .zip file
Hazel unzips .zip file
Hazel moves contents of unzipped folder (.JPG-files) to media folder
Ember detects images and auto-imports into library.

The unarchive function always creates a folder with the contents of the zip file. Ember cannot descend into subfolders. I need to move the JPG files themselves, and not the containing folder, into Ember's auto-import folder. I thought Hazel might help me do that, but everything I've tried so far has failed.

I don't know how to split that up into 2 rules, as you have suggested. Here's why:

a) I can't run a folder-based rule on a non-existent folder

The folder is created when the .zip file is unarchived. I've tried by renaming the .zip-file before unarchiving so that the resulting folder always has the same name (so that Hazel can monitor it, in this case unsplash-archive), but Hazel blocks me from doing that:

b) I can't keep an empty folder around because the Unarchiver can't overwrite it.

My second idea was to have an empty folder that Hazel can monitor, but the Unarchiver just adds a new folder with a trailing -1:

So, it seems like my hands are tied, unless I'm missing something important?

The point of the subfolder rule is that it goes into any folders under the monitored folder. If you look at the rule, the only condition is "Kind is folder". So, as long as that thing you want Hazel to go into is a folder, it will work. No need to add those folders to Hazel. Just monitor the folder that contains the zips and the rules will handle it from there.

Sorry, I still don't get it. How do I access .jpg files within a subfolder of a monitored folder? That's all I really need to know. I've been spending hours across several days trying to set this up and I'm just not seeing it. I'd really appreciate if you had a few moments to create a screenshot of the proper setup.

There's a screenshot of one of the rules in the article. Do not modify that unless you know what you are doing. That rule matches folders. To have something process jpgs, then create ANOTHER rule to match those and deal with them.

Alright, I got it working now, thanks. It wasn't obvious to me that the "run rules on subfolders" directive applied to all rules on a folder. I realize you mentioned it by alluding to a ruleset, but it didn't register with me because I was expecting the system to be more granular. I thought "run rules on subfolders" referred to whatever tasks follow below the directive within a single rule. I'm coming from front-end development with Gulp, where you can pipe tasks and have different tasks run in different scopes on the same folder, so I was viewing it through that mindset this entire time. Thanks for your help!

It's admittedly hard to grasp but it provides for the most control while also making it a bit harder for people to do something they didn't intend to whole hierarchies of files.