How to point image variable for the template directory in 'root/aaa/' folder?

[oavs]

Hi,

Some of my mod images aren't showing. Mod is installed in
www.abc.com/AAA/includes/modules/my_mod folder (not in admin)

I have following code
$this->icon = $template->get_template_dir('bbb.jpg', '' ,'','images/icons'). '/bbb.jpg';

and
$this->logo = $template->get_template_dir('ccc.jpg', '','' ,'images/icons'). '/ccc.jpg';

but when I follow the no-image icon it points to
http://www.abc.com/AAA/admin/include.../icons/bbb.jpg

How can I modify the code so that images are correctly found and linked.

Can anyone please assist?

[carlwhat]

it looks like your reference to $this in your mod must have somehow included the admin directory.

how have you initialized $this in your mod? and is your admin directory named admin?

[mc12345678]

If in the admin and trying to reach the store's modules directory where the "my_mod" info is installed in the template override directory in the modules directory, I think the following would work:

$this->variable = $template->get_template_dir('bbb.jpg', DIR_FS_CATALOG . DIR_WS_MODULES, $template_dir, '') . '/bbb.jpg';

[mc12345678]

it looks like your reference to $this in your mod must have somehow included the admin directory.

how have you initialized $this in your mod? and is your admin directory named admin?

Not quite carlwhat. See, the function/code that is trying to display the icon is located in the admin directory. The global $template variable is accessible from the admin, but the problem in the above code lies in the lack of "starting" directory. Therefore, the returned location is provided based on the current location which is the admin directory when the result(s) come back. It's centered around this function in includes/classes/template_func.php which "typically" looks in the includes/templates directory, but also could be used to look in other overrideable directories.

 function get_template_dir($template_code, $current_template, $current_page, $template_dir, $debug=false) {
    //	echo 'template_default/' . $template_dir . '=' . $template_code;
    if ($this->file_exists($current_template . $current_page, $template_code)) {
      return $current_template . $current_page . '/';
    } elseif ($this->file_exists(DIR_WS_TEMPLATES . 'template_default/' . $current_page, preg_replace('/\//', '', $template_code), $debug)) {
      return DIR_WS_TEMPLATES . 'template_default/' . $current_page;
    } elseif ($this->file_exists($current_template . $template_dir, preg_replace('/\//', '', $template_code), $debug)) {
      return $current_template . $template_dir;
    } else {
      return DIR_WS_TEMPLATES . 'template_default/' . $template_dir;
      //        return $current_template . $template_dir;
    }
  }

The only thing about the provided suggestion from above is that the entire path of the store is made visible (on the admin side to which I just found a solution) instead of simply copying the file to somewhere admin side and referencing it from there such that the same image is presented in two locations on the server. But whatever is desired I guess...

[mc12345678]

If in the admin and trying to reach the store's modules directory where the "my_mod" info is installed in the template override directory in the modules directory, I think the following would work:

$this->variable = $template->get_template_dir('bbb.jpg', DIR_FS_CATALOG . DIR_WS_MODULES, $template_dir, '') . '/bbb.jpg';

I'd like to offer a revision because of the concern I expressed above related to "publishing" the file path. Instead of DIR_FS_CATALOG, use DIR_WS_CATALOG or as necessary DIR_WS_HTTPS_CATALOG:

$this->variable = $template->get_template_dir('bbb.jpg', DIR_WS_CATALOG . DIR_WS_MODULES, $template_dir, '') . '/bbb.jpg';

Though I also did just find that DIR_FS_CATALOG_MODULES is defined if you need a hard file path to a file in the modules directory.

[carlwhat]

...Therefore, the returned location is provided based on the current location which is the admin directory when the result(s) come back. It's centered around this function in includes/classes/template_func.php which "typically" looks in the includes/templates directory, but also could be used to look in other overrideable directories.
...

ok, mc i am very confused! (not an unusual occurrence...)

