When porting a theme from 4.7 and moving to a different server, I had to repair paths to images in the theme directory that were hard-coded into the tpl files.

With this patch, instead of:

<?php base_path() . path_to_theme() ?>/box_bottom.png

I can include, more succinctly:

<?php base_path_to_theme() ?>/box_bottom.png

These paths won't break when the theme is moved around in the sites directory or renamed.

Files: 
CommentFileSizeAuthor
#7 theme_path_helper-110632-7.patch808 bytesdropcube
Failed: Failed to apply patch.
[ View ]
#6 theme.inc_.patch708 bytespnm
theme.inc_16.patch650 bytespnm

Comments

catch’s picture

Version:6.x-dev» 7.x-dev
Status:Needs review» Needs work

No longer applies.

dvessel’s picture

Status:Needs work» Closed (won't fix)

You can also do this:

<?php
 
print url("$directory/box_bottom.png");
?>

This applies to the current version and goes way back to 4.7 I think. So, I don't see a real need for this patch.

pnm’s picture

Status:Needs work» Closed (won't fix)

dvessel: your suggestion doesn't work for me in 5.0.

base_path_to_theme() returns
/drupal/subsite/sites/subsite/themes/subsite/box_bottom.png

url("$directory/box_bottom.png") returns
/drupal/subsite/?q=en/sites/subsite/themes/subsite/box_bottom.png

pnm’s picture

pnm’s picture

Status:Closed (won't fix)» Needs work
pnm’s picture

Status:Closed (won't fix)» Needs review
StatusFileSize
new708 bytes

I updated the above patch against HEAD.

dropcube’s picture

Assigned:Unassigned» dropcube
StatusFileSize
new808 bytes
Failed: Failed to apply patch.
[ View ]

I suggest the following helper function:

<?php
 

/**
 * Returns a relative path from base to a file in the currently
 * selected theme. Useful for providing relative paths to files
 * in the theme directory.
 *
 * @param $path
 *   The path relative to the theme directory. 
 *  
*/
function base_path_to_theme($path) {
  return
base_path() . path_to_theme() . "/$path" ;
}
?>

It will avoid themers to repetitively use base_path() . path_to_theme() . $file , and instead use this more succinctly function.

For example:

<?php
 base_path
() . path_to_theme() . '/fix-ie.css'
?>
<?php
 base_path
() . path_to_theme() . '/images/bg.png'
?>

Can be converted respectively to:

<?php
 base_path_to_theme
('fix-ie.css')
?>
<?php
 base_path_to_theme
('images/bg.png')
?>

Find attached the patch.

drawk’s picture

Patch still applies, with offset

RobLoach’s picture

I think helper functions like this are better lived in the template.php file of your theme, and not part of core where they might never be used. Just my thoughts though...

dvessel’s picture

I made a bad call on #2 but I still don't think this needs a function.

Instead, setup the variables within "template_preprocess" so it can be used in any preprocessor or template file. The function calls are cheap and it would be a two line change. The $base_path variable in "template_preprocess_page" should be moved to "template_preprocess" and the $directory variable should be changed to $theme_path. $directory is seldom used since it has little meaning in this context. Not many know that they can use it.

It would end up like this:

<?php
print "$base_path$theme_path/fix-ie.css";

// vs. this:

print base_path_to_theme('fix-ie.css');
?>

If we can prevent function calls inside templates, lets not provide another function as a shortcut. Make the variables available instead. If you need to call these paths from theme functions, the two functions "base_path" & "path_to_theme" should be fine.

webchick’s picture

To me

<?php
print "$base_path$theme_path/fix-ie.css";
?>

is still messy (and error prone; why not $base_path/$theme_path?). Could we do:

<?php
print "$base_path_to_theme/fix-ie.css";
?>

or similar? one variable to remember rather than two? I leave it to themers' discretion what that variable is best called.

RobLoach’s picture

Morbus was throwing around the idea of a base_url() function...

dvessel’s picture

That would work too Webchick but having them separated is useful too so we might need 3 variables. If we stuck to one standard in how paths are used, a single path would be fine. For example, theme_image can't take in the base path while drupal_add_css does. Maybe another thing to tackle.

RobLoach’s picture

Did I hear drupal_add_css? #266358: Use $options in drupal_add_css()

pnm’s picture

Since every themer will face this problem, I think it's better to have a helper function, and "one best way" of doing it.

Having a standard way would reduce the chance of themers creating code that works on their current configuration -- a site in / -- but breaks if the site is moved to a subdirectory. This is the situation that led me to post this request in the first place.

In addition, people learning Drupal and reading theme code for the first time will better understand what to do.

Anonymous’s picture

Status:Needs review» Needs work

The last submitted patch failed testing.

sun’s picture

Most modules in contrib that implement path lookup helper functions use an optional boolean argument to return the same path prefixed with base_path().

So:

<?php
echo path_to_theme();
// returns: "sites/all/themes/mytheme"

echo path_to_theme(TRUE);
// returns: base_path() . "sites/all/themes/mytheme"
// e.g.: "/sites/all/themes/mytheme"
?>
RobLoach’s picture

Note that there's also talk of vamping base_path() with hook_file() goodness to make it easy to push files to CDNs or host files externally.

Also, I think instead of using a PHP function for this, it might be nicer to give designers and theme developers a variable. $base_path, $path_to_theme, etc?

sun’s picture

For template files, we have $base_path and $directory already. IMHO, that is sufficient and allows for any flexible styling.

However, that "base_path() . path_to_theme()" weirdness not only used in theme.inc, template.php, but also in various modules and theme functions.

dropcube’s picture

Assigned:dropcube» Unassigned
a.luiz.n’s picture

how can I call base_path() inside my template.php file???