I have trouble understanding what settings control the url of the search results page "domain-b.com/search/content/term" for the search block. It keeps redirecting to the default domain "domain-default.com/search/content/term" when I post a search in the search block from "domain-b.com/front", which kind of defeats the purpose of trying to keep the domains apart as separate sites. Any help pointing me in the right direction would be greatly appreciated....

CommentFileSizeAuthor
#5 search-settings.jpg580.13 KBleanderl

Comments

agentrickard’s picture

DA does not issue redirects in this case (unless domain B is set to "inactive"). If you have a redirect, and not a form action problem, there is nothing I can do but help you find the problem module.

A form action pointing to the default domain should not be coming from DA. Perhaps some other module is making the search form use an absolute URL.

If you have the SEO options enabled, all forms should have the 'action' element set to an absolute URL to the current domain.

What is the HTML being generated for the block?

leanderl’s picture

@agentrickard. Thank you for replying and helping out, I'm very grateful.

Yes, I know the behavior is strange. The action of the form is set to "/", see code below. But if it is as you say, that DA doesn't do anything other than redirect to the domain one is using when submitting, then the problem must reside elsewhere. The only "special" thing about my Search is that I use Display Suite to render the results.

<form action="/" method="post" id="search-block-form" accept-charset="UTF-8"><div><div class="container-inline">
      <h2 class="element-invisible">Sökformulär</h2>
    <div class="form-item form-type-textfield form-item-search-block-form">
  <label class="element-invisible" for="edit-search-block-form--2">Sök </label>
 <input title="Ange de termer du vill söka efter." type="text" id="edit-search-block-form--2" name="search_block_form" value="" size="15" maxlength="128" class="form-text" style="color: rgb(115, 118, 129); ">
</div>
<div class="form-actions form-wrapper" id="edit-actions"><span class="button-wrapper"><span class="left-slice"><span class="right-slice"><input type="submit" id="edit-submit" name="op" value="Sök" class="form-submit"></span></span></span></div><input type="hidden" name="form_build_id" value="form-DiII8uKgKyWsoybn9kXArXHX0fX1GhPbST15WvO3v3w">
<input type="hidden" name="form_token" value="zPArV3AKQd7B5aLugil3ZBjvSdKa37MWU09xtQn_-_Y">
<input type="hidden" name="form_id" value="search_block_form">
</div>
</div></form>
leanderl’s picture

Ok, so I turned off Display Suite (Search display) and it seems to be working as expected. Wish there was a way though to combine the two...

agentrickard’s picture

We've seen some odd behaviors with DS before. If DS rewriting the form action?

Does enabling the SEO option in DA fix the issue?

leanderl’s picture

StatusFileSize
new580.13 KB

Thanks for trying to help. I have the following search settings... (see attached screen shot). The search itself is working, if I manually type the correct path (domain-b.com/search/content/term) I get the result I want. But when I do the Search with the search form it redirects to the default domain (domain-default.com/search/content/term).

(PS: The Search form itself is the standard drupal block)

agentrickard’s picture

Right. What we're trying to determine is _where_ the redirect occurs. It's not in the defined #action of the form, so that means that something else is interfering.

You can set "Search engine optimization" to "Rewrite all URLs to a single source". That will force the #action URL to be absolute (e.g. http://example.com/search instead of /search).

If you change that and still get redirected, then something else is causing the issue.

DA will only issue a redirect if the search is performed from a domain marked "inactive" and the user cannot access that domain.

leanderl’s picture

Well, I just can't get it to work not even with "simple" default node search. There must be something really special in my installation. I've disabled Context, Display Suite, i18n, Redirect. Removed the entire template.php for my theme.

I'm wondering if it is somehow related to localhost issues. So far this is only a test environment. I'm using default domain loc.sitename.se and alternative domain dev.differentsite.se. Perhaps the domain prefixes should be defined or treated differently. I guess I'll have to install Netbeans and step through the execution of the code to see where the redirect to default domain happens.

leanderl’s picture

Perhaps it is something with my .htaccess?


#
# Apache/PHP/Drupal settings:
#

# Protect files and directories from prying eyes.
<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)$|^(\..*|Entries.*|Repository|Root|Tag|Template)$">
  Order allow,deny
</FilesMatch>

# Don't show directory listings for URLs which map to a directory.
Options -Indexes

# Follow symbolic links in this directory.
Options +FollowSymLinks

# Make Drupal handle any 404 errors.
ErrorDocument 404 /index.php

# Set the default handler.
DirectoryIndex index.php index.html index.htm

# Override PHP settings that cannot be changed at runtime. See
# sites/default/default.settings.php and drupal_initialize_variables() in
# includes/bootstrap.inc for settings that can be changed at runtime.

