mod_rewrite directives in .htaccess

[Jonathan]

no idea half of what ya said man

1) Moving away from PHP-Nuke;
2) Want to do this, so I can use includes and the 'case' or w/e
way of loading just the text part of the page (file.php?id=filecase)
3) Make 'em all search engine friendly :P

So erhm, what do I need

[Buddha]

no idea half of what ya said man

Half the time even I'm not sure what the heck I'm talking about either.

1) Moving away from PHP-Nuke;
2) Want to do this, so I can use includes and the 'case' or w/e
way of loading just the text part of the page (file.php?id=filecase)
3) Make 'em all search engine friendly

So erhm, what do I need

PHP-Nuke uses a front controller which is why you have filenames like this "file.php?id=filecase" to begin with. When what you really want is just "file.php" and there is no reason you can't have that. All you have do is dump the front controller that is so common in CMS these day.

There are many common elements to a page. Take the front page of any CMS, they all have a list of the recent news items and maybe an announcement at the top. The article pages have the content of the article and maybe user comments. Most of the pages are made up of common functions (announcements, news, comments) which can all be stuck in a common include file for that page type. All you need in file.php is the static elements and enough information for the common functions that are being included to find the dynamic content, like the comments for that page. The CMS would write file.php, be that an article page, news page or some other type of page. Any way thats what I'm working on. Maybe you might come up with something different with your CMS.

Basically all I'm saying is... If your going to re-invent the wheel at least keep the parts that work well and dump those that don't.

Bet your still , don't worry that always preceeds semantic convergence.

[Jonathan]

Half the time even I'm not sure what the heck I'm talking about either.

PHP-Nuke uses a front controller which is why you have filenames like this "file.php?id=filecase" to begin with. When what you really want is just "file.php" and there is no reason you can't have that. All you have do is dump the front controller that is so common in CMS these day.

There are many common elements to a page. Take the front page of any CMS, they all have a list of the recent news items and maybe an announcement at the top. The article pages have the content of the article and maybe user comments. Most of the pages are made up of common functions (announcements, news, comments) which can all be stuck in a common include file for that page type. All you need in file.php is the static elements and enough information for the common functions that are being included to find the dynamic content, like the comments for that page. The CMS would write file.php, be that an article page, news page or some other type of page. Any way thats what I'm working on. Maybe you might come up with something different with your CMS.

Basically all I'm saying is... If your going to re-invent the wheel at least keep the parts that work well and dump those that don't.

Bet your still , don't worry that always preceeds semantic convergence.

Its not a CMS I'm making;
Errhm, never mind; but I'm still
thinking of using this...just gotta see
where my web design goes w/ this project 1st

[mdmcginn]

I was told to add this to my htaccess file:

<Files article>
ForceType application/x-httpd-php
</Files>

to force any file named "article" to be treated as a PHP file.

But after creating "article.php," http://www.my-site.com/article gets a 404 error. Renaming the file to "article" without the extension gets a 500 error. But http://www.my-site.com/article.php works.

Does Oz use ForceType or a RewriteRule for his search friendly URLs?

[djn]

Just because I'm in a posting mood tonight - this one works fine too:

<FilesMatch "^myfile$">
SetHandler application/x-httpd-php
</FilesMatch>

And regarding

But, could I use (and if so, how) mod rewrite
to make 'index.php?id=hosting' actually show, in the URL
as 'domain.com/hosting/' ? Basicly, for search-engine friendly URLs...

I'd suggest putting some sort of prefix in front of the url to activate the rewriting, otherwise every request will be redirected to index.php (think requests for images, css and javascript), assuming you use a sintax like '^(.*)$' (thinking again, this will redirect index.php too into itself).
Alternatively, you can either list all the options in the regex query
"RewriteRule ^(page1|page2|page3)/$ index.php?id=$1 [NC,L]"
or use a prefix
"RewriteRule ^my\.(.*)$ index.php?id=$1 [NC,L]".
I've found the later to be much easier to debug and extend...

[mdmcginn]

htaccess codes that finally worked for me

This is what worked for me.

This .htaccess line allows you to rename PHP files as HTM files instead, so you can put PHP code on the page. It treats mypage.htm as if it were mypage.php:

AddHandler application/x-httpd-php .php .htm

This .htaccess line treats mydomain.com/articles/123 as if it were mydomain.com/articles.php/123:

<FilesMatch "^articles$"> 
SetHandler application/x-httpd-php
</FilesMatch>

The file named "articles" (no period or extension) would include search-engine-friendly code that allows you to use mydomain.com/articles.php/123 (or rather, mydomain.com/articles/123) instead of the old-fashioned mydomain.com/articles.php?article=123

