Recent Topics

Problem with extra path data when using absolute url

Started by on Jan 18, 2006 – Contents updated: Jan 18, 2006

Jan 18, 2006 03:04    

I'm working with the Phoenix 1.6 Alpha and appear to have discovered a bug. Here's some background and one possible fix.

Problem Description:
When my blog is setup as a traditional "relative to baseurl" stub blog everything works as expected. If I switch to an "Absolute URL" things break. e.g. My main page is always displayed even after clicking on a permalink or changing the date, in other words the extra path data is being ignored.

The Research:
This seems to stem from a problem with line 156 (1.6 Alpha NOT CVS) in _blog_main_inc.php which reads:


$blog_baseurl = substr( $Blog->get( 'siteurl' ), strlen( $baseurlroot ) );
The problem is that $baseurlroot is the incorrect thing to be getting the string length of. What we really want is the length of the absolute site url root. If I hard code my absolute site root in


$blog_baseurl = substr( $Blog->get( 'siteurl' ), strlen( '' ) );
things start working as expected (for that domain).

I have looked at the CVS versions and unless I'm mistaken this has not been fixed yet. Version 1.35 of is labeled as a bugfix but the code was just commented out which has the same effect of breaking absolute site urls.

If we are using an absolute site url ($Blog->get( 'siteurl') we really need a $siteurlroot variable so we can make the offending code


$blog_baseurl = substr( $Blog->get( 'siteurl' ), strlen( $siteurlroot ) );
which should fix the problem.

If this has already been fixed in CVS and I've overlooked it please let me know. If someone has an idea about where I can pull a $siteurlroot variable please let me know. Comments?

Jan 18, 2006 04:19

I think I've fixed this in my copy of Phoenix 1.6 Alpha though I haven't tested it thoroughly yet. Here's what I did, note this may not (probably is not) the cleanest fix for this problem but it does work.

In _blog_main_inc.php:
Comment out the if( $Blog->get( 'siteurl' ) ) section (around line 155) to force the else statement to run (this is how it is done in the current CVS version). Modify the line


$blog_baseurl = substr( $Blog->get( 'baseurl' ), strlen( $baseurlroot ) );
so that it reads


$blog_baseurl = substr( $Blog->get( 'baseurl' ), strlen( $Blog->get( 'baseurlroot' ) ) );

In _blog.class.php:
Inbetween the get case baseurl and get case basehost add:


case 'baseurlroot':
       if( preg_match( '#(https?://(.+?)(:.+?)?)/#', $this->siteurl, $matches ) )
              { // We have a specific URL for this blog:
                     return $matches[1];
       else if( preg_match( '#(https?://(.+?)(:.+?)?)/#', $baseurl, $matches ) )
              { // We have a standard blog under the /blogs/ directory
                     return $matches[1];
                     die( 'Your baseurl ('.$baseurl.') set in _config.php seems invalid. You probably missed the "http://" prefix or the trailing slash. Please correct that.' );

Any thoughts?

Jan 19, 2006 00:54

Sort of, AFAIK you wil still not get 404s for non-existant pages, though that shouldn't be extremely hard to implement. This should fix the problem of being unable to link to individual posts. Please create a link from that topic to this one as well so others can find this solution, I don't have time at the moment.

Jan 25, 2006 03:16

Any comment on this from a developer?

Jan 25, 2006 19:35

I've looked into it.

Your fix looks reasonable.

I'll commit the following to _blog.class.php:


case 'baseurlroot':
        $blog_baseurl = $this->get('baseurl');
        if( preg_match( '#(https?://(.+?)(:.+?)?)/#', $blog_baseurl, $matches ) )
          return $matches[1];
        debug_die( 'Blog::get(baseurl) - assertion failed.' );



// Check and Remove blog base URI from ReqPath:
  $blog_baseuri = substr( $Blog->get('baseurl'), strlen( $Blog->get('baseurlroot') ) );

to if further tests work out o.k.
(Note that I've renamed $blog_baseurl to $blog_baseurl because it was confusing).

I've also found some other small issues around while debugging it.

Jan 25, 2006 20:19

Thanks! With 0.9.X I was using a custom hack/stub to accomplish something similar and I'm thrilled to have the ability to do this built-in so I'll do just about anything I can do to help with this.

Jan 26, 2006 00:26

I've just seen on your blog that the "Next page/posts" links are broken. Have you hacked something there?

I can take a look at it tomorrow, but it would help if you could post your blog setup:
- "Blog folder URL" is absolute? - at ""?
- "Preferred access type"?
- "Stub name"?
- "URL blog name"?

Jan 26, 2006 00:42

You've got a better eye than me! I hardly ever use those links so I wouldn't have noticed that for a while.

Site information:
b2evo installed to:
b2evo version: 1.6 Alpha (with the mods I mentioned at the beginning of this thread)
Blog folder URL (Absolute):
Explicit reference to stub file (Advanced): bensbits.php
URL Blog Name: bensbits.php

My guess is that there is another place in the code where the site url root is being used instead of the blog url root. I think on Friday I'll upgrade from 1.6 Alpha to CVS unless you tell me there's a lot of broken stuff in CVS.

Jan 26, 2006 01:33

There's not more broken in CVS than in the Alpha I'd say. But as said elsewhere, the Plugins will get some bump tomorrow and DB tables will also get altered before the beta. If you think that's no problem to handle, go for it, but otherwise I'd just wait for the beta and apply some patches by hand.

I've taken a quick look into the code regarding the "Next >" issue and it may be working in current CVS.

Jan 26, 2006 04:37

I think I'm going to upgrade to CVS. I think I have enough database experience to avoid screwing it up too much. I know it will be a big help for bugsquashing if I'm running the latest code.

Jan 28, 2006 00:34

I have just finished upgrading from 1.6 Alpha to a snapshot of CVS as it is right now. The "Next Page/Posts" does seem to be working now.

Jan 29, 2006 11:23

No, the "Next posts" link still do not work.

I've looked at it yesterday and the root of this problem is with the base tag in the html head that links to the skin's url (which is on $baseurl) and makes the "next posts" links go to the baseurl then to (those links are relative to the domain and without the BASE tag they would stay on the subdomain).

I've added it to the bugtracker, waiting for Fran├žois to comment on it.

Form is loading...

blogtool – This forum is powered by b2evolution CMS, a complete engine for your website.