Hi,
I have installed subdomain on Drupal 6.5 with all the module dependencies. Followed readme.txt to the letter. The first two, and the fourt tests:
DNS server
Web server
Drupal's outbound URL rewriting

pass with green, but the third: "Drupal's inbound URL rewriting" does not pass.

Also, right now I get "Page not found" for any URL I try to access.

I checked the code in settings.php that I copied and pasted from readme.txt. This is it:

function custom_url_rewrite_outbound(&$path, &$options, $original_path) {

  // Used by the Subdomain module to generate URLs with subdomains
  if (module_exists('subdomain')) {
    subdomain_url_rewrite_outbound($path, $options);
  }
}

function custom_url_rewrite_inbound(&$result, $path, $path_language) {

  // Used by the Subdomain module to correctly interpret URLs with subdomains
  if (module_exists('subdomain')) {
    subdomain_url_rewrite_inbound($result, $path, $path_language);
  }
}

I have no idea what I am doing wrong. By the way, I already set the tilde setting to none.

Do you have any any advice?

CommentFileSizeAuthor
#3 subdomain-panel.png151.99 KBsam6

Comments

setvik’s picture

Can you paste the exact message given for the "Drupal's inbound URL rewriting" test that fails?

sam6’s picture

Hi, this is the message:

(keeping in mind I visit the admin/build/path/subdomain page using test.domain.com, since the regular www.domain.com gives "page not found" no matter which URL I try to vist)

"HTTP request to http://subdomain-test.test.withsrichinmoy.org/subdomain/test resulted in an internal Drupal path of subdomain/test. It should have been ~subdomain-test/subdomain/test

The custom_url_rewrite_inbound() function in settings.php is rewriting the internal path incorrectly. Did you patch settings.php? See readme.txt for instructions."

Thank you for all the help

sam6’s picture

StatusFileSize
new151.99 KB

I am attaching a snapshot of the subomain panel in the "URL aliases" section.

Also note that there are no other extra modules or themes enabled beside the core ones and the dependencies. I tried re-creating the site from scratch (and I mean, from the bare directory and db), always with same issue.

The cookie part is not set since, if I do, even test.domain.com would show "Page not found" for any URL, thus preventing me to reach the the subdomain panel.

sam6’s picture

Would anybody have any advice please?
Anything to try, or at least a way to know why that is happening?
Does this module have any debug possibility, any file I could look at?

gster’s picture

I've got the same question and then solved it.I think you maybe forgot to uncomment the "$cookie_domain" in setting.php.
em~sorry for my bad english,hope you got what i mean.
and good luck!

gster

setvik’s picture

Sorry for the belated reply.

I think gster is correct. It looks like you need to uncomment the $cookie_domain line in settings.php and set it to the name of your domain.

setvik’s picture

Status: Active » Postponed (maintainer needs more info)
sam6’s picture

Thank you very, very much for your help.

I thought that uncommenting the $cookie_domain assures that the user remains logged in as he cross between the various sub-domains.

Anyway, I didi that but unfortunately it does not seem to fix it. The moment I uncomment the $cookie_domain line I also start getting "page not found", no matter which third level domain or URL inside the domain I try to access (www.domain, test.domain, etc).

If I leave that line commented out, at least I can still reach the admin page.

Here is the settings.php file:

[user1@svati ~]$ cat sites/default/settings.php

<?php
// $Id: default.settings.php,v 1.8.2.1 2008/08/13 06:52:36 dries Exp $

/**
 * @file
 * Drupal site-specific configuration file.
 *
 * IMPORTANT NOTE:
 * This file may have been set to read-only by the Drupal installation
 * program. If you make changes to this file, be sure to protect it again
 * after making your modifications. Failure to remove write permissions
 * to this file is a security risk.
 *
 * The configuration file to be loaded is based upon the rules below.
 *
 * The configuration directory will be discovered by stripping the
 * website's hostname from left to right and pathname from right to
 * left. The first configuration file found will be used and any
 * others will be ignored. If no other configuration file is found
 * then the default configuration file at 'sites/default' will be used.
 *
 * For example, for a fictitious site installed at
 * http://www.drupal.org/mysite/test/, the 'settings.php'
 * is searched in the following directories:
 *
 *  1. sites/www.drupal.org.mysite.test
 *  2. sites/drupal.org.mysite.test
 *  3. sites/org.mysite.test
 *
 *  4. sites/www.drupal.org.mysite
 *  5. sites/drupal.org.mysite
 *  6. sites/org.mysite
 *
 *  7. sites/www.drupal.org
 *  8. sites/drupal.org
 *  9. sites/org
 *
 * 10. sites/default
 *
 * If you are installing on a non-standard port number, prefix the
 * hostname with that number. For example,
 * http://www.drupal.org:8080/mysite/test/ could be loaded from
 * sites/8080.www.drupal.org.mysite.test/.
 */