# PHP 5, Apache 1 and 2.
<IfModule mod_php5.c>
  php_flag magic_quotes_gpc                 off
  php_flag magic_quotes_sybase              off
  php_flag register_globals                 off
  php_flag session.auto_start               off
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass
  php_flag mbstring.encoding_translation    off
</IfModule>

# Requires mod_expires to be enabled.
<IfModule mod_expires.c>
  # Enable expirations.
  ExpiresActive On

  # Cache all files for 2 weeks after access (A).
  ExpiresDefault A1209600

  <FilesMatch \.php$>
    # Do not allow PHP scripts to be cached unless they explicitly send cache
    # headers themselves. Otherwise all scripts would have to overwrite the
    # headers set by mod_expires if they want another caching behavior. This may
    # fail if an error occurs early in the bootstrap process, and it may cause
    # problems if a non-Drupal PHP file is installed in a subdirectory.
    ExpiresActive Off
  </FilesMatch>
</IfModule>

# Various rewrite rules.
<IfModule mod_rewrite.c>
  RewriteEngine on

  # Block access to "hidden" directories whose names begin with a period. This
  # includes directories used by version control systems such as Subversion or
  # Git to store control files. Files whose names begin with a period, as well
  # as the control files used by CVS, are protected by the FilesMatch directive
  # above.
  #
  # NOTE: This only works when mod_rewrite is loaded. Without mod_rewrite, it is
  # not possible to block access to entire directories from .htaccess, because
  # <DirectoryMatch> is not allowed here.
  #
  # If you do not have mod_rewrite installed, you should remove these
  # directories from your webroot or otherwise protect them from being
  # downloaded.
  RewriteRule "(^|/)\." - [F]
  #RewriteCond %{HTTP_HOST} ^differentsite.se$ [OR]
  #RewriteCond %{HTTP_HOST} ^www.differentsite.se$ [OR]
  #RewriteCond %{HTTP_HOST} ^loc.differentsite.se$
  #RewriteRule (.*)$ http://loc.sitename.se/differentsite$1 [R=301,L]  

  # If your site can be accessed both with and without the 'www.' prefix, you
  # can use one of the following settings to redirect users to your preferred
  # URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
  #
  # To redirect all users to access the site WITH the 'www.' prefix,
  # (http://example.com/... will be redirected to http://www.example.com/...)
  # uncomment the following:
  # RewriteCond %{HTTP_HOST} !^www\. [NC]
  # RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
  #
  # To redirect all users to access the site WITHOUT the 'www.' prefix,
  # (http://www.example.com/... will be redirected to http://example.com/...)
  # uncomment the following:
  # RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
  # RewriteRule ^ http://%1%{REQUEST_URI} [L,R=301]

  # Modify the RewriteBase if you are using Drupal in a subdirectory or in a
  # VirtualDocumentRoot and the rewrite rules are not working properly.
  # For example if your site is at http://example.com/drupal uncomment and
  # modify the following line:
  # RewriteBase /drupal
  #
  # If your site is running in a VirtualDocumentRoot at http://example.com/,
  # uncomment the following line:
  # RewriteBase /

  # Pass all requests not referring directly to files in the filesystem to
  # index.php. Clean URLs are handled in drupal_environment_initialize().
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_URI} !=/favicon.ico
  RewriteRule ^ index.php [L]

  # Rules to correctly serve gzip compressed CSS and JS files.
  # Requires both mod_rewrite and mod_headers to be enabled.
  <IfModule mod_headers.c>
    # Serve gzip compressed CSS files if they exist and the client accepts gzip.
    RewriteCond %{HTTP:Accept-encoding} gzip
    RewriteCond %{REQUEST_FILENAME}\.gz -s
    RewriteRule ^(.*)\.css $1\.css\.gz [QSA]

    # Serve gzip compressed JS files if they exist and the client accepts gzip.
    RewriteCond %{HTTP:Accept-encoding} gzip
    RewriteCond %{REQUEST_FILENAME}\.gz -s
    RewriteRule ^(.*)\.js $1\.js\.gz [QSA]

    # Serve correct content types, and prevent mod_deflate double gzip.
    RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
    RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]

    <FilesMatch "(\.js\.gz|\.css\.gz)$">
      # Serve correct encoding type.
      Header set Content-Encoding gzip
      # Force proxies to cache gzipped & non-gzipped css/js files separately.
      Header append Vary Accept-Encoding
    </FilesMatch>
  </IfModule>
</IfModule>
mrgoltra’s picture

Subscribing. I am experiencing this too.

agentrickard’s picture

Status: Active » Closed (cannot reproduce)
Lalas’s picture

Hi

These are just suggestions you can try i'm not sure if it works in your case

1. Change the default theme to any core theme and test for result - If this case resolves the issue then you might have a wrong entry in any of your block. Disable each block and find the culprit

2. Disable all the rules and test for the result - If disabling rule resolve issue then enable each rule one by one and find the culprit