Menu

#9 SITE_URL not always set

closed-fixed
Module Bug (2)
5
2005-11-25
2005-11-19
Scott
No

For some reason, the SITE_URL variable is not always
sent to the templates, resulting in some files/links
being relative-linked instead of absolute-linked. This
causes noticable problems, for example, when you're
looking at search results. The working directory
changes from

http://site.com/blog/

to

http://site.com/blog/modules/mod_search/

and any links or images that don't have the {SITE_URL}
varibale set will result in a 404 error. Post images
and comment/trackback links seem to be okay, but things
like calendar prev/next images, the link in the blog
title header, and most importantly, the FORM ACTION=
tag to do another search point to nonexistant files.
(In fact, the search form has a hacked-up path starting
with a ./ in mod_search.php which also breaks things.)

I believe this has something to do with the code
starting at line 85 of include/xtemplate.inc.php:

// intro
$parse_intro = true;
if (isset($_SERVER['PATH_INFO'])) {
$this->assign('SITE_URL', CFG_SITE_URL);
if ($_SERVER['PATH_INFO'] != '')
$parse_intro = false;
}

On my simple Apache installation, the outer if
statement NEVER seems to evaluate true. I've noticed
that moving $this->assign('SITE_URL', CFG_SITE_URL) out
of the if statement seems to fix the problem for me,
although it's probably a complete hack that's breaking
something bigger.

Also, like I said before, the
modules/mod_search/mod_search.php file seems to need a
CFG_SITE_URL or something in there to make it work
regardless of the working dir.

Discussion

  • Scott

    Scott - 2005-11-19

    Logged In: YES
    user_id=1109254

    Actually, it seems like turning the "USE PATH INFO" option
    off in the configuration seems to fix the SITE_URL problem.
    This should probably be documented somewhere... I don't
    remember if that was on or off by default, or if I had
    stupidly set it back when I was running EasyMoblog.

    Although, the URL set in mod_search.php still doesn't seem
    to work correctly when performing a new search from a page
    of search results.

     
  • Mark Wallis (aka serialmonkey)

    Logged In: YES
    user_id=342445

    The path info variable defaults to yes and would have been retained during
    the upgrade.

    To be honest I haven't come across this parameter yet - I believe it is
    applicable with IIS compatability. What web server are you running ?

    I'm testing with Apache and find that with this set to "Yes" (the default) that
    the pages and the mod_search screens work fine. I'm hoping your not
    running Apache :-)

     
  • Nobody/Anonymous

    Logged In: NO

    Heh, hate to break it to you, but I'm running Apache 1.3.31
    on Win2000. PHP version is 4.3.10.

    All the pages work fine regardless of whether or not the
    pathinfo variable is on or off. The problem occurs when
    pathinfo is set to "yes" AND the current path is something
    other than the "site URL" parameter.

    The only module/page that I've seen that changes the path is
    mod_search, which moves away from '/moblog/' (as my site is
    set up) into '/moblog/modules/mod_search/', which breaks any
    relative links.

    Like I said, turning pathinfo off seems to fix everything
    (except for the FORM ACTION= tag, whose relative link points
    to the nonexistant
    '/moblog/modules/mod_search/modules/mod_search/search_results.php'
    when performing a new search from a search result page.

    Looking through the code (which, admittedly, I'm not too
    familiar with, although I know a lot of PHP)... I found a
    possible fix that seems to make the form work regardless of
    how I configure pathinfo. Not sure if it breaks other pages
    or server configurations (I'll keep an eye out)...

    In modules/mod_search/mod_search.php, line 4, change

    $mod_contents .= '<form
    action="./modules/mod_search/search_results.php"
    method="post">';

    to

    $mod_contents .= '<form action="' . CFG_SITE_URL .
    'modules/mod_search/search_results.php" method="post">';

    Like I said, I think it all boils down to the fact that when
    you look at the page of search results, the base URL in the
    browser changes and breaks all the relative links.

    At least, that's what it's been doing for me. ;) Hope I've
    been helpful, or at least not a total pain for you...

     
  • Scott

    Scott - 2005-11-20

    Logged In: YES
    user_id=1109254

    Sorry, that last post was from me. Not quite sure why the
    formatting got so messed up...

     
  • Mark Wallis (aka serialmonkey)

    Logged In: YES
    user_id=342445

    Very helpful mate :-) Now I seem to understand what the problem is.

    Most likely I'll release a 1.1 version mod_search that fixes this in the next 24
    hours or so.

    Thanks for your help ! :-)

     
  • Mark Wallis (aka serialmonkey)

    • labels: --> Module Bug
    • milestone: --> To_Fix_in_next_module_release
    • assigned_to: nobody --> markwallis
     
  • Mark Wallis (aka serialmonkey)

    Logged In: YES
    user_id=342445

    Okay, I can see the fix for the form action tag as you suggested, no problem
    there.

    What I can't see is the "Return to blog" link broken no matter what I have path
    info set to. It just always works for me.

     
  • Scott

    Scott - 2005-11-23

    Logged In: YES
    user_id=1109254

    I wasn't talking about the "return to blog" link... I was
    taking about the blog's title (in the H1 heading level).
    That's a link back to the main page of the blog. I need to
    start re-reading my comments before I send them. ;)

     
  • Mark Wallis (aka serialmonkey)

    Logged In: YES
    user_id=342445

    NOW I see it :-) Sorry, I'm on another planet sometimes I swear.

    Fix coming soon.

     
  • Mark Wallis (aka serialmonkey)

    • status: open --> closed-fixed
     
  • Mark Wallis (aka serialmonkey)

    Logged In: YES
    user_id=342445

    Fixed in mod_search 1.1

    I've had to remove the modules from the sidebar though for the timebeing until I
    can rethink the best way to handle these "misplaced" php pages overall. But for
    the time being everything on the search results page appears to be functioning.

     

Log in to post a comment.