/**
 * Database settings:
 *
 * Note that the $db_url variable gets parsed using PHP's built-in
 * URL parser (i.e. using the "parse_url()" function) so make sure
 * not to confuse the parser. If your username, password
 * or database name contain characters used to delineate
 * $db_url parts, you can escape them via URI hex encodings:
 *
 *   : = %3a   / = %2f   @ = %40
 *   + = %2b   ( = %28   ) = %29
 *   ? = %3f   = = %3d   & = %26
 *
 * To specify multiple connections to be used in your site (i.e. for
 * complex custom modules) you can also specify an associative array
 * of $db_url variables with the 'default' element used until otherwise
 * requested.
 *
 * You can optionally set prefixes for some or all database table names
 * by using the $db_prefix setting. If a prefix is specified, the table
 * name will be prepended with its value. Be sure to use valid database
 * characters only, usually alphanumeric and underscore. If no prefixes
 * are desired, leave it as an empty string ''.
 *
 * To have all database names prefixed, set $db_prefix as a string:
 *
 *   $db_prefix = 'main_';
 *
 * To provide prefixes for specific tables, set $db_prefix as an array.
 * The array's keys are the table names and the values are the prefixes.
 * The 'default' element holds the prefix for any tables not specified
 * elsewhere in the array. Example:
 *
 *   $db_prefix = array(
 *     'default'   => 'main_',
 *     'users'     => 'shared_',
 *     'sessions'  => 'shared_',
 *     'role'      => 'shared_',
 *     'authmap'   => 'shared_',
 *   );
 *
 * Database URL format:
 *   $db_url = 'mysql://username:password@localhost/databasename';
 *   $db_url = 'mysqli://username:password@localhost/databasename';
 *   $db_url = 'pgsql://username:password@localhost/databasename';
 */
$db_url = 'mysqli://user1:password@localhost/user1_d1';
$db_prefix = '';

/**
 * Access control for update.php script
 *
 * If you are updating your Drupal installation using the update.php script
 * being not logged in as administrator, you will need to modify the access
 * check statement below. Change the FALSE to a TRUE to disable the access
 * check. After finishing the upgrade, be sure to open this file again
 * and change the TRUE back to a FALSE!
 */
$update_free_access = FALSE;

/**
 * Base URL (optional).
 *
 * If you are experiencing issues with different site domains,
 * uncomment the Base URL statement below (remove the leading hash sign)
 * and fill in the URL to your Drupal installation.
 *
 * You might also want to force users to use a given domain.
 * See the .htaccess file for more information.
 *
 * Examples:
 *   $base_url = 'http://www.example.com';
 *   $base_url = 'http://www.example.com:8888';
 *   $base_url = 'http://www.example.com/drupal';
 *   $base_url = 'https://www.example.com:8888/drupal';
 *
 * It is not allowed to have a trailing slash; Drupal will add it
 * for you.
 */
# $base_url = 'http://www.example.com';  // NO trailing slash!

/**
 * PHP settings:
 *
 * To see what PHP settings are possible, including whether they can
 * be set at runtime (ie., when ini_set() occurs), read the PHP
 * documentation at http://www.php.net/manual/en/ini.php#ini.list
 * and take a look at the .htaccess file to see which non-runtime
 * settings are used there. Settings defined here should not be
 * duplicated there so as to avoid conflict issues.
 */
ini_set('arg_separator.output',     '&amp;');
ini_set('magic_quotes_runtime',     0);
ini_set('magic_quotes_sybase',      0);
ini_set('session.cache_expire',     200000);
ini_set('session.cache_limiter',    'none');
ini_set('session.cookie_lifetime',  2000000);
ini_set('session.gc_maxlifetime',   200000);
ini_set('session.save_handler',     'user');
ini_set('session.use_only_cookies', 1);
ini_set('session.use_trans_sid',    0);
ini_set('url_rewriter.tags',        '');

/**
 * Drupal automatically generates a unique session cookie name for each site
 * based on on its full domain name. If you have multiple domains pointing at
 * the same Drupal site, you can either redirect them all to a single domain
 * (see comment in .htaccess), or uncomment the line below and specify their
 * shared base domain. Doing so assures that users remain logged in as they
 * cross between your various domains.
 */
