how to access and use query string of URL that has been rewritten

marcnyc

I am working on a script which heavily relies on reading variables from the URL to determine what to do and what to show. In order to make it more SEO friendly I have added the following URL rewriting to an .htaccess file in the root:

RewriteEngine On

RewriteCond %{THE_REQUEST} /index\.php\?p=(?!admin)(?!superadmin)((?![^&]*?edit)[^\s&]+) [NC]

RewriteCond %{THE_REQUEST} /index\.php\?p=([^\s&]+) [NC]
RewriteRule ^ /%1? [R=301,L]

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^/]+)/?$ index.php?p=$1 [L,QSA]

This completely removes the query string from the browser's address bar, however a lot in the script does not work anymore because the variables $_GET['var'] are now empty...

is there a way I can still read the contents of the variables that are being sent in the URLs?

Thanks

laserlight

Parse the URL path in PHP.

marcnyc

what do you mean laserlight?
if I have a url that's domain.com/Home there is nothing to parse, isn't there?

laserlight

marcnyc wrote:
if I have a url that's domain.com/Home there is nothing to parse, isn't there?

You could use [man]parse_url[/man] to get the path '/Home', then parse '/Home' for 'Home' (by taking a substring and comparing, by using regex, etc), upon which you do whatever you would have done previously when $_GET['var'] == 'Home'.

marcnyc

yes but the issue is there are other variables in the query string which I don't want the user to see... my query string is stuff like p=Home&l=en&m=0 and I want the user to just see domain.com/Home and I want google to just index domain.com/Home but I still need to be able to access $GET['l'] and $GET['m'] to make my file work correctly

laserlight

marcnyc wrote:
yes but the issue is there are other variables in the query string which I don't want the user to see... my query string is stuff like p=Home&l=en&m=0 and I want the user to just see domain.com/Home and I want google to just index domain.com/Home but I still need to be able to access $GET['l'] and $GET['m'] to make my file work correctly

That is not possible. However, l=en looks like a language preference, so what you can do is to create a session and store the user's language preference as a session variable. Perhaps the same can apply for m=0.

marcnyc

unfortunately I can no do the same for m=0 as that is a value that changes for every page, unlike the language preference which stays throughout all the pages... is there any other way to do this? should I look into rewriting the URL via PHP so that I can grab my URL vars before rewriting? is that possible? is there a tutorial on that? I've never done it... any other suggestions?

laserlight

marcnyc wrote:
unfortunately I can no do the same for m=0 as that is a value that changes for every page, unlike the language preference which stays throughout all the pages...

What is this value for? You can certainly store something that changes on each page load in a session.

marcnyc wrote:
should I look into rewriting the URL via PHP so that I can grab my URL vars before rewriting? is that possible?

It can be done in the sense that you can redirect from PHP, but it is more efficient to do so at webserver level.

I believe the point of the URL rewriting is so that users who access your pages by the old URLs will see the page at the new URL rather than be turned away with a message that the page does not exist. So, you should focus on what your new clean URLs will look like, i.e., coming up with a suitable hierarchy and such, rather than blindly mapping from an old scheme to a new scheme in which the only difference is that the query string variables have been stuffed into the URL path.

Therefore, your motivation for rewriting at PHP level does not make sense: yes, you can access the query string at that point should the user access it via the old URL, but what about users who directly access your page via the new URL?

marcnyc

The way I have it right now, users can access from both the new or the old url, so that part works (ie the old urls are turned into new urls and so whether the user visits a new or an old url he always sees the new url). The issue is that with the new url I don't have access to the query string variables

laserlight

marcnyc wrote:
The issue is that with the new url I don't have access to the query string variables

Then just use query string variables. Your initial problem was that you were using a query string variable to distinguish between entirely different pages. If the page is the essentially the same regardless of what is the value of the query string variable, there's no problem.

marcnyc

indeed I AM using query strings to distinguish between different pages and the whole reason I want to move away from query string is to make the URLs SEO friendly

laserlight

Yes. So, any problems now?

marcnyc

Well I have kind of given up on the idea to be able to make urls pretty AND have a fully functional site... my design relies too much on $_GET vars and I don't wanna be recording the whole website just to make google happy

laserlight

marcnyc wrote:
Well I have kind of given up on the idea to be able to make urls pretty AND have a fully functional site... my design relies too much on $_GET vars and I don't wanna be recording the whole website just to make google happy

You can have pretty URLs AND have a fully functional site. Changing the p=Home query string name/value pair to be part of the URL path instead is a Good Thing. Saving the language preference in a session variable can be a good idea. The only thing tripping you seems to be the m=0 query string name/value pair, but since you have not stated what that means, for all we know it could legitimately be part of the query string. You do not have to completely avoid the use of the query string to be SEO friendly, and in fact trying to do so runs counter to overall good practices for the Web.

Derokorian

Its also advised against to put page number/size in the path, it should be part of the query string. IE /home/2 is bad, but /home?page=2 is good.

marcnyc

Derokorian;11042253 wrote:
Its also advised against to put page number/size in the path, it should be part of the query string. IE /home/2 is bad, but /home?page=2 is good.

I'm confused, doesn't adding the query string to a rewritten URL like that make it an UGLY and non-SEO friendly URL again???

laserlight

marcnyc wrote:
I'm confused, doesn't adding the query string to a rewritten URL like that make it an UGLY and non-SEO friendly URL again???

I'm not sure about exactly how SEO friendly it is, but I can tell you that search engines are able to handle such URLs. Ugly depends on your point of view, but the whole idea behind the query string for a GET request is to pass parameters for querying, and conceptually one can argue that requesting a particular section ("page") of a web resource involves a "query", much like a search.

Derokorian

The talk I was at that I got that from, they went on a long rant about how paginated sections of a site, tend to be ordered most recent to oldest. What this means is the content on page 1 is constantly changing as new content is added. Therefore /section/1 is not a uniquely identified page, as the content changes LOWERING your score. However, other times it makes sense to be part of the path, such as a profile page, which still points to the same resource always... IE /profile/123 vs /profile?id=123

Unfortunately, I didn't memorize all the reasoning he gave, just the suggestions 🙂

marcnyc

So you guys are saying that domain.com/Home?id=123 is still an SEO friendly address, in spite of the fact that there is a query string? was I wrong to assume that query strings in the URL automatically make it non SEO friendly?

laserlight

marcnyc wrote:
So you guys are saying that domain.com/Home?id=123 is still an SEO friendly address, in spite of the fact that there is a query string?

Possibly. I would look into why you have id=123. Does /Home?id=123 identify the same resource as /Home?id=456, except that some kind of querying operation has been applied to it? If so, then by all means go with that, e.g., /Home is a list of homes, and /Home?id=123 filters the list to show homes matching id=123. But if /Home?id=123 identifies a different resource, e.g., /Home?id=123 shows the details of the home with id=123 but /Home?id=456 shows the details of the home with id=456, then it would be better to go with /Home/123 and /Home/456.

marcnyc wrote:
was I wrong to assume that query strings in the URL automatically make it non SEO friendly?

Yes.