By mightypants on

Hello all,

I'm a newb, so my apologies if this question is very basic. I've searched the forum and have found some similar issues to the one I'm having, but thus far no solutions. Here's the problem:

Internal URLs, both images and links to other nodes, are not working properly. I'm trying to create links from within the text of various pages to other pages on the site. I am using clean URLs. I've tried creating URLs both with and without the leading slash, and the only time it works is when I use the leading slash and the aliased path has no subdirectories, i.e. there is only one slash and one argument after it. The problem is, many of my pages currently have more complex aliased paths. This seems related to this thread: http://drupal.org/node/552656, though in that case it is images, not links that are broken. I am having this problem with images as well. I haven't been able to get any images to appear without using absolute URLs. Any thoughts? Thanks.

Here's the setup:
server: hostmoster.com
php:5.2.11
apache:2.2.14
mysql: 5.1.43-log
OS: both Windows XP and Mac OSX
browser: various

⋅ Categories: Drupal 6.x

Comments

vm’s picture

vm commented

examples of a working path and a non working path?

have you altered your .htaccess or settings.php files?

link to the site so that it can be inspected further?

some information about the way drupal is installed:
is it in your public root?
in a subdirectory in your public root?

mightypants’s picture

mightypants commented

working:<a href="/contact.html">
not working: <a href="/services/documentation.html">
also not working: <img src="/sites/default/files/images/approach_communication.jpg" />

I am aware that the file extensions are not necessary, this is the way my boss set it up. I did alter the .htaccess and settings.php files to point to the appropriate address. Drupal is installed in the public root. I probably shouldn't post the link just yet, I'll have to check with my boss on that one.

Thanks.

vm’s picture

vm commented

no idea how adding extensions effects things.

if <img src="/sites/default/files/images/approach_communication.jpg" /> isn't working, what path is is the image pointing to? ie: view the source and check the path, what is being added or taken away?

and how does dropping the leading / affect the above investigation? what path does it produce when viewing the source?

you altered settings.php and .htaccess to point to the proper url, under most circumstances these don't need to be altered if using drupal in your root. That said, what exactly did you alter? if posting entire files, please use pastebin or drupalbin

mightypants’s picture

mightypants commented

I had to change these two files because we are currently using a temporary/shared IP address. Here is the e-mail we received from hostmonster's support about the issue:

Because Drupal (like Wordpress) handles redirects and temporary URLs in an unusual manner, to get Drupal to recognize this 'test' URL, you have to change two things.

(either make backups of these files first, or copy and comment out the original lines before you change them because once the site goes live, you will need to undo the changes you make below.)

1. Change the "$base_url = " in /public_html/sites/default/settings.php to your temporary URL WITHOUT A TRAILING SLASH!!!!

for example:
$base_url = 'http://74.220.215.210/~nsightwo';

2. Uncomment the "RewriteBase /drupal" line in /public_html/.htaccess and change it from:

#RewriteBase /drupal
to
RewriteBase /~

for example:
RewriteBase /~nsightwo

and now you should be able to set up and test the website you created in Drupal. Once you are finished and have tested everything successfully, be sure to undo the above changes so that the site works properly once bluehost's DNS becomes authoritative for the site and the real URL is working.

