I am encountering the same problem.

http://www.newestindustry.org/ --> 404
http://www.newestindustry.org/index.php --> Works fine.

????

smp

HERE IS THE SOLUTION

Go to ADMIN --> Blogs --> [your default blog] --> General

In the "Blog Folder URL", where it says no trailing slash...

...ADD THE TRAILING SLASH!

:D

smp

Good one, that's working.

Thanks a lot spierzchala !

--
Arnaud

Thanks for both reporting the problem and finding and reporting the fix! When I get a download and installation going I'll see where in the files you can fix that text, and let this thread know.

I wish I could just do the upgrade, but my installations are hacked like crazy. I gotta jump through a hundred hoops just to hope that maybe upgrading doesn't break my blog. I like my hacks, but not when it's upgrade time...

BTW I'm not on the dev team and can't actually make a fix happen. I'm just a forum-junkie with a keyboard and way too much spare time...

good call, it worked for me too

I gotta wonder how this got past testing. It happened to me on a completely clean install with an existing database.

Well, I've just remarked something else.

Ok, adding a slash do solve the problem : the blogs become accessible.
But this adds an other issue : there is an extra slash in all the links, and permalinks everywhere.

Ex: http://domain.net//blogname/2005/09/15/post_title
and going back to the index give : http://domain.net//blogname.

So fixing somewhere seems to break somewhere else.
I'll try to look at this more carrefuly tomorrow.

--
Arnaud

So, you found a fix to something but it also changes other.
Is it wise to install this version yet?

I added the trailing slash and things seem to be working. I'm also reporting the double slash in links but it doesn't seem to have an adverse affect.

http://hamtramckstar.com

I also tried removing the trailing slash and instead generating a static file (index.html). That didn't work, I got a header error and a 404 error.

I've also tried using the sample .htaccess file with no luck

# this will select the default blog template to be displayed
# if the URL is just .../blogs/
<IfModule mod_dir.c>
        DirectoryIndex index.php index.html
</IfModule>

though I don't think that's the problem because my old installation's index.php loaded up just fine when just given the domain ..

I am not on the dev team, so please don't kill the messenger here - especially since I don't have a happy message ;)

I was part of a small group of people asked to look at "pre-dawn". Personally I had no problem, but I DID NOT change my default blog settings. I also did not try it with stub files, and I don't know all the feedback the dev team got from those of us who tried to do some debugging. After a fashion we got word that a bug was fixed and it was shipping.

Obviously there's another bug.

Here's the deal for me: when I tested I had bookmarks for a test installation I was using that I turned into my "pre-dawn" tester. My bookmarks included the file name, so I never saw what happened when you tried path_to_blog/ instead of path_to_blog/index.php. I just now deleted my test installation files and database, then started over with "real-dawn" and saw what people are reporting: it doesn't work without the file name on the URL. For lots of people that's bad because bookmarks and search engine indexes probably have you without index.php, so those become dead links.

I did not test further, meaning poking around the double slash issue. Since I did not add a slash in the back office I'm not seeing a double slash, but I've no doubt it's happening. I also have no clue how to fix it. I'm pretty good at hacking this app, but Dawn is as new to me as it is to you. If I can find a hack that answers ALL aspects of this bug I'll share it, but between now and then I figured I'd better let the dev team know.

I just sent the dev team an email saying "dude it's like this is like it's not workin man an' you know people are like this ain't cool an' all cuz like wow man I am in a totally negative space because you know I really wanna be like upgradin' an' all but like wow it's just wow it's like you know - awwwww". That's how people who write wicked-powerful multi-user multi-blog programs released under the GNU GPL think. They're wierd that way. I'm normal!

I encountered exactly the same as well. I found the problem and also a simple fix.

