Absolute image paths

Hi, I am having an issue that I cant seem to resolve on my own and hoping for some help. Currently I have a C5 installation in a sub-domain and was installed using the sub-domain address. When i add images or files to the site everything is fine as long as I access the site via the sub-domain address. If I go to the site via the standard address, the image path adds a second instance of the sub-domains folder.

For example:

Accessing the site (Non edit mode btw) from w2zxl.hevener.com, I can see the files I uploaded and the source code shows (var CCM_IMAGE_PATH = "/concrete/images";)

However; accessing the site from hevener.com/w2zxl/ the images are gone and now the source code reveals (var CCM_IMAGE_PATH = "/w2zxl/concrete/images";)

As you can see, it added the "w2zxl" path...

How can I change it so the paths stay constant or can this not be done?

This also pertains to files as well, if I link a file to download the same thing happens. Accessing via the sub-domain address works fine, accessing via the root domain with the sub-domains folder creates the duplicate "w2zxl" folder.

Thanks in advance, this has been driving me nuts!

View Replies:
mhawke replied on at Permalink Reply
Perhaps I'm confused about what you are trying to accomplish. If you install concrete5 in a sub-domain then that's where it is. It is not installed anywhere else and you should only expect it to work properly if your URL starts with the sub-domain. Did you happen to install concrete5 in both places (http://w2zxl.hevener.com/ ANDhttp://www.hevener.com/w2zxl ) and are using the same database for both installs?

I use sub-domains all the time to develop a new site and then when it's ready, I move the files to the root. I have never experienced any such problems. If I put the sub-domain at the end of the URL (as if it's a folder) I get a 404.
Hevener replied on at Permalink Reply
I only installed it once. When the Site Builder script for my provider asked for a destination, I typed w2zxl.hevener.com, that's all. (The absolute paths are the same whether I would have typed hevener.com/w2zxl or w2zxl.hevener.com, they both show up as home1/hevenerc/public_html/w2zxl/.). The database was created automatically by the installer and the MySql list only shows the one DB so there doesn't appear to be multiple DB's.

When I added the sub-domain to the server initally, it created the folder "w2zxl" in which to provide a place to put files for that sub, so that's why that folder exists.

So, you can access that folder by either typinghttp://w2zxl.hevener.com or by typinghttp://www.hevener.com/w2zxl , they are one and the same.

For some reason though the C5 variables are treating them differently. This was never an issue with the earlier versions of C5 though so I'm not sure what happened to create this issue now, all I know is that it's driving me nuts.

Thanks for replying and for any help you can offer.
Hevener replied on at Permalink Reply
Ok, I've added a redirect to my .htaccess file, will see if this might fix the issue, will keep updated.
mhawke replied on at Permalink Reply
I religiously stay far away from installation scripts.

If you FTP to your site and navigate to the sub-domain, are there concrete5 files installed there?
jshannon replied on at Permalink Reply
A few things:

