I fooled around with this as well.

Donald, I second this request. Needing the main php file in the URL is easily changed. I'd recommend this get changed throughout the code before FB3 goes final.

Archives could now be http://yoururl/archives
Post would be http://yoururl/post
Etc...

Moving to this format, instead of later, will be good so all of us don't need to keep modifying our templates. :)

This is relativley easy to do with Apache and PHP.
Ex: http://tinyurl.com/cpxys

Also, it looks like the IIS folks have ways of doing it:
http://tinyurl.com/cyw9c

Maybe insert some code so FB3 checks to see which server it's on and calls the appropriate routine appropriately?

-z

p.s.
If you open-sourced FB3, we could probably have this done before you get back. :)

The demo blog uses the following .htaccess:

# Start folderblog redirecting 
Options +FollowSymlinks 
RewriteEngine On 
RewriteCond %{REQUEST_FILENAME} -d 
RewriteCond %{REQUEST_URI} !/$ 
RewriteRule ^.*$ %{REQUEST_URI}/ [R,L] 
RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d [OR] 
RewriteCond %{REQUEST_FILENAME} /preview$ 
RewriteRule ^(.*)$ fb.php?p=$1 
#End

where /preview is the directory of your folderblog and fb.php is your folderblog filename.

According to Zach's second link, the mod_rewrite method is server-resource intensive, so I took a couple minutes to put together a method that uses a 404 page:

# Start folderblog redirecting 
ErrorDocument 404 /preview/index.php 
# End

for your .htaccess and an index.php file that contains

<?php 
header("HTTP/1.1 200 OK"); 
header("Status: 200", TRUE, 200); 
$_GET["p"] = str_replace("/preview/","",urldecode($_SERVER["REQUEST_URI"])); 
include("fb.php"); 
?>

This method will fill up your error_log rather quick, but is otherwise a good way to do it — it's actually the way I do rewriting on the folderblog main site.

Both of those methods require $use_alt_url set to 1.

Zach, I hesitate to include a clean URL redirection method in the default package because it'd require a .htaccess — and I don't want anyone accidentally overwriting an existing .htaccess.

It's pretty easy functionality to add, though (see above), and you don't need to touch the fb.php source — I'll be sure to add the instructions when I write the documentation and maybe even post a zip with the files.

Maybe the urls don't have the query string in it anymore, but I think the urls of FB2 were much more simple. Any way we can revert back to that but still keep the other new features of FB3?

You like the query string URLs? Really?

Unfortunately, there's no way to swtich back without a ton of coding in fb.php. fb3 will accept folderblog 2 style URLs with no problem, but there are so many places where URLs are being written that it would just be a major overhaul to swap them all back to query-string style URLs.

What don't you like about fb3's URLs? Too long? I welcome any suggestions.

Useful info here. Glad I was able to find it through Google

Well, finally managed to use the info here to make things work for me. Now using clean URIs sans any index.php or fb.php or ?p= in the displayed URI

The Holy Grail of Clean URIs, used even with the restrictions of php as cgi module:

 
RewriteEngine On 
RewriteCond %{REQUEST_URI} /$ 
RewriteRule ^(.*)$ index.php?p=$1 

the above should go into the .htaccess of the folder you use for fb.
$use_alt_url should be set to 1 or true in your settings.
This does make the server work, and would perhaps cause a scare for heavy traffic. But does it make much difference from evolt's method? - http://tinyurl.com/cpxys

My next trick will be to try copying the method from evolt -- instead of putting folderblog in a directory named fb, I drop the file extension off fb.php and make it fb [or whatever else I like] on my web server root folder and then ForceType it to be parsed by php to mimic a folder. Then I'd need to store all other folderblog files in a different directory name because the point here is to reduce the number of server requests that require the server to handle.

Anyone trying to achieve clean URLs should understand that.

To keep the clutter of fb's files off the web server root directory, I'll have to find a way to alter fb.php to look for all it's parts in another directory, leaving the http://myserver.com/fb/image/jpgfilename/ request to the server be the only request that needs to be processed by apache or php.

As it is with my mod_rewrite solution above, every file, from the css files to the php files and the images would undergo a rewrite process in the request to apache because they are all affected by the directory .htaccess command.

I'll let you know when I get this developed further and would be glad to hear of any other attempts at this.

discovered a bug in fb.php that causes a failure with the simple method to clean urls I offered above and it happens where you click on the pages of the archives. They are missing a trailing slash.

Original code:

 
$i 

Modified code:

 
$i 

It's about the 30th last line from the bottom. Try a text search on the file. The only change is to add a slash after $i

Bah. See if this works:
Original code:

 
a href=\"" . linkPrefix() . "archives/$i\">$i 

Modified code:

 
a href=\"" . linkPrefix() . "archives/$i/\">$i 

Do you want me to include this change into next fb?

related question: when i visit a URL that includes a category and is obviously wrong, i still get re-directed to my main category website, for example: http://therohan.com/index.php/people/iambad/

how do i make it generate a file not found error in such a case?

re: ikue
yes, I think that line of code is an error and should be fixed

re:rohan
The reason is that although they may look like folders after index.php, they are really just URL rewrites of variables. There is no file not found error because the file is index.php in any case so if it doesn't understand the variables, it displays the main page. It would be possible I think to set fb to display an error screen if it is passed categories it doesn't understand.

It has thrown me off a number of times too when fb does not understand the variables passed yet displays the main page, fooling me.

to clarify: when I say it would be possible, I mean one could recode the script to handle this.

it fools search engines too which caches pages that do not exist but google thinks they do because the main page shows.

i have the same problem with images that google cached when i was using fb2 that had a different URL system. when those old dead links are accessed the main page shows, this should perhaps be changed to show a file not found?

any suggestions about how to change this?

I also agree that it should be possible including such a function, yes. I will see what I can do tomorrow, and tell you guys about the results.

if you're concerned about search engines properly indexing your site, you not only would want to display a message that an error has occurred, but you would want PHP to return a 404 in the headers.

On another note in this thread, have others tested my 'Holy Grail of Clean URIs' above? I'm curious how well it works for others. I haven't had time yet to sit down and crack the other method yet, but it's in the works.

Okay I succeeded in integrating an error 404 option into new fb ikue release 1.7, see the appropriate post in this forum. You are free to copy out the lines of code to enhance to "old" fb, but make sure you dont miss the relevant changes. Do a text search on "404" in the new fb.php.

...