Around line 100 in blogs/b2evocore/_blog_main.php:

                // echo $path_elements[$i];
                if( isset( $path_elements[$i] ) )
                {
                        if( is_numeric( $path_elements[$i] ) )
                        { // We'll consider this to be the year

Just change it to:

                // echo $path_elements[$i];
                if( !empty( $path_elements[$i] ) )
                {
                        if( is_numeric( $path_elements[$i] ) )
                        { // We'll consider this to be the year

(Just change isset to !empty)

Why? When you enter your base URL directly, $path_elements[0] will be an empty string ''. In the old code, it's handled in a different way and you won't get the 404 problem. But in Dawn, it will get into the if() section and soon fails in

if (is_numeric($path_elements[$i]))

and you get a 404 problem. To fix this, you should skip all $path_elements[$i] that have an empty string ''. So, just change isset() to !empty(). Done! Hope that I didn't overlook any side effect.

vy wrote:

I found the problem and also a simple fix.

I was trying a mod_rewrite solution when I saw your fix. It seems to do the trick.

I suggest a b2evolution Dawn Version 0.9.1 Recall.
All that have upgraded to Dawn please bring their sites to your nearest b2evolution dealer...

I'm a big fan of b2evolution and I trust its development team but this time something was overlooked and the version went public with a defect.
My humble opinion is that there should be an urgent Dawn Update to be downloaded and re-installed instead of having to start hacking not to add a feature but just to make it work properly.

Hope this opinion doesn't offend anybody, that's not my idea.

gcasanova wrote:

something was overlooked and the version went public with a defect.

try vy's patch. it only takes a few seconds.

my site's just fine running with Dawn: http://hamtramckstar.com/

vy wrote:

... I found the problem and also a simple fix ...

Thanks vy. I love it when someone's first post is hooking up others like this.

Thanks Mr. Cherry for verifying vy's solution.

gcasanova: I'm sure your local dealer will offer a full refund ;)
Seriously: I've no doubt Francois (The Man for b2evolution) is unhappy with this bug happening, but it's like 5am in his time zone so maybe he's not even aware of the issue yet. I've seen him say things like "Are you MAD!!!" when people suggested changing something that works if the change could potentially introduce a gross bug. It's tough, ya know? I obviously like this product, but I sure don't like bugs. "Less than perfect features" isn't a bug. "It's not what I want" isn't a bug. This problem IS a bug, and an ugly one. Assuming vy is correct it's also easily squashed, but if I was a brand new user and got this dawn thing and saw this problem I'd move on.

vy wrote:

and you get a 404 problem. To fix this, you should skip all $path_elements[$i] that have an empty string ''. So, just change isset() to !empty(). Done! Hope that I didn't overlook any side effect.

This fix did not solve the problem on my site, its a new installation running on a windows server

Dexter wrote:

This fix did not solve the problem on my site, its a new installation running on a windows server

What the patch does is to simply skip the checking of $path_elements[$i] when it's an empty string. You can try to print out the value of $path_elements[$i] before the if statement and find out what happened. It would be helpful for others to look into the problem if you can provide more information such as the base URL of the blog, what URL fails to visit your blog, etc. B)

vy wrote:

Dexter wrote:

This fix did not solve the problem on my site, its a new installation running on a windows server

What the patch does is to simply skip the checking of $path_elements[$i] when it's an empty string. You can try to print out the value of $path_elements[$i] before the if statement and find out what happened. It would be helpful for others to look into the problem if you can provide more information such as the base URL of the blog, what URL fails to visit your blog, etc. B)

I moved it to a directory and it works fine, problem was only when it was in the root directory

In the root directory, none of the urls worked, not even the stubs unless it had the / added in the Blog Folder URL: setup which gave it a double //

When the slash was added there in the setup, all the urls would work with or without the double //

I have followed the instructions by "vy" and it works now. Probably should have waited till few more days (when some more problems might be found out) but was too eager to try out the new stuff. Also the annoucement said that it will improve the performance :D .

Guys, thanks for all the support and hard work you have been doing for this.

Tejaaa

Hmmm, I must be missing the problem here.

I've been running the dawn installation for almost a week and I've yet to find any errors.

Windoze server, new installation in the root folder, no amendments/hacks of the code.

Maybe I'm just lucky? :roll:

¥

Dexter, without any patch, did you encounter the 404 error ("b2evolution cannot resolve the requested URL.")? Or other error? If it's indeed 404 error, it would be helpful if you can post the URL here. The portion I've patched deals with extra path info. With the patch, you should encounter 404 error only if the extra path info is not empty AND it does not starts with a number.

http://www.vyvy.org/blogs/ => ok (but won't work without the patch as the extra path info is an empty string) http://www.vyvy.org/blogs/index.php => ok (no extra path info) http://www.vyvy.org/blogs/index.php/2005/09/15/latex2html_black_line_bug_fix => ok (has valid extra path info as the 1st element is a number) http://www.vyvy.org/blogs/index.php/what/is/this => 404 error (invalid extra path info as the 1st element is not a number)[/list:u] I installed b2evolution under a subdirectory instead of the root directory. There may be some special case with the latter setup that the patch has overlooked...

vy wrote:

I encountered exactly the same as well. I found the problem and also a simple fix.

Around line 100 in blogs/b2evocore/_blog_main.php:

                // echo $path_elements[$i];
                if( isset( $path_elements[$i] ) )
                {
                        if( is_numeric( $path_elements[$i] ) )
                        { // We'll consider this to be the year

Just change it to:

                // echo $path_elements[$i];
                if( !empty( $path_elements[$i] ) )
                {
                        if( is_numeric( $path_elements[$i] ) )
                        { // We'll consider this to be the year

Vy's fix worked like a charm for me.

Okay everyone I hear you. I am awfully sorry about this screw up which did indeed pass through the testing because 1) it doesn't fail in the default install 2) it doesn't fail on localhost 3) it doesn't fail on my site and 4) it doesn't fail on b2evolution.net ... :/

I have removed the 0.9.1 distrib from sourceforge and will post an update as soon as I have it tested on a "root" installation.

Thank you guys and especially vy for having posted workarounds that fast.

I actually had to get some sleep and take care of my day job before I could come and check back on this ;)

I'll get back here ASAP.

Okay, here is my projected solution:

_blog_main.php lines 78->88 were:

	// Check and Remove blog baseurl from ReqPath:
	$blog_baseurl = substr( $Blog->get( 'baseurl' ), strlen( $baseurlroot ) );
	if( ($pos = strpos( $ReqPath, $blog_baseurl )) !== false )
	{ // note: $pos will typically be 0
		$path_string = substr( $ReqPath, $pos+strlen( $blog_baseurl ) );
		// echo "path=$path_string <br>";
		$path_elements = explode( '/', $path_string, 20 );						// slice it
		$path_error = 0;
		$i=0;
		// echo $path_elements[$i];
		if( isset( $path_elements[$i] ) && preg_match( '#.+\.php[0-9]?#', $path_elements[$i] ) )

These lines should be replaced with:

	// Check and Remove blog baseurl from ReqPath:
	$blog_baseurl = substr( $Blog->get( 'baseurl' ), strlen( $baseurlroot ) );
	if( ($pos = strpos( $ReqPath, $blog_baseurl )) !== false )
	{ // note: $pos will typically be 0
		$path_string = substr( $ReqPath, $pos+strlen( $blog_baseurl ) );
		//echo "path=[$path_string]<br />";

		// Slice the path:
		$path_split = explode( '/', $path_string, 20 );

		// Remove empty slots:
		$path_elements = array();
		foreach( $path_split as $path_element )
		{
			if( !empty( $path_element ) )
			{
				$path_elements[] = $path_element;
			}
		}
		// echo count( $path_elements );

		$path_error = 0;
		$i=0;
		// echo $path_elements[$i];
		if( isset( $path_elements[$i] ) && preg_match( '#.+\.php[0-9]?#', $path_elements[$i] ) )

This solution is based on the same principle as vy's solution but it should handle several derivative failure scenarios all in one trick...

The center of this solution is to filter out any empty element from the extra path, which includes paths of any length ending in / as well as paths containing // sequences.

Note: You should *not* put an ending slash on your baseurl.

I am going to test this solution a little more before releasing a patched "dawn" distribution, but if you guys could confirm this does the trick for you, it would comfort me :)

Thanks for your help.

Anybody remember GD's "Touch of Grey"?

Dawn is breaking everywhere
Light a candle, curse the glare
Draw the curtains
I don't care 'cause
It's all right

I just undid vy's patch and implemented Francois' um... HACK! When I first went with dawn I saw the 404 when I had no file name and extension. Both solutions corrected this. My server says it's a Lexus no wait Linux box with PHP 4.3.11 and MySQL 4.0.25-standard, and my test installation lives in a folder.

thanks, Francois, i put in your edit and it's working fine.

i'm glad there were several fixes and semi-fixes to the problem, either way

The distribution file on SourceForge has been updated and it now includes the fix.

Thank you to all of you who have done unexpected testing on this and who have reported their concerns. I am sorry for the inconvenience and hope this new release will now live up to your expectations!

Also, it is to be expected that an upgrade from 0.9.0.12 to 0.9.1 might raise more issues than an upgrade from 0.9.0.11 to 0.9.0.12 ...

Phoenix will be something like version 1.6 and the potential for new bugs is... hum... enormous!! This is the main reason why I'm still delaying release. I am basically only doing testing and fixing until release and I want to remove as many issues as possible before telling the public to upgrade...

fplanque wrote:

The distribution file on SourceForge has been updated and it now includes the fix.

.

So if I just replace _blog_main.php file, will it do the trick? Is that what is expected.

Regards,

Tejaaa

I just wanted to say thanks to everyone for their work on this problem and quick response. ;)

EdB wrote:

Anybody remember GD's "Touch of Grey"?

Dawn is breaking everywhere
Light a candle, curse the glare
Draw the curtains
I don't care 'cause
It's all right

I remember that one ...

The shoe is on the hand that fits.
There's really nothing much to it
Whistle through your teeth and spit, cuz
It's alright

I undid vy's fix and instituted the fplanque fix. I'm reporting no problems. I grabbed the latest cvs of the new b2evo to kick around behind my firewall and I have to say that it's looking pretty fine.

http://hamtramckstar.com

Just undid my simple workaround and patched my site with fplanque's official patch. It works great! :D

I started to use b2evolution half a year ago after doing an extensive survey of the existing blog engines. I believed that it's one of the best blog engines available and I still believe that it is. B) Thanks for the great work!