1. CCM_IMAGE_PATH isn't used for most images. Yes, it's indicative of the problem, but that's not the exact reason why the "images are gone". What's do the "gone" images say? (What's the path in the source?) You can look at that and compare it to the actual files (via, eg, FTP).

I just went to your site and it looks like the redirect is active, so not much I can do.

2. Based on the CCM_IMAGE_PATHs you pasted, this is what I expected. If concrete5 is installed / copied / linked / whatever in /somedir, and it works (such that loading site.com/somedir loads c5), then that means the concrete5 "root" is in /somedir and thus the concrete/images directory is in /somedir/concrete/images. So, based on the URL you're using, and the path it provides, I'd say things are working fine.

However, you say they're not. I feel something is wrong with the way c5 is "installed" within your subdirectory.

If you undo the redirect (so that /w2zxl is "working" ) it might be easier to poke around.
Hevener replied on at Permalink Reply
It would be great to have a second set of eyes on this...I'll take out the wildcard redirect and let ya see whats going on.

There is only one place that C5 installed and that is in the home1/hevenerc/public_html/w2zxl folder so yes, there are concrete files there...it's the only place it could be.


Ok, I took out the redirect and now all of the work done (including adding a theme) since then is now gone from "hevener.com/w2zxl" but perfectly fine at w2zxl.hevener.com. Very weird.

Compare the two and check it out.http://w2zxl.hevener.com andhttp://www.hevener.com/w2zxl .

They are both the same folder.
mhawke replied on at Permalink Reply
Some hosts show the sub-domains as a folder off of 'public_html' while others show it above 'public_html'. If it was installed into a true sub-domain that you created using the host's Control Panel then it's true location is above the root and not in a folder below the root. From what I can see, your site seems to have been properly installed into a sub-domain and is available from there.

I'm still trying to figure out why it's important to have it also available from http://www.hevener.com/w2zxl . I don't believe the 'w2zxl' folder is really a folder. I believe your host is showing your sub-domain below the root as a 'convenience'. I know GoDaddy does this. Siteground and TMDHosting don't so I have to navigate above 'public_html' to see my sub-domains.
Hevener replied on at Permalink Reply
Two reasons:
1. When editing, some if not most themes use the root site to edit with so it has to be there for that. (If I was to edit the site now, it would show "www.hevener.com/w2zxl/index.php?blahblah" and not "w2zxl.hevener.com/index.php?blahblah)

2. For SEO purposes. Search engines will see the site as simply a folder.

But as for where the folder is located, my Host doesn't provide me with much choice...when asked where to install I only have /home1/hevenerc/public_html/w2zxl/ to choose from. I cant tell it to go anywhere else.
jshannon replied on at Permalink Reply
Yeah. Mhawke is right. I suspected that you were doing this (subfolder) for development reasons, or because you had a site at the root, and you wanted your ham site to be in it's own directory.

But I just checked the root and it's blank. If you don't plan on having a different site at the root, you really should just move all the concrete5 files to that root. Even if it's misconfigured (see my other post), it'll work. It'll be better for SEO, etc.
Hevener replied on at Permalink Reply
Yes, it would be better I agree...but my Root was setup for my business for many years and I'm not sure if I will want to go back to it again or not...for now I just want the option of having the root available for it again.
jshannon replied on at Permalink Reply

Looks like the CCM_IMAGE_PATH is actually /concrete (vs /w2zxl/concrete). As I said, this isn't the direct cause of the broken images (and CSS files, etc), but it's got the same root.

So, basically, it tries to load an image at /files/some_image instead of /w2zxl/files/some_image.

This might be some crazy config in your apache (as it bases it on SCRIPT_NAME), but it's more likely you have something hardcoded in your /config/site.php file. Can you paste the contents (minus your db password and the SALT)? I'm expecting DIR_REL or DIR_BASE or somethign to be set.
Hevener replied on at Permalink Reply
This is the entire contents of my site.php file.

define('DB_SERVER', 'localhost');
define('DB_USERNAME', 'hevenerc_con2');
define('DB_PASSWORD', '**********');
define('DB_DATABASE', 'hevenerc_con2');
define('PASSWORD_SALT', '******************************');

The *'s obviously are my edit. For some reason, the newest version did away with DIR_REL etc...

Thanks again.
jshannon replied on at Permalink Reply

I still suspect that the DIR_REL is hardcoded somewhere. A apache config issue is always possible, but unlikely.

Try to add the following to the bottom of your config/site.php file

define('BASE_URL', 'http://www.hevener.com');
define('DIR_REL', 'w2zxl/');

This should override any weird apache issue. If it's already being hardcoded elsewhere (some wacky host install routine), then you might get an error (because you're trying to redefine it), but that'll tell you where it's define'd initially, which is good.

Also, note that w2zxl.hevener will stop working. Even if that's not what you want, you should still at least test the above.
Hevener replied on at Permalink Reply
I already did...no go. Thanks though :/

I guess the work around for now will be the wildcard redirect.
mhawke replied on at Permalink Reply
Concrete5 is very good at knowing where it is installed without intervention most of the time. The JavaScript variable in the View Source:

CCM_BASE_URL = "http://w2zxl.hevener.com";

is the same no matter what URL you use which tells me it's properly installed in a true sub-domain. If you want it in a folder then install it in a folder. At that point the CCM_BASE_URL will show 'http://www.hevener.com' and the CCM_DIR_REL will be '/w2zxl'

The themes take their paths from the BASE_URL and the DIR_REL variables and editing will be fine. I have installed many test sites into sub-domains and folders and they all just work 'out of the box'. C5 knows where it is.
jshannon replied on at Permalink Reply
I don't have a lot (any) experience with subdomains / subdirectories, but I don't see how c5 could possible "know" that it's supposed to be at that particular domain. It's not like it checks the parent directory and sees that it has some special name associated with subdomains and "knows" that it should be there.

(It uses the apache SERVER variables, which is why I suggested that there could be some weird config issue with that. Apache shouldn't be telling the script that's run when you go to domain.com/something that it's actually at something.domain.com -- unless the directory is configured as some sort of weird "alias"). And, even if it did "know" the "correct" directory, it should most definitely allow you to override it via the defines that the OP says he's already tried. The fact that that made no difference (maybe it did, and it was done wrong and wasn't obvious), means that something really weird is going on here. Like you, I suspect the "auto install" from the host.

Speaking of the host, I noticed this 404 page --http://hevener.com/w2zxl/inde . I wouldn't be suprised if they have some other "non-standard" setup....

mhawke replied on at Permalink Reply 2 Attachments
jshannon, I certainly mean no disrespect to your advice and expertise but I'd bet my house that the 'w2zxl' folder is indeed an 'alias' to a true sub-domain called 'w2zxl' and that it isn't really a folder below the root. That's why there are 404's everywhere when we try to address it as a folder. It doesn't exist as a folder.

I'm not suggesting that C5 can read Hevener's mind but when it's installed it certainly does a good job of sniffing out what folder it's installed in and sets the BASE_URL and REL_DIR accordingly. Have a look at [root]/concrete/base.php and [root]/concrete/base_pre.php. This is where the sniffing action happens. You can override these in your site.php but you do so at your peril.

I have attached a Filezilla screenshot of a GoDaddy account that I sometimes use for testing. The circled folders are not real. They are sub-domains that are actually located above the root. When you create these sub-domains, the Control Panel asks you for a folder name and that folder is listed below the root but it's not really there. I get the same kind of problems as Hevener is having if I try to address the site as a folder.

Works when addressing the sub-domain:


This appears to work at first:


But crashes when you navigate away from the home page.


IMHO, the best answer is to the SEO issue is to purchase a domain called 'w2zxl' and not have the site in a folder or a sub-domain.
jshannon replied on at Permalink Reply
No disrespect taken... at all.

I've just never seen the sniffing you speak of. And I don't see how c5 could possibly do it. The directory-based sniffing wouldn't cause the domain name (BASE_URL) to change. If anything, the way that his host (and possibly, yours) is configured, Apache is presenting a weird SERVER['HTTP_HOST'] environment. This would have to be a lot different than a typical directory alias... it'd have to be configured to cause apache to actively lie in the environment variables (saying the host is different than the one accessed). Not saying it's impossible, just that I've never seen it.

Also, yes, manually setting these variables isn't usually recommended, but if they ARE set, then they should take precedence (even if you set it to 'jxljasdfnm;lcx4j09s') which isn't what we're seeing (assuming the OP did it and evaluated correctly, which I sort of doubt)....
mhawke replied on at Permalink Reply
As far as I can see from looking at concrete/config/base.php, nothing fancy is happening when C5 determines where it's been installed. Starting at line 18:
# These items should be set by site.php in config/ but if they're not that means we're installing and we need something there
/* https patch applied here */
if (!defined('BASE_URL')) { 
   if(isset($_SERVER['HTTPS']) && ($_SERVER['HTTPS'] == 'on')) {
      define('BASE_URL', 'https://' . $_SERVER['HTTP_HOST']);
   } else {
      define('BASE_URL', 'http://' . $_SERVER['HTTP_HOST']);
if (!defined('DIR_REL')) {
   if($pos > 0) { //we do this because in CLI circumstances (and some random ones) we would end up with index.ph instead of index.php
      $pos = $pos - 1;
   $uri = substr($_SERVER['SCRIPT_NAME'], 0, $pos);

My point is that hevener posted that the original installation was done into 'http://w2zxl.hevener.com' and that's what C5 is reporting in CCM_BASE_URL. I see no reason to expect the site to work properly if you use 'http://www.hevener.com/w2zxl' unless you re-direct in the .htaccess which appears to be what hevener has decided to do.
TMDesigns replied on at Permalink Reply
Go to dashboard and check the "File Storage Locations" is set to the right path.

I had same issue once and this was set differently.