[solved] Search in CMSMS ver 1.5.2 generates incorrect action="" path

[JohnnyB]

I noticed the search module did not work on any interior pages. Attempting a search redirected to the originating page and did not process.  It worked fine on the home page. I tried this on 3 different installs on 2 different servers using cms ver 1.5.2

The problem is the generated action="" path. On interior pages it becomes action="http://www.domain-name.com/page-alias/" and it should be action="http://www.domain-name.com/[b]index.php[/b]" regardless of the hierarchy.

The root of the problem is in this file:
/lib/classes/module_support/modform.inc.php

The new version (1.5.2) uses the current page's URL action="" .  See line 35:

Code: Select all

$pageURL .= $_SERVER["SERVER_NAME"].$_SERVER["REQUEST_URI"];

Solution that works for me (tested in 4 sites) is replacing line 35 with PHP_SELF

Code: Select all

$pageURL .= $_SERVER["SERVER_NAME"] . $_SERVER['PHP_SELF'];

I haven't tested in a SSL environment, but I think the complete solution is Replacing this:

Code: Select all

function __curPageURL() {
 $pageURL = 'http';
 if ($_SERVER["HTTPS"] == "on") {$pageURL .= "s";}
 $pageURL .= "://";
 if ($_SERVER["SERVER_PORT"] != "80") {
  $pageURL .= $_SERVER["SERVER_NAME"].":".$_SERVER["SERVER_PORT"].$_SERVER["REQUEST_URI"];
 } else {
    $pageURL .= $_SERVER["SERVER_NAME"].$_SERVER["REQUEST_URI"];
 }
 return $pageURL;
}

With:

Code: Select all

function __curPageURL() {
 $pageURL = 'http';
 if ($_SERVER["HTTPS"] == "on") {$pageURL .= "s";}
 $pageURL .= "://";
 if ($_SERVER["SERVER_PORT"] != "80") {
  $pageURL .= $_SERVER["SERVER_NAME"] .":".$_SERVER["SERVER_PORT"]. $_SERVER["PHP_SELF"];
 } else {
    $pageURL .= $_SERVER["SERVER_NAME"] . $_SERVER['PHP_SELF'];
 }
 return $pageURL;
}

I submitted a bug ticket here: http://dev.cmsmadesimple.org/bug/view/3021

.

[MantaPro]

Just upgraded from cmsMadeSimple version 1.3.1 to 1.5.3 and found a kind of similar problem, slightly different symptoms but the same root cause.

Post upgrade the website worked fine except every submit button on the site no longer seemed to be processed. i.e. the submit button on my contact-us just redirted to the home page, as did every over formbuilder form plus all of the front-end-user sign-ins stopped working. After reinstalling Formbuilder with no improvement, tried a more sysmatic diagnostics:

• Tried switching Captcha off to no effect.
• Swicthed off mod-rewite & pretty_URLs in config.php, no effect
• Removed .htaccess - It works - why

Traced it back to a 'mis formed' action= on all of the forms, which is created  in /lib/classes/module_support/modform.inc.php i.e. all modules that create frontend forms such as Search, FrontEndUsers, FormBuilder all suffered the same problem. for me the problems is that my hosting companies shared hosting yields $_SERVER['SERVER_NAME'] = domain.com whereas $_SERVER['HTTP_HOST'] = www.domain.com (Strangely I use a subdomain for testing which has a completely seperate install in it. in the test system $_SERVER['SERVER_NAME'] = test.domain.com and $_SERVER['HTTP_HOST'] = test.domain.com

The lack of www combined with .htaccess rules that redirect domain.com requests to www.domain.com was the combination that was causing the problem.

A few searches on google re. SERVER_NAME versus HTTP_HOST suggests that neither work 100% of the time for everybody, depends on environment config which is controlled by the hosting company

Also searches on google suggest that the  mod_rewrite in .htaccess should preserve the forms POST variables, but they didn't seem to.

Although asking the hosting company to change the server name or attempting the black-art of changing the .htaccess to force it to pass the POST variables would be the perfect or purist solution, the faster and pragmatic fix was to change the code in /lib/classes/module_support/modform.inc.php from $_SERVER['SERVER_NAME'] to use   $_SERVER['HTTP_HOST'] instead. It now works fine.

I am not going to post a bug ticket because the problem is more likely my hosting/.htaccess - but by posting to the forum hopefully anyone else suffering this problem and searching will find this.

[JohnnyB]

Dragging up this older post in case this can be helpful to someone. I have the same problem again as indicated in my first post - the search action="" URL does not include index.php. The result is search only functions on the home page.  I confirmed on two sites today and will check out others as time permits. Here is the environment:

Cms Version: 1.5.4

Installed Modules:
    * CMSMailer: 1.73.14
    * FileManager: 0.4.5
    * MenuManager: 1.5.3
    * ModuleManager: 1.2.1
    * News: 2.9.3
    * nuSOAP: 1.0.1
    * Printing: 0.2.6
    * Search: 1.5.3
    * ThemeManager: 1.1.0
    * TinyMCE: 2.4.13
    * CGExtensions: 1.15.2
    * CGSimpleSmarty: 1.4.1
    * Captcha: 0.4
    * FormBuilder: 0.5.11
    * MovedPages: 0.1
    * SiteMapMadeSimple: 1.1.4
    * Cataloger: 0.7.2
    * CompanyDirectory: 1.1.7
    * Questions: 1.0.3
Config Information:
    * php_memory_limit: 128M
    * process_whole_template: false
    * max_upload_size: 100000000
    * default_upload_permission: 664
    * assume_mod_rewrite: true
    * page_extension:
    * internal_pretty_urls: false
    * use_hierarchy: true
Php Information:
    * phpversion: 5.2.6
    * md5_function: On (True)
    * gd_version: 2
    * tempnam_function: On (True)
    * magic_quotes_runtime: Off (False)
    * memory_limit: 128M
    * max_execution_time: 90
    * safe_mode: Off (False)
    * session_save_path: /home/REMOVED/tmp/ (0755)
Server Information:
    * Server Api: cgi
    * Server Db Type: MySQL (mysql)
    * Server Db Version: 5.0.67

---------------------------------------------

Here is what I did in /public_html/lib/classes/module_support/modform.inc.php

I am using

  $pageURL .= $_SERVER["SERVER_NAME"].$_SERVER["PHP_SELF"];

instead of


  $pageURL .= $_SERVER["SERVER_NAME"].$str;

I tried using $_SERVER['HTTP_HOST'] instead of $_SERVER["SERVER_NAME"] but that didn't help because /ndex.php was not being generated in the action=""

[JohnnyB]

Using CMSMS ver 1.6 and the new search tag parameter search_method="post" solves the problem.