HOW-TO: use mod_rewrite to get rid of index.php in the url

[aronchi]

I have one journal and I want to make it on the first page, with http://www.mydomain.org
url
I want to make administrative and other things available with /admin or another sub url.

Is it possible?

[asmecher]

Hi Alessandro,

Rearranging OJS's URLs could get quite complicated. The above discussion removes the usual index.php from OJS's regular URLs, but beyond that you'll need to get your hands dirty.

If it's important enough to warrant implementation and you have some PHP and mod_rewrite experience on hand, I can broadly describe the changes you'll need to make.

Regards,
Alec Smecher
Open Journal Systems Team
---
Don't miss the First International PKP Scholarly Publishing Conference
July 11 - 13, 2007, Vancouver, BC, Canada
http://ocs.sfu.ca/pkp2007/

[ozp]

here is a .htaccess that did the job for me

Code: Select all

#pkp rewrites
DirectoryIndex index.html  index.php
RewriteBase   /
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule  ^(.*)$ /index.php/$1
#pkp admin fix
RewriteRule inicio/admin/(.*) /index.php/index/admin/$1


the admin fix was because in PT_BR locale there is some king of problem with index and inicio (inicio means index)

[istoyanov]

I suppose that my case isn't that complicated, but I can't get the mentioned mod_rewrite rules to work.

I would like to get the following:

Code: Select all

http://MYDOMAIN/ojs/index.php/NEWJOURNAL -- > http://MYDOMAIN/ojs/NEWJOURNAL

In the above scheme "ojs" is the location where OJS is installed.

In config.inc.php I have set

Code: Select all

base_url = "http://MYDOMAIN/ojs"
...
base_url[index] = http://MYDOMAIN/ojs
base_url[NEWJOURNAL] = http://MYDOMAIN/ojs/NEWJOURNAL


and in the .htaccess file I have

Code: Select all

Options +FollowSymLinks
RewriteEngine On
RewriteBase /ojs
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]


As a result, when visiting http://MYDOMAIN/ojs, the URLs are rendered as expected, but all the links are broken -- i.e. nothing changes when I follow any of them, except links that point one or more levels below http://MYDOMAIN/ojs/NEWJOURNAL (such as http://MYDOMAIN/ojs/NEWJOURNAL/issue/current or http://MYDOMAIN/ojs/NEWJOURNAL/user/register). In the latter case, the http://MYDOMAIN/ojs page displays again, but without any influence from the CSS.

I'd appreciate any further hints on how to accomplish the desired result.
Cheers!!!

[robinhood1362]

Thanks for the great Journal CMS, and another thanks for the invaluable support!
I have my CMS (Drupal 6.2) running on http://sub.domain.com and I need to have OSJ running for just one journal on this site as well. I also want to be able to direct to myonlyjournal (using OJS 2.2) using the url http://sub.domain.com/myonlyjournal. It would be nice if the urls of the journal such as the about page and current issue etc. looked like this: http://sub.domain.com/myonlyjournal/about , http://sub.domain.com/myonlyjournal/issue/current without the "index.php". I guess I have to put OJS in a folder other than webroot (since Drupal is in webroot) say "/path", but then the urls of the journal would be like http://sub.domain.com/path/index.php/myonlyjournal which is undesirable.
Is it possible to apply the described makeover to my site?

[makemywish]

Hi Guys

My Apache version is 2.0.63/PHP 5.2.5 and I have the following in my htaccess

Code: Select all

# Turn Rewrite Engine on
RewriteEngine On

# Set the base for relative paths
RewriteBase /

# Check for www and remove
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

# Do not enable rewriting for files that exist
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

# Remove index.php
RewriteRule ^(.*)$ index.php [PT,L]

IndexIgnore .htaccess */.??* *~ *# */HEADER* */README* */_vti*

<Limit GET POST>
order deny,allow
deny from all
allow from all
</Limit>
<Limit PUT DELETE>
order deny,allow
deny from all
</Limit>
AuthName domain.org
AuthUserFile /home/wide02/public_html/_vti_pvt/service.pwd
AuthGroupFile /home/wide02/public_html/_vti_pvt/service.grp

