Absolute image paths
PermalinkFor 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!
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.
If you FTP to your site and navigate to the sub-domain, are there concrete5 files installed there?
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.
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.
Thanks!
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.
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.
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.
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.
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.
<?php
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.
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
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.
I guess the work around for now will be the wildcard redirect.
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.
(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....
James
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:
http://higgins-steele.hawkeconsulting.ca/contracting/...
This appears to work at first:
http://hawkeconsulting.ca/higgins-steele...
But crashes when you navigate away from the home page.
http://hawkeconsulting.ca/higgins-steele/contracting/...
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.
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)....
# 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')) { $pos = stripos($_SERVER['SCRIPT_NAME'], DISPATCHER_FILENAME); 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.
I had same issue once and this was set differently.
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.