I made the changes as above which fixed our original problem (we couldn't access the site at all).

When I view source, that image URL is: http://74.220.215.210/sites/default/files/images/approach_communication.jpg. When I remove the leading slash, it appears as: sites/default/files/images/approach_communication.jpg. I've now noticed that the links created using Drupal's menus all include our IP address user name in front, ex: <a href="/~nsightwo/company.html" title="">COMPANY</a>. So maybe I need to add that to all my internal links, but it seems that I shouldn't have to, given that it's included in the base_url. Maybe I'm not understanding how this is supposed to work, but shouldn't my site root reflect whatever the base_url is set to? Also, the one internal link I've created that does work (<a href="/contact.html">Contact</a>) does not include the user name. I'd rather not have to change all the internal links to include this bit, because then it will all have to be changed again when we move to the new domain. Any suggestions?

Thanks for your help.

vm’s picture

vm commented

Are you sure both changes were required? Did you test with just the change to settings.php for example?

On a test site, thats what I'd do. I'd test only using the change in settings.php with reference to $base_url
If that doesn't work, I'd test with only the changes to .htaccess and compare.

mightypants’s picture

mightypants commented

Yes, both changes were required. At first I just made the settings.php change which gave us access to the home page, but we were unable to access anything beyond that (i.e. all links led to error messages). Making the change to the .htaccess file corrected the problem. Thanks.

vm’s picture

vm commented

that information doesn't necessairly mean it was needed in both files. What if it was done in .htaccess only and not settings.php?

mightypants’s picture

mightypants commented

Touché. I'll try that out when I get a chance. There are usually a couple people working on the site, so I'll have to find a time when I can mess with it. Thanks.

mightypants’s picture

mightypants commented

VM,

I have some updates on this issue. I tried reverting the base_url in settings.php to it's default state as per your suggestion and everything still works, so it appears your were correct that this change was not necessary. I found out that the URLs linking to other pages are now working and have been for a while--I'm not sure how this got fixed, but they work so I'm not worried about it for now.

URLs for images are still a problem. After reverting settings.php I've gotten some images to work with relative paths with no leading slash. For example, one image in the body of a page has the path <img src="sites/default/files/images/icon_training.jpg" />, and it appears the same when I view source on the published page. This image works. Using a leading slash, however, breaks the image. The problem I have now is that I have blocks that contain images that will appear appropriately on some pages but not others, depending on the location of those pages and how that affects their relative paths to the images. So, if I have an image in a block with the path <img src="sites/default/files/images/callout_somwba.jpg" />, it works fine on the home page and other pages on the top level of the site. However, it will not work, for example on a page with a URL of http://74.220.215.210/~nsightwo/company/nsight-content-development-and-communications-specialists because it is in the "company" subfolder. Am I wrong in assuming the leading slash should work in this case, such that images using it will always refer first to the site root? Any ideas how to fix this? Thanks.

vm’s picture

vm commented

I'd first get a new copy of .htacess and use it in place of one that was altered and realtered.

or, pastebin or drupalbin settings.php minus your db_connection info and .htaccess and link them here. (please don't paste the contents of the files here) just the links to the files.

Obviously if using a new .htaccess that hasn't at all been altered you don't need to pastebin that, I can look at that myself. Something still isn't quite right about the way one of the two files. leadning slash should be used.

which brings me back to someting wrong with .htaccess or something unset that should be or $base_url not not correct.

mightypants’s picture

mightypants commented

Just to clarify, based on my tests it seems that the changes to .htaccess were necessary but those made to settings.php were not. I'll put the code on drupalbin, but could you clarify what info I should omit from settings.php? I'm not sure what you mean by db_connection and searching for that text in the file produced no results. Thanks.

vm’s picture

vm commented

whatever is in $db_url. I don't want your username password or DB location. That's private and not required to sort out what the issue may be. Obviously you are connecting to the DB.

mightypants’s picture

mightypants commented

settings.php: http://drupalbin.com/14155?nocache=1

.htaccess: http://drupalbin.com/14156?nocache=1

vm’s picture

vm commented

looks to me like .htaccess is the culprit

RewriteBase /~nsightwo

looks like your server account folder ? Which normally wouldn't every be referred to.
What folder does your site resolve to when you put in your domain name or IP address?

if that is indeed a subdirectory and not an account folder, you are missing the /company part of the path which is also a subdirectory. But if this is also true, I'd wonder why you are two levels deep and not using the public_root or at the very least up one more level.

mightypants’s picture

mightypants commented

My understanding is that we are on a temporary/shared IP address, and "~nsightwo" is what distinguishes us from other users on this IP. The full URL to access our test site is: http://74.220.215.210/~nsightwo/. The index.php file for this Drupal installation resides in the public_html folder of our server space, for whatever that's worth. The line of code you pointed to as the problem is as I was told it needed to be by hostmonster's tech support (see the fifth post in this thread for their e-mail). What do you think it ought to be instead?

vm’s picture

vm commented

you aren't telling drupal about the /company subdirectory which I've already stated.

please list your directory tree.

is it /~nsightwo/company/public_html ?

or /~nsightwo/public_html/company ?

or /public_html/~nsightwo/company ?

...

mightypants’s picture

mightypants commented

"company" is a subdirectory on our site, so if http://74.220.215.210/~nsightwo/ is our home page, then http://74.220.215.210/~nsightwo/company is where all the "company" related pages are. public_html doesn't appear in the path when viewing any of the pages, I thought it was equivalent to the ~nsightwo directory.

Here is the directory tree. As I said, our Drupal installation resides in public_html. Sorry if this doesn't make sense, I'm a bit confused.

(/home1/nsightwo)
.cpanel
.htpasswds
.trash
access-logs
etc
mail
public_ftp
public_html
tmp
www

vm’s picture

vm commented

the directive in .htaccess should be tested it /company not with the useraccount folder of the server which is what /~nsightwo/ is based on the information above. When you get a domain name it will resolve to /public_html/

unless of course you have it resolve to /public_html/company at which point the work you're doing now will become void.

personally, I would have put the drupal install directly in public_html and not in a /company subdirectory. doing so should negate the need for any of this work that is being done.

yourIP/~nsightwo/public_html/company is where your site is currrently resolving to when being pulled up in a browser.

mightypants’s picture

mightypants commented

I'm sorry, there appears to be a misunderstanding here. The Drupal installation is within the public_html folder, as I mentioned before (in the post beginning with "My understanding..."). The URL with "company" in it was just an example of the problem. Sorry if I was unclear about that.

vm’s picture

vm commented

Then I've no idea what is happening here. not sure at all why you need to mess with either if your site is resolving correctly with public_html/index.php as you aren't in a subdirectory at all based on your explanation above.

One of the reasons I build on a local machine and avoid a server until it is ready with a domain name.

mightypants’s picture

mightypants commented

There are several people working on this project, some remotely, so we needed to have it up on a server. The reason we messed with the files is, as I said, because the site was NOT resolving correctly.

vm’s picture

vm commented

puttting it on the server isn't the issue as much as not having a domain name which I think is adding a layer of complexity and confusion due to the way you must access the site in the browser by using the user account in the url which wouldn't be needed with a domain name. Evidentally calling the useraccount on the server in the url is redirecting in some way to the public_html folder.

As an aside, a local machine can act as a public server for users to gain remote access. Though you certainly should be able to do what you are trying to do.

# If your site is running in a VirtualDocumentRoot at http://example.com/,
# uncomment the following line:
# RewriteBase /

you can try uncommenting the above RewriteBase line which may or may not help. I'm fuzzy on the definition of a VirtualDocumentRoot

There is no way for me to test ideas as I don't have a static IP address with user accounts. I use domain names. Someone else is going to have to jump in here with more experience in this area where it concerns working with IP addresses and user accounts on a shared server.

Good Luck.

mightypants’s picture

mightypants commented

We're converting the site to Drupal, so the domain is currently occupied by our live site. Thanks again for all your help.

vm’s picture

vm commented

then I'd do it in a subdomain of the current domain name which wouldn't affect the current site. When ready remove the subdomain and point the document root on the server to the folder which holds the drupal install.