Serendipity with relative paths

[b33blebr0x]

Hi there!

I found a way to use Serendipity having only relative link paths in the source code. How about incorporating this patch into the next version? To me, this would be a great help, since relative paths are required for a service that uses my serendipity application. I tested this patch with Serendipity 0.8.2.

The first thing you have to do is to delete the 'Relative path' $serendipity['baseURL'] and the 'URL to blog' $serendipity['serendipityHTTPPath'] in the Serendipity Administration Suite under Configuration --> Paths. Simply delete all characters in the input fields and click 'Check & save'.

All right, this is not everything. The first problem is the patch in line 224 in serendipity_config.inc.php which says:

Code: Select all

// Try to fix some path settings. It seems common users have this setting wrong
// when s9y is installed into the root directory, especially 0.7.1 upgrade users.
if (empty($serendipity['serendipityHTTPPath'])) {
    $serendipity['serendipityHTTPPath'] = '/';
}

It creates a slash in front of the HTTPPath (it is empty now), which is nonsense if you want to have relative paths. Just remove these lines or comment them out.

Code: Select all

// Try to fix some path settings. It seems common users have this setting wrong
// when s9y is installed into the root directory, especially 0.7.1 upgrade users.
/*if (empty($serendipity['serendipityHTTPPath'])) {
    $serendipity['serendipityHTTPPath'] = '/';
}*/

The next problem pops up when using the calendar. Serendipity does not find any entries when clicking on a month or on a day. The problem results from the url parsing method serendipity_getUriArguments() that can be found in /include/functions.inc.php. When using relative paths, the regular expression in serendipity_getUriArguments() produces unwanted results. Altering the function from

Code: Select all

function serendipity_getUriArguments($uri, $wildcard = false) {
global $serendipity;
    /* Explode the path into sections, to later be able to check for arguments and add our own */
    preg_match('/^'. preg_quote($serendipity['serendipityHTTPPath'], '/') . '(' . preg_quote($serendipity['indexFile'], '/') . '\?\/)?(' . ($wildcard ? '.+' : '[a-z0-9\-*\/%\+]+') . ')/i', $uri, $_res);
    if (strlen($_res[2]) != 0) {
        $args = explode('/', $_res[2]);
        if ($args[0] == 'index') {
            unset($args[0]);
        }
        return $args;
    } else {
        return array();
    }
}

to

Code: Select all

function serendipity_getUriArguments($uri, $wildcard = false) {
global $serendipity;
    /* Explode the path into sections, to later be able to check for arguments and add our own */
    preg_match('/'. preg_quote($serendipity['serendipityHTTPPath'], '/') . '(' . preg_quote($serendipity['indexFile'], '/') . '\?)\/?(' . ($wildcard ? '.+' : '[a-z0-9\-*\/%\+]+') . ')/i', $uri, $_res);
    if (strlen($_res[2]) != 0) {
        $args = explode('/', $_res[2]);
        return $args;
    } else {
        return array();
    }
}

solves this problem and more. The if-clause that deletes the first value 'index' from the result-set is obsolete due to the modified regexp-pattern.

Still, we are not finished yet. There is still an error message raised by serendipity_track_referrer() which can be found in /include/functions.inc.php as well. Right at the beginning, the function checks, wether the client comes from this website or from another one:

Code: Select all

        if (stristr($_SERVER['HTTP_REFERER'], $serendipity['baseURL']) !== false) {
            return;
        }

Using $serendipity['baseURL'] as a parameter for stristr() raises an error, because it is an empty string. Thus, the function is aborted here doing nothing. The standard php function parse_url() does the same job here:

Code: Select all

        $url = parse_url($_SERVER['REQUEST_URI']);
        if (stristr($_SERVER['HTTP_REFERER'], $url['path']) !== false) {
            return;
        }

[garvinhicking]

This patch is sadly only halfway thought through. There are many many more places that *require* an absolute URL to be present so that s9y works correctly.

I'm sorry that we cannot include the patch in the current form as it raises too much problems on many related issues. A good reason are RSS Feeds: Those need to contain an absolute HTTP path to properly validate as RSS.

You will need to grep through all plugins and all core files for "baseURL" and "serendipityHTTPPath", there are many many more occasions which can create trouble. If you want to take on that surely massive job, a patch would be appreciated in a unified diff format so that I can verify it.

But such a patch can only be included for the next Serendipity 1.0 version; version 0.9 is near to be finished and such a change would massively influence the whole codebase and could possibly create trouble and thus needs to be tested on a new release cycle.

Many thanks for getting involved with Serendipity,
Garvin

[b33blebr0x]

Hi!

Thanks for your appreciation. Sure, this was just a rough hack. I will try to implement this in the current version and submit all changes to you.