There's are a couple little bugs related to the new image directory options in 3.7.12 for users who freshly install atahualpa, or reset all settings to defaults. The site logo and fav-icon get incorrect paths if 'ata_images_dir' hasn't been written to the database yet. Easy fixes:

bfa_header_config.php

Change lines 154-155 from this:

$img_folder = 'ata-images';  
$imgdir  = content_url() . '/ata-images/';

to this:

$imgdir  = get_template_directory_uri() . '/images/';

header.php

Change lines 48 from this:

$imgdir  = content_url() . '/ata-images/';

to this:

$imgdir  = get_template_directory_uri() . '/images/favicon/';

That will break the new functionality. All you need do is go to ato->New Image Locations and press the 'Save Changes' button.

Originally Posted by juggledad

That will break the new functionality. All you need do is go to ato->New Image Locations and press the 'Save Changes' button.

I think you're speaking before testing. I see no breaking of functionality.

The idea of the new functionality is to allow you to have the images outside of the template directory.

Originally Posted by lmilesw

The idea of the new functionality is to allow you to have the images outside of the template directory.

Yep... and I'm not breaking this ability.

I updated the first post to reflect that the same problem affects favicons. Before you guys dismiss this suggestion -- as seems to be the case considering earlier responses -- can you actually pull up the code and take a look? Consider the if statements around the code I'm suggesting should be changed:

if( !isset($bfa_ata['ata_images_dir']) OR ($bfa_ata['ata_images_dir'] == '') )

In 3.7.12, the code that runs if the above is satisfied is $imgdir = content_url() . '/ata-images/';. There are two problems here:

1. /ata-images/ is hard-coded (must be left-over from an earlier version of this functionality)
2. content_url() should NOT be the path called when $bfa_ata['ata_images_dir'] is unset/empty

The else statement below this correctly captures user-specified directories.

The problem is that the new option adds an entry into an array but does not initialize it. With your changes if someone selects wp-content as the root and the folder they name does NOT exist (say they misspell it), it will default to the Atahualpa images folder and they won't see their images.

I'll be looking into a fix for the array when I get a chance.

Originally Posted by juggledad

With your changes if someone selects wp-content as the root and the folder they name does NOT exist (say they misspell it), it will default to the Atahualpa images folder and they won't see their images.

In the example you mention, the image paths will not revert to the default atahualpa images folder. This only occurs if ata_images_dir is undefined or empty. Their incorrect folder name will result (as it should) in broken links to images.

Perhaps there is one misconception I have though: I assumed defining your own image folder required it be located under wp-content/. Is it actually the case that users can specify an alternate images folder under atahualpa (not a good idea)?

Your assumption is correct, the alternative location is within wp-content. The idea is that when you do an automatic upgrade, WordPress wipes out the contents of the theme folder and puts the new version in. By moving the images out of the theme folder, they will remain over upgrades.