the OP stated that the mod is NOT on the admin side. the function get_template_dir resides on the customer facing side as well.

if both of those statements are true, how did the admin get into the file path? how does the current location become the admin directory when the results come back?

thanks in advance.

[mc12345678]

ok, mc i am very confused! (not an unusual occurrence...)

the OP stated that the mod is NOT on the admin side. the function get_template_dir resides on the customer facing side as well.

if both of those statements are true, how did the admin get into the file path? how does the current location become the admin directory when the results come back?

thanks in advance.

No problem. I too was a little confused, but then thought about this: where are the shipping and payment modules installed? Catalog right? From where does one access/setup those modules? Admin, right? Want to "pretty your mod"? Add pictures... now, though the thing goes back to what is defined and when/where. If the images are to be visible on the Admin side *and* the store front side, then the path for the image(s) needs to be "flexible". So for example DIR_WS_CATALOG_MODULES doesn't exist on the store front, but does on the Admin side. So:

(defined('DIR_WS_CATALOG_MODULES') ? DIR_WS_CATALOG_MODULES : DIR_WS_MODULES)
Would address referencing the "correct" path depending if accessed from the Admin (first option) or catalog (second).

[mc12345678]

I guess I didn't get into the directory path resolution part.

So, the path returned from the function is a relative path (begins without a forward slash /) by having the image to be displayed in the admin as part of "working with" the module (added to database to reference the store/catalog side "control file" or the database populated with a reference to a location), then the image is attempted to be displayed considering the original code using src="includes/templates/template_default/images/icons/bbbb.jpg" for example. Because the image path is presented on the admin side, the base path or place from which to reference that path includes the admin location. Therefore, the image path when "viewed" becomes admin centric.

Even if the OP does have files in the admin which would contradict the original statement in the OP, the reference is built the same way and the result is not catalog/admin centric, but relative to the location to where the image (or more specifically overrideable location) exists.

That help a little?

[carlwhat]

no, none of this makes sense to me....

the only place i see $current_template defined is here:

admin/includes/init_includes/init_image_handler.php

which could possibly explain how the admin part comes up. although i have not been able to reproduce it my testing.

with regards to the function get_template_dir, it includes the php function file_exists and in the php definition, i see no second parameter, and yet get_template_dir passes a second parameter when using the file_exists function, so frankly i have no idea what is going on there as well.

if the OP stored the icons in his template i would just use:

$this->icon = DIR_WS_TEMPLATE . 'images/icons/bbb.jpg';

and move on....

something seemingly so simple gets to be so complex.

[mc12345678]

Did you look in the catalog side of the store?

Have to back track a little, but in the initialization of the admin side, the includes/classes/template_func.php file is loaded... the $this->file_exists command references the function file_exists inside the above class.

Okay, bouncing ball:
admin/index.php loads includes/application_top.php
App_top loads admin/includes/auto_loaders/config.core.php
The core loads admin/includes/init_includes/init_templates.php
That assigns $template_dir based on a database lookup.
Also requires the catalog/classes/template_func.php file.
$template is initialized referencing DIR_WS_TEMPLATE, the constant is set to being DIR_WS_TEMPLATES and the $template_dir.

Now, the image(s) as identified are located in the modules directory... so one somewhat has to question why then use a template function? Well, on the catalog side there is a zen_get_module_directory function, but it doesn't appear that the function is made available on the admin side unless there is some other circuitous route that I've missed. At any rate, the template_directory function can kind of do the same thing if fed the applicable information.

As to "just set it to" DIR_WS_TEMPLATE and then the sub-path off of the template, sure could if the image(s) were stored in the template directory first of all, and second if stored on the admin side's template directory because again admin would appear in the path when referenced from the admin which is the only way that the admin directory could even get involved when/if properly coded. Which is what gets back to the "complexity". Write everything so that the code can be picked up and moved elsewhere and continue functioning. But yes, an obvious solution is to store the images elsewhere. :)