//Splits the URL at the slashes
$url_array=explode("/",$url);
// Gets article number 123 from the URL http://mydomain.com/articles/123
$articlenumber = $url_array[2];
//Imports article 123.txt into the webpage
include $articlenumber.'.txt';

[ilyas]

SEO friendly links worked fine in my wordpress 2.0.3 blog without any .htaccess modification.

But in my joomla 1.0.10 stable version SEO friendly links don't work. Does anyone run joomla and have a solution to that problem??

[ZYV]

You guys be careful with the includes();! I would suggest you at least to add some quick checks you can think of or your domain will be defaced the next day. Thanks Andrew php is running under your username, so probably the hacker would only deface your own page, but if he manages to upload say a flood script, the performance of the whole server will degrade significially.

1) Always put your .txt files outside of the web server tree (say /home/you/site_stuff).

2) Always check that a file that you are trying to include exists on a local FS.

3) Always check that the file is a valid one (say not /etc/passwd, but "/home/you/site_stuff/file.txt").

4) Always remove "." and ".." and "../" to deflect the directory transversal attacks.

5) Better to make a whitelist (list of valid files for your CMS to include).

6) Etc.

Please remember, that most of times the hacker is a bot or a script-kiddie, who found your website from Google to make a quick deface and have phpun. If you follow those basic advices he probably will just switch to the next site and leave you alone. And if your domain gets hacked, you may compromise the whole server (which is, of course, unlikely unless a hacker is an obsesed one, but anyway).

[mdmcginn]

Thanks ZYV! Here is a hint from php.net:

To be sure only pages are called you want the user to call, use something like this:

<?php
  $path = 'pages/';
  $extension = '.php';
 
  if ( preg_match("#^[a-z0-9_]+$#i",$page) ){
   $filename = $path.$page.$extension;
   include($filename);
  }
?>

This will only make sure only files from the directory $path are called if they have the file extension $extension.

[ilyas]

I don't know much about that .htaccess subject. But I think these last two posts are not directly about .htaccess override or SEF links in php scripts. If not, I'm sorry I couldn't understand...

Not to spoil my question in the pages of history...

Is there anyone using joomla 1.0.10 with the SEF links enabled?? I really can't understand why SEF links work in wordpress but not in joomla, in the same server...

[abvarts]

Getting 500 Internal Server Error

I just installed Dew-New PHP Links and am getting a 500 Internal server error. I'm pretty sure it has something to do with the .htaccess file, but I don't know anything about this stuff and don't know how to fix it. The only info in the .htaccess file is:

<Files directory>
ForceType application/x-httpd-php
</Files>

Can anyone help? Thanks in advance for anyone that can help me get this resolved!!!

Vicky

[djn]

This entry on theri faq (http://www.dew-code.com/modules/xoop...hp?cat_id=1#q2)
suggests to replace 'ForceType' with 'SetHandler'. Might just do the trick. I coudn't find the download link to take a look to the package itself.
BTW, reading further down the FAQ I noticed that the thing expects register_globals to be on (in late 2006!). Are you really sure you want such a script runnning on your site? I admit I'm rather uninpressed overall...

[abvarts]

Fantastico offers it

Thanks djn for replying. Thanks for the link. In regards to your question:

Are you really sure you want such a script runnning on your site?

The reason I installed Dew-New PHP Links is because it is the only link directory script offered with Dathorn's Fantastico auto-installable scripts.

I didn't realize about the register_globals. I would have thought that Dathorn would have removed any questionable scripts from Fantastico if they were concerned about their security, wouldn't they have?

Do you recommend any other reliable link directory scripts? I want to be as secure as I can be against hackers so I don't want to use Dew-New PHP Links if there is a threat that I may get hacked.

Thanks, Vicky,

[djn]

I believe Dathorn (and pretty much everybody else) includes Fantastico 'as is', with no warranty.
I can't really judge any of the scripts out there, as I usually tend to code such stuff myself and don't even know what's available, but I've downloaded a couple of ready-made scripts from Sourceforge and DMOZ to take a closer look at the code, and 'PHPMini Links' is the only one I found that explicitly filters the user supplied data:
http://www.phpmini.com/downloads/links.php.
Not much of a documentation, I'm afraid...

[ZYV]

I would recommend you to take a look at http://phplinkdirectory.com/ . Unfortunately it became a commercial tool, but the free v2 is still available, and I rememeber I contributed an addon (there should now be 3 SEF schemes in total) so SEF should be working fine here at Dathorn.