The stripping of index.php doesn't work. Any suggestions?

[mj]

Hi all,

Just to provide some more support on this issue, it's worth noting that the directives in .htaccess are relative to location of the site root; that is, the values for .htaccess will differ depending on whether your OJS installation is in the site root or not. For an example of my local setup, my ojs installation is located at http://localhost/ojs/ ; my .htaccess file is located in the ojs root directory (same place as config.inc.php) and looks like this:

Code: Select all

<IfModule mod_rewrite.c>
   RewriteEngine on
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteRule ^(.*)$ index.php/$1 [QSA,L]
</IfModule>

Please note that this will not change URLs as they are generated within OJS, ie. links in OJS will still contain index.php. If you want to change that, you will have to modify the code directly in Request.inc.php (or PKPRequest.inc.php for newer versions) to change:

Code: Select all

define('INDEX_SCRIPTNAME', 'index.php');


to:

Code: Select all

define('INDEX_SCRIPTNAME', '.');


Although I wouldn't recommend this modification, it may be helpful for those of you who are looking to do this.

MJ

[matthew_ellis24]

I'm confused which of these are meant to work? All I want to do is to make it so that
http://www.jicr.carabusonline.co.uk/ind ... jirc/index
can be accessed directly at
http://www.jicr.carabusonline.co.uk/
as there only be one journal and the extra screens and extra stuff in the URL are a waste of time and ugly. None of the above really seem to work so I'm now rather confused!

[mj]

Hi Matthew,

The approach I describe in my post above should allow you to remove the index.php part of the URL, which should get your URLs down to, eg. http://www.jicr.carabusonline.co.uk/jirc/about (for the about page). If you still want to remove the "/jirc" part, you'll have to do something like replace:

Code: Select all

RewriteRule ^(.*)$ index.php/$1 [QSA,L]

with:

Code: Select all

RewriteRule ^(.*)$ index.php/jirc/$1 [QSA,L]

This should get your URLs down to, eg. http://www.jicr.carabusonline.co.uk/about (for the about page), and so on. Note that the home page still requires a name according to RESTful practices, so http://www.jicr.carabusonline.co.uk/index will always be a valid URL. Also, bear in mind that mod_rewrite is a bit of a black art, since it can vary substantially depending on the server configuration, Apache version, and so on. The less rules, the easier to troubleshoot, and what may work for one person may need to be modified to work for another. I'd suggest taking it slow and reading the mod_rewrite documentation for your particular version of Apache.

Hope this helps,
MJ

[matthew_ellis24]

Hi there, I'll give that a go thanks. I must admit I'm a little confused why it's structured the way it is anyway, presumably it's some kind of legacy from the way it's been developed. It's a shame as the package is fantastically easy and intuitive to use, but it's hideously ugly and takes some serious work to make it look any better.

I didn't realise mod_rewrite was so temperamental. It obviously works on my server as clean urls works perfectly on drupal, but I guess it just takes some gentle caressing to ease it into shape!

[mj]

Hi Matthew,

One of the reasons why OJS still generates "ugly" URLs by default is that, unlike other software like Drupal, a large contingent of our user base is still running on rather old versions of PHP, Apache, and so on. So, while it would be easy to require, say Apache 2.x with PHP5.x and mod_rewrite to run OJS -- in which case we could do better things with URL rewriting and so on -- if we did that we would be shutting out countless of the most critical producers of open access material (some of the smaller African community journals come to mind, for example). Our approach has been to support the largest breadth of technology possible, which often means that some configuration is required for certain features. OJS 2.3 will support enabling RESTful URLs by default (ie. removing index.php) with a small configuration setting.

As for the package being "hideously ugly", I'll say thanks for the feedback, and mention that we are just beginning to undertake a *major* (and in the collective mind of the PKP team, long overdue) overhaul of the user interface for the entire PKP suite, both to make it more visually appealing as well as more intuitive and user-friendly, and a more configurable templating system to make customization easier. Again, this will have to incorporate a balance of modern features and compatibility with older systems, but we are working extremely hard with our limited resources to provide software that is accessible to as many people as possible, across a multitude of platforms and at minimal cost.