$cookie_domain = 'withsrichinmoy.org';

/**
 * Variable overrides:
 *
 * To override specific entries in the 'variable' table for this site,
 * set them here. You usually don't need to use this feature. This is
 * useful in a configuration file for a vhost or directory, rather than
 * the default settings.php. Any configuration setting from the 'variable'
 * table can be given a new value. Note that any values you provide in
 * these variable overrides will not be modifiable from the Drupal
 * administration interface.
 *
 * Remove the leading hash signs to enable.
 */
# $conf = array(
#   'site_name' => 'My Drupal site',
#   'theme_default' => 'minnelli',
#   'anonymous' => 'Visitor',
/**
 * A custom theme can be set for the off-line page. This applies when the site
 * is explicitly set to off-line mode through the administration page or when
 * the database is inactive due to an error. It can be set through the
 * 'maintenance_theme' key. The template file should also be copied into the
 * theme. It is located inside 'modules/system/maintenance-page.tpl.php'.
 * Note: This setting does not apply to installation and update pages.
 */
#   'maintenance_theme' => 'minnelli',
/**
 * reverse_proxy accepts a boolean value.
 *
 * Enable this setting to determine the correct IP address of the remote
 * client by examining information stored in the X-Forwarded-For headers.
 * X-Forwarded-For headers are a standard mechanism for identifying client
 * systems connecting through a reverse proxy server, such as Squid or
 * Pound. Reverse proxy servers are often used to enhance the performance
 * of heavily visited sites and may also provide other site caching,
 * security or encryption benefits. If this Drupal installation operates
 * behind a reverse proxy, this setting should be enabled so that correct
 * IP address information is captured in Drupal's session management,
 * logging, statistics and access management systems; if you are unsure
 * about this setting, do not have a reverse proxy, or Drupal operates in
 * a shared hosting environment, this setting should be set to disabled.
 */
#   'reverse_proxy' => TRUE,
/**
 * reverse_proxy accepts an array of IP addresses.
 *
 * Each element of this array is the IP address of any of your reverse
 * proxies. Filling this array Drupal will trust the information stored
 * in the X-Forwarded-For headers only if Remote IP address is one of
 * these, that is the request reaches the web server from one of your
 * reverse proxies. Otherwise, the client could directly connect to
 * your web server spoofing the X-Forwarded-For headers.
 */
#   'reverse_proxy_addresses' => array('a.b.c.d', ...),
# );

/**
 * String overrides:
 *
 * To override specific strings on your site with or without enabling locale
 * module, add an entry to this list. This functionality allows you to change
 * a small number of your site's default English language interface strings.
 *
 * Remove the leading hash signs to enable.
 */
# $conf['locale_custom_strings_en'] = array(
#   'forum'      => 'Discussion board',
#   '@count min' => '@count minutes',
# );

function custom_url_rewrite_outbound(&$path, &$options, $original_path) {

  // Used by the Subdomain module to generate URLs with subdomains
  if (module_exists('subdomain')) {
    subdomain_url_rewrite_outbound($path, $options); 
  }
}

function custom_url_rewrite_inbound(&$result, $path, $path_language) {

  // Used by the Subdomain module to correctly interpret URLs with subdomains
  if (module_exists('subdomain')) {
    subdomain_url_rewrite_inbound($result, $path, $path_language); 
  }
} 

Korak1’s picture

I'm having the same problem. When I enabled the subdomain modude, I suddenly started getting "Page Not Found" messages even for the www.example.com domain. (Or example.com) If I rename the subdomain folder in the module directory, then the site will be accessible for a couple of pages before returning a constant stream again of "page not found". In my case, I've installed the module in sites/all/modules since I anticipate a mutli-site scenario for this code. My cookies statement is uncommented. I've been trying to figure out the problem with no success. I'm not even sure what to try this point so any suggestions will be very much appreciated.

Thanks!

sam6’s picture

I am still in the dark with this module.

I just wish there would be some kind of debug log file. I am trying Domain Access as well, but it is quite more than I need. Subdomain would be perfect, if only it would work.

Korak1’s picture

I'm adding a little more detail here in the hope that it will help... when the subdomain module is enabled every page on the domain including the base domain returns the "Page not found" message of the Drupal install. Additionally, if I attempt to go to a subdomain, then I get the install screen.

If I unenable the subdomain module, (which I can only access by renaming the subdomain module on the server so it doesn't run), then the site functions normally.

So, I can see that I have configured something incorrectly but have tried to step through the configuration steps and don't see anything wrong. Has anyone encountered this problem before and solved it?

Thanks!

Korak