I hope someone can help.
I have some html, and css knowledge that has served me well to date - but am finding Magento tough.
I want to add physical address information and a location map image for my (physical retail) store to the Contact Us page. Currently (default) the page only has a title and the Email Contact Form in the main content area.
I have been experimenting with creating a Static Block (identified as “address_block"), then having this Block called/inserted into the Contact Us page above the Email Form.
I must confess however, I do not understand how to achieve this and I have not been able to get it to display at all. Can someone please provide a step-by-step on how to achieve this, including code snippets and where (and in what files) to put them.
CMS static block title: Address
Identifier: address_block
Content: div’s positioning postal address, actual address, opening hours, and a location map GIF which hyperlinks to Google Maps.
To be called by/positioned in: Contact Us page (below Contact Us title and above Email Contact Form)…
You’d think this would be so easy with CMS managed pages???
ok, you created static block with title Adress and identifier address_block and it should be shown within content area of contact us.
So you have to customize contacts.xml located in /app/design/default/default/layout/contacts.xml or if you have a own layout
/app/design/yours/yours/layout/contacts.xml.
Open contacts.xml and add following code to <reference name="content"> node
Thanks Stefan,
That got it working!
It’s people like you who make OS communities work, and OS solutions workable for their users (particularly those like me who have limited programming knowledge). I really appreciate it.
Tiffany,
I had initially simply added HTML to the form.phtml page as you suggested - it certainly seemed like the solution to me… however it occurred to me that directly editing the form.phtml page would not be upgrade-compatible. Am I right in thinking so?
I want to ensure that the edits I make are not lost in the ether when Magento recieves a new version. Part of why, like Stefan mentions, I SHOULD be creating my own theme/layout updates. Right now I applied those edits to contacts.xml in /default/default/. When Stefan suggested my own theme/layout, I created a /mine/mine/ directory path and placed a copy of contacts.xml in there, then edited that as suggested, and used the Admin backend to set the design to /mine/mine/ - however when I reloaded the Contact Us page I got a blank page??? Back to the (not-so-easy-to-follow Designer’s Guide for me I think).
Thanks Stefan,
Tiffany,
I had initially simply added HTML to the form.phtml page as you suggested - it certainly seemed like the solution to me… however it occurred to me that directly editing the form.phtml page would not be upgrade-compatible. Am I right in thinking so?.
Actually I think it’s the other way around, but both approach require manual update anyway!
With Stefen’s method, you need to edit the ‘contact.xml’. When you do upgrade, the newest Magento will not recognized whatever extra stuff you added to the ‘contact.xml’ or other files in the ‘layout’ folder.
As for Tiff’s method. it’s the same. Whatever block(s) you added, won’t be recognized by newest version Magento anyway.
From a web design’s point of view, I much prefer Tiff’s method for the reason that I am in full control of the layout/theme, and it’s easier because you only need to add the html code directly to ‘.phtml’ file, that is, if you don’t move the structural blocks around that requires further modification on ‘.xml’ files in the layout folder. With Stefen’s method, in additional to adding a block type in the ‘.xml’ file, you also need to create a new ‘.phtml’ file.
IMHO, I think people who kept saying to keep the update compatibility have got the concept all wrong - the only way you can have this is you store looks exactly like the demo site, except the Skins part that you change the colors, widths images, font size etc.
To me, what is important is not to add/edit anything in the ‘code’, so that I can have a better control with each update.
You can create your own theme and put the contacts/form.phtml with your custom content there.
Change in admin > configuration > design > default theme = “mycustomtheme”
All the files you have in your theme will be used, and will fall back to /default theme for missing templates.
This way you will not loose your customizations on upgrades.
To include in .phtml file a CMS block without changing xml layouts:
Great tips! Moshe. Thank you for pointing that out.
I have a question: In the earlier testing (v0.7x), I created my own theme, when the system couldn’t find my custom content in my theme, it loaded the default theme. Problem is, if I am using my own design, I don’t want the system loads the default theme when it finds something missing in my theme.
Will your approach shows the default theme when the system can’t find the custom content?
Hmmm, I am thinking maybe I didn’t setup my theme probably last time!
First, I fully understand the logic behinds the fallbacks, to default template.
You said:
Change in admin > configuration > design > default theme = “mycustomtheme”
All the files you have in your theme will be used, and will fall back to /default theme for missing templates.
My earlier test showed that, when a custom content was not included in the ‘mycustomtheme’, Magento loads the page from the ‘default’ package. The fallback is a prevention for page showing error codes, this I understand, but from the usability point of view, this defeated the purpose of having to create a new custom theme when I have only one website, one store because I only wanted the page shows my custom theme when something is missing or error occurring.
So, unless I am not fully understand (very likely!) how the default theme works in relation with the fallback feature, the way I look at it, is I am having two choices with upgrade compatibility :
1) A bit more work - Overwrite the ‘template’, ‘layout’ and ‘Skin’ from the default package to my custom theme, and with each upgrade, I replace them back. Thought insignificant, it does save server space because there isn’t a Default package taking up space.
2) Keep the upgrade compatibility runs hassle free, use the Default Theme with fallback feature, but when something is missing in my custom them, my site visitor gets panic because she is seeing a Magento demo page, and the reason she is seeing the Magento demo page is because it’s very unlikely I will spend time to make the Default package looks like my custom theme as it will be like asking me doing double work for the same task.
This looks more like a design decision one needs to make
No, I did not Actually I didn’t quite understand when you said I will have to create my own interface - I thought you were implying that this is how it works, and if I don’t like it, then create my own system.
Thank you so much for repeating the *question*, I don’t ever remember if I read something about creating a new interface before. I thought we can only have
app/design/frontend/default/custome_theme/template
Will definitely try it out. Does is only involve with frontend?
The way Magento’s theming is setup is pretty slick. What Moshe means is that you can have interfaces and themes. An interface contains themes so for instance you can have:
Default Magento Install:
app/design/frontend/default/default/template/…
-The first default (frontend/default) is the interface name and the second default (default/default) is the theme name.
Custom Theme in Default Interface:
app/design/frontend/default/mycustomtheme/template/…
-The first default (frontend/default) is the interface name and the second mycustomtheme (default/mycustomtheme) is the new theme name.
Custom Theme in Custom Interface:
app/design/frontend/mycustominterface/mycustomtheme/template/…
-The first mycustominterface (frontend/mycustominterface) is the interface name and the second mycustomtheme (default/mycustomtheme) is the theme name.
The point of all of this is to allow you great flexibility in theming. Say for example you want to create seasonal themes (in the designers guide per example). You can create a new custom theme in the default interface and then use it when a different season comes around. This lets you create say packages of themes, a bunch of like-minded themes that are contained in one interface. You can then create an entirely new interface to contain a bunch of different themes for a completely different look.
The way Magento’s theming is setup is pretty slick. What Moshe means is that you can have interfaces and themes.
The point of all of this is to allow you great flexibility in theming. Say for example you want to create seasonal themes (in the designers guide per example). You can create a new custom theme in the default interface and then use it when a different season comes around. This lets you create say packages of themes, a bunch of like-minded themes that are contained in one interface. You can then create an entirely new interface to contain a bunch of different themes for a completely different look.
-Adam
Hi Adam, yes. Thank you for further explanation. That helps a lot
I am totally with you - the more I understand how Magento works, the more I appreciate how great this system is and the great effort and the vision the Varien team has for the software. And I have had better days working on Magento these past weeks
This worked perfect… on question. My website is in Spanish and English, whats the method to have the address_block change from one language to another (Locale is EN = english_address_block, Locale is Spanish = spanish_address_block)?
Do I need an if statement somewhere or is there something I´m missing in the block CMS gui?
let me explain my thinking again.
Actually I didn’t quite understand when you said I will have to create my own interface - I thought you were implying that this is how it works, and if I don’t like it, then create my own system.