Good luck with your mod_rewrite work -- it definitely responds well to a gentle touch and systematic, one-at-a-time changes.

MJ

[matthew_ellis24]

Hi sorry, I didn't mean to be quite so critical I really like this software as the workflow is just so intuitive and useful, and I think your mission is highly admirable. Being a UK user I guess it's easy to forget that there is a broader spectrum of hosting solutions across the world then we're aware of

I look forward to the updates!Do you mean by user interface overhaul that you'll be doing away with different screens for all the editors/managers/readers etc? That would be great.

Thanks for your help. Fingers crossed for a happy ending
Matt

[mj]

Hi Matt,

No worries, positive criticism is welcomed, and your annoyance with the current appearance of OJS is one that's shared by the PKP team in general, and undoubtedly many others. We're still at the very early stages of determining what the UI overhaul will entail, so unfortunately I can't say at this point how it will affect / be affected by the user roles. Definitely one of the main tenets will be to make the UI less confusing for multi-role users, and to make it more intuitive in line with the workflow. Of course, I'm sure the new UI changes will receive their own criticism and commentary, but that kind of user engagement is exactly what Open Source and PKP are all about.

Cheers,
MJ

[matthew_ellis24]

sadly I'm having no luck with mod_rewrite, probably born more from my ignorance of its inner working than anything else.

[msaghaei]

Common pitfalls regarding mod_rewrite usage
An extract from the Rich Bowen's book The Definitive Guide to Apache mod_rewrite

Whether mod_rewrite is installed by default in an Apache installation, vary from system to system. Even if it is installed it may not be ON by default. Using per-directory rewrite also needs activation of .htaccess files, which usually is not enabled by default. Therefore the problem may be all or some of the followings:

Installion of mod_rewrite
Enabling mod_rewrite
Enabling .htaccess files

You may perform some diagnostics to find out on which of the above levels your rewrite problem is. Create a directory in your website for these experiment and name it something (e.g. test_rewrite). In that folder create an index.html file which contains some sample texts ("Hello Rewrite" for example). Test whether it loads correctly by pointing your browser to the address of index.html file (e.g. http://www.yourdomain.com/test_rewrite/index.html).

Then create an .htaccess file (name it exactly .htaccess, with a preceding dot).
Open the .htaccess file and place a two words phrase in it (anything you like except standard rewrite commands, e.g. "MyQuitePossibleDirective RightNow", without quotes of course).

Then refresh your browser to reload the index.html page. If you received an error, something that probably says "Internal Server Error" or anything similar to it you're lucky!!
If the page reloaded without any problem or error, it means that apache does not parse your .htaccess file. This may be due to either mod_rewrite is not installed, is not enabled, or the .htaccess file is not enabled. If you're sure that mod_rewrite is installed and enabled on your server, contact your server admin to enable the .htaccess file. If she do not know how to do that you may tell her to change the line in apache config file which read
AllowOverride None
to
AllowOverride All
or at least to
AllowOverride FileInfo

After assuring the .htaccess file is enabled on your system, if you like to check whether mod_rewrite is installed on your server, edit your .htaccess file again and change the invalid entry (MyQuitePossibleDirective RightNow) to the following:
RewriteEngine On
and then reload your index.html page in the browser. This time if you got no error response and everything was OK, this means that mod_rewrite is installed and enabled. But if you received the same error again (Internal Server Error), two situation are possible:
1. mod_rewrite is not installed
2. mod_rewrite is installed but not enabled or you do not permitted to use it.

Checking your server error log (if you can access it) and searching for word 'rewrite" may help. Something like "Rewrite not allowed" may denote the second type of problem. Again this is related to the level of AllowOverride directive in apache config file.

In the error log if you found something like "Invalid command 'RewriteEngine'" it means that mod_rewrite is not installed.