I’ve created a new interface with a default theme and tweaked some CSS, images, etc. So far that’s working fine. However, when I go into my custom interface and create a non-default theme, none of the changes I make there are reflected in my shop.
Here’s my setup:
app/design/frontend/butterwing_madras/default and skin/frontend/butterwing_madras/default - contain all the files and directories.
app/design/frontend/butterwing_madras/xmas and skin/frontend/butterwing_madras/xmas - contain only the image files I’ve changed so far, under skin/frontend/butterwing_madras/xmas/images.
The custom interface default theme is working fine (butterwing_madras/default); I see my changes there reflected in the store. But I don’t see the changes I make in butterwing_madras/xmas reflected in the store. It’s as if Magento is ignoring the theme and only looking at the default theme.
In my admin, System->Configuration->Design:
Current package name: butterwing_madras
Default: xmas
(the other theme fields are blank, though I’ve also tried putting xmas into the “skin” field to no avail.) I don’t know what I"m doing wrong. :(
I’ve confirmed that Magento is loading the modified image (in this case main_container_bg.gif) from the default theme in my custom interface, and not the xmas theme, even though this is what I set as the theme in the Admin. (I confirmed this by replacing the image in default/images with the modified image, and it showed up just fine.)
I’ve found where the package/theme values get stored in the database, in table core_config_data. Here’s what I have:
The value/old_value for design/theme/layout, /skin, template, etc are empty as I’ve not set these.
Anything fishy here? It looks to me like #183, design/package/theme, should be set to ‘xmas’, but there’s nowhere in the admin to set this. I can only set ‘translations’, ‘templates’, ‘skin’, ‘layout’ and ‘default’. But even if I alter this directly in the database, it doesn’t help.
I tried changing the package & theme values at the website level, and then at the store level. The changes are accurately reflected in the database, but the Admin doesn’t show the right values once it’s saved the configuration (it shows the default values as they are when you first enter the Admin, namely everything inherited and ‘default’ in the package name field). Moreover, the changes aren’t reflected in the storefront. For example, if I set the default_config to use my custom interface and the ‘xmas’ theme, but set the store to use ‘default’ interface and ‘default’ theme, I still see my custom interface.
It seems like somewhere Magento is reading old data, or not reading current data from the database at all. I cleaned and disable all the caches, but still no change. So it seems like there’s an error somewhere in reading the current settings from the database; they’re still as I set them to be, but the Admin isn’t reading them out. Perhaps the frontend isn’t reading them out (or at least not consistently), either, which is why I’m getting such strange design problems? Unless I’m the only person with this problem (which is possible ).
The relative image paths in the CSS files (e.g., background: url(../images/main_container_bg.gif)) mean that the background images for the store are taken from the images/ directory in the same theme where the CSS is found. Thus if your non-default theme doesn’t have its own CSS files, these will fall back and load from the default theme--so the images you want to use for your background will also come from the default theme.
Moreover, Magento will assign “styles.css” (which itself loads the other CSS files in the same directory) to the page, so if styles.css isn’t in your new theme, Magento will assign the version in the next theme down in the hierarchy where it finds it--and thus all your CSS files will come from that theme, period.
Solution is to replicate all CSS files if your new theme uses different background images than the default theme.
Note that this also means you must replicate every background image referred to in the replicated CSS files, because now they will all be loaded from the new theme’s image/ directory. And this CSS image loading falls outside of the Magento fallback file-loading scheme (it’s part of the web server and occurs after all Magento processing on the file, when the HTML and CSS are parsed before the page is served to the client). There are 75 image references in boxes.css alone, plus a few in reset.css and menu.css, so in practice this means duplicating two-thirds of your image directory for every theme you create (if your store design still uses all those images).
(Note you don’t need to replicate images referred to in the template files, only those called in the CSS. Images referred to in the template files do fall under the Magento fallback scheme. This is why just duplicating the logo in the new theme in the Design Guide screencast works; logo.gif is not used as a CSS background image, but is directly referred to in the header.phtml file.)
This doesn’t address the issue of why the Admin isn’t properly displaying the database settings for package, template, etc at the website and store levels, but that’s not the source of my initial issue here, so this thread is closed with a happy ending .
When you copy the CSS files to your new theme and begin customizing them, the background images are still referenced as url(../images/imagename.png ). Unless your new CSS files make no reference to the background images from the default theme, then your theme will not appear correctly.
I would not recommend copying all of the images from the skin/default/default/images folder to the skin/default/mytheme/images/ folder for several reasons. For starters, you will be copying images that you do not need. This means that you will be using more space, and you may be keeping around images that will no longer exist after an upgrade.
Instead, I would recommend finding only those images referenced by the CSS files, and creating symlinks to them from the new directory. For example, you can create a symlink from skin/frontend/default/default/images/product_collateral_bg.gif to skin/frontend/default/mytemplate/images/ .
The code for creating a symlink from a file in the ../../default/images/ directory, to my current theme is as follows:
ln -s ../../default/images/side_col_bg.gif ./
The above code assumes that you are in your skin/frontend/default/mytheme/images/ directory.
If you have shell access, I have a one-liner bash shell to do this for you:
First, cd to the directory of your template images. In my case.
cd htdocs/skin/frontend/default/mytemplate/images/
Then run this one liner:
for i in $( grep url ../css/*.css | perl -pe 's/.*url\(.*\.\.\/images\/(.*\..*)\).*/$1/g; s/[^A-Za-z0-9_.\n-]//g' | sort | uniq ); do if [ ! -e $i ]; then ln -s ../../default/images/$i ./; fi; done
Please note, I have only tested this with images that only contain alphanumerics, dashes, underscores, and periods in the file name. I do not use spaces or odd characters in image file names, and neither should you. Additionally, the code above should all be on one line.
You can do something similar for the adminhtml sections. However, you have to remove the “css/” and “\.\.\/” portions, because for some reason, Magento has not placed the CSS files in a “css” directory in the adminhtml theme.
It would look like this:
for i in $( grep url ../*.css | perl -pe 's/.*url\(.*images\/(.*\..*)\).*/$1/g; s/[^A-Za-z0-9_.\n-]//g' | sort | uniq ); do if [ ! -e $i ]; then echo ln -s ../../default/images/$i ./; fi; done
Of course, you or your web host must have FollowSymLinks turned on in your Apache config.
So, just to make sure I am understanding this correctly:
Not all image files follow the hierarchy structure… that is to say, without uploading all of the css files and image files into the new non-default directory, some images may not display correctly? Is this correct?
I did run into this issue when updating some of the background images.
That is not entirely correct. The hierarchy works for all images except those are loaded via css. Reread post #3 by Grayson on Jan 10, 2008. More precisely, see the two lines she had placed in bold red text.
When you update the background image, are you doing so in a new css file that you referenced in
app/design/frontend/default/YOURTHEME/layout/page.xml
, or did you override one of the built in style sheets by creating a new file named
skin/frontend/default/YOURTHEME/css/boxes.css ?
Each answer carries a different approach to solving the problem.
Case 1)
You created a new css file in
skin/frontend/default/YOURTHEME/css/
and loaded it via
app/design/frontend/default/YOURTHEME/layout/page.xml
. For this example, we’ll name the file custom.css. In this file, you may choose to override only specific attributes of the default classes, IDs, or other selectors.
For example, maybe you want to change the background image of the Mini Search. The code in the default css file boxes.css is as follows:
Now, you need to make sure there is a background image named your_custom_bg_img.png in your skin/frontend/default/YOURTHEME/images folder. All of the other default background images will appear just fine, right where they are.
Case 2)
In this example, you have decided that you will be overriding the entire default boxes.css file by created a new boxes.css file in the
skin/frontend/default/YOURTHEME/css/
directory. Since all of the new CSS background image declarations are referencing images by their relative path, as follows:
url(../images/imagename.gif)
, you will need to make sure that ANY images referenced via this new style sheet are copied or symlinked into the ../images/ directory, which would be skin/frontend/default/YOURTHEME/images .
Summary
If an image is referenced with a relative path of ../images/ in style sheet, in a custom theme, and the image is not found in that theme’s image directory, then it will not failover to an image with the same name in the default theme’s image directory.
.
Unless you are making drastic changes to the layout, then you may want to create only new custom css files in your theme that override specific elements. This avoids the necessity of duplicating the default theme’s background images into your new theme’s image folder.
If you do decide to override the boxes.css style sheet by duplicating it in your theme’s css folder, then you must either copy or symlink only those images loaded via the style sheet. You do not need to duplicate all of the images in the default theme’s image folder. That would be an waste of time, space, etc…
The code in my previous post finds all of the images referenced in boxes.css and then make the symlinks. If you want do this manually, then here you go: ( See next post )
These are all images referenced in the stylesheets in this version. The code below will add symlinks to the images from your theme’s skin -> image directory. This is needed if you chose to copy boxes.css into your theme’s skin -> css directory.
When you copy the CSS files to your new theme and begin customizing them, the background images are still referenced as url(../images/imagename.png ). Unless your new CSS files make no reference to the background images from the default theme, then your theme will not appear correctly.
I would not recommend copying all of the images from the skin/default/default/images folder to the skin/default/mytheme/images/ folder for several reasons. For starters, you will be copying images that you do not need. This means that you will be using more space, and you may be keeping around images that will no longer exist after an upgrade.
Instead, I would recommend finding only those images referenced by the CSS files, and creating symlinks to them from the new directory. For example, you can create a symlink from skin/frontend/default/default/images/product_collateral_bg.gif to skin/frontend/default/mytemplate/images/ .
The code for creating a symlink from a file in the ../../default/images/ directory, to my current theme is as follows:
ln -s ../../default/images/side_col_bg.gif ./
The above code assumes that you are in your skin/frontend/default/mytheme/images/ directory.
If you have shell access, I have a one-liner bash shell to do this for you:
First, cd to the directory of your template images. In my case.
cd htdocs/skin/frontend/default/mytemplate/images/
Then run this one liner:
for i in $( grep url ../css/*.css | perl -pe 's/.*url\(.*\.\.\/images\/(.*\..*)\).*/$1/g; s/[^A-Za-z0-9_.\n-]//g' | sort | uniq ); do if [ ! -e $i ]; then ln -s ../../default/images/$i ./; fi; done
Please note, I have only tested this with images that only contain alphanumerics, dashes, underscores, and periods in the file name. I do not use spaces or odd characters in image file names, and neither should you. Additionally, the code above should all be on one line.
You can do something similar for the adminhtml sections. However, you have to remove the “css/” and “\.\.\/” portions, because for some reason, Magento has not placed the CSS files in a “css” directory in the adminhtml theme.
It would look like this:
for i in $( grep url ../*.css | perl -pe 's/.*url\(.*images\/(.*\..*)\).*/$1/g; s/[^A-Za-z0-9_.\n-]//g' | sort | uniq ); do if [ ! -e $i ]; then echo ln -s ../../default/images/$i ./; fi; done
Of course, you or your web host must have FollowSymLinks turned on in your Apache config.