I am using ajax to load pages on my website.
Each time a page is loaded I change the url in the browser to
http//www.example.com/old/page/#!/new/page/
by setting it through window.loaction using javascript
Now what I want to do is when someone comes to my website by entering the url
http//www.example.com/old/page/#!/new/page/
he should automatically get redirected to
http//www.example.com/new/page/
This is somewhat that happens on facebook too.
Can someone help me out with the required .htaccess code to achieve the same.
Thanks in advance
I don't think anything past the # symbol in your URL is even visible on the server side. So htaccess, php, etc won't even know the hash is there to begin with. I think in order to pull this off you're going to have to use a client side redirect.
window.onload = function(){
// First we use a regex to check for the #! pattern in the hash
if(window.location.hash.match(/\#\!/i)){
// If we found a match, use substring to remove the #! and do a redirect
window.location = window.location.hash.substring(2);
}
};
This example will redirect the user immediately on page load. Unfortunately doing a redirect in this manner won't help the search engines to reindex your site, but thats just one of the pitfalls of using fancy javascript or hash based URL's.
Related
I wish to create a front-end for joomla using CodeIgniter. I prefer to make my own front-end that reads joomla database and I had my own "framework" to accomplish this, this is because I feel that joomla front-end is too heavy for high traffic websites, because it needs to accommodate for so many user needs, at the end you would really only use a small percentage of what joomla has to offer, yet a lot of unneeded core modules load and when you have a website with 300k visits per day, every bit of resource counts. And I like joomla because of its back-end and database structure.
Anyway, I'm looking to standardize a framework for joomla front-end using CodeIgniter instead of my own messy php code, the main issue for me is the ci router. In joomla I set sef url like these:
websitex.com/
websitex.com/category.html
websitex.com/category/subcat/123-alias.html
I'm looking for a router override that would allow me to process those urls. Basically, if any of the params has a number, then its for sure an article. If it doesn't, and its not index.php then its for sure a category or subcategory (if it exists).
And if I write this:
websitex.com/123 [OR]
websitex.com/category/123-alias.html
It would display the article with id 123. At least that's how it works in joomla and its what I'm trying to achieve here.
If anyone could point me in the right direction that would be great. Thanks in advance.
ADDED:
OK #ImranQamer comment left me thinking. What if I try to do it with conventional CI router? So I tried, and came up with this:
$route['default_controller'] = "controller/index";
$route['index'] = "controller/index";
$route[':num'] = "controller/article";
$route['(:any)/:num'] = "controller/article";
$route['(:any)'] = "controller/section";
I think it may work. I've run some tests and so far so good.
First and second line, if nothing is specified OR index.suffix (index.html) is the URI, then it goes to my controller index method.
Third line, if URI is a number (eg: /123.html) then it routes to controller/article.
Fourth line needs more testing, but apparently it will grab any URI that ends with a number (or number + suffix) and route it to controller/article. Still needs another rule to let article's title alias to be put in the URI (eg: /category/123-hello.html)
And last line, will treat the URI as one of the categories/section of the joomla site. In this controller though, I'm going to need to check if submitted URI corresponds to an existing section, in which case it gets displayed, otherwise, redirected to 404.
I'm gonna test this out for a while, but looks good so far.
I am developing a website using Codeigniter.
i want to redirect a URL to its SEO Friendly version. for eg.
I have URL
A. http://www.example.com/post/[post-id]/
I want this URL to redirct to SEO Friendly version of itself
B. http://www.example.com/post/[post-id]/[post-title]
Just like stackoverflow is using and like redirecting A URL to B URL.
http://stackoverflow.com/questions/[question-id]/[question-title]
I was using 302 redirection in the Codeigniter until i read somewhere that if you are using 302 redirection.
then google might treat you as a Spammer but then again when i saw Stackoverflow URL Pattern then i think its much better to have B version of URL.
So my Questions are:
1. Which redirection stackoverflow is using?
2. Is it better to Store the Slug for [post-title] in database or manually calculate it with url_title() function.
302 means a temporary redirect. The result is search engines will still index the original URL.
301 mean permanent redirect. This results in the search engines transferring index data to the new URL.
302s are not spam but if used in the wrong situation you don't helping yourself.
In your case you will be permanently moving your URLs so a 301 is appropriate.
create a private function in the posts controller for SEO friendly URLs for posts.
private function _redirect($url) { // $url = http://www.example.com/post/[post-id]/
redirect($url . $this->post_title); // becomes http://www.example.com/post/[post-id]/[post-title]
return;
}
You should have a post_title member variable set before redirection. Where ever you are calling a redirect() function, replace it with your private function _redirect() and you are good to go.
by default its 302 redirect. To do a 301 redirect just add parameter to the redirect() function. e.g
// with 301 redirect
redirect($url . $this->post_title, 'location', 301);
Note: In order for this function to work it must be used before anything is outputted to the browser since it utilizes server headers.
man, I am stumped, and you probably won’t be able to help, but perhaps if I talk it through here:
This is a CodeIgniter custom CMS.
I am troubleshooting a custom cms someone else wrote; specifically, one of the payment gateways (HSBC - similar type library as PayPal or the like, but using Curl )
It has a callback function from the bank’s site, returning a set of $_POST variables.
PROBLEM: The $_POST variable are not accessible from app’s controller (I can see them returned by using httpFox)
I CAN:
1) return to a non-app .php page and print_r($_POST) (i.e., callback url is just another page on my server, outside of CI)
2) post a Form from within or outside the app to the suspect controller, and print_r($_POST) with no trouble (i.e., this controller/app CAN receive a normal post)
So, trying to read the $_POST results from the callback itself is what is failing.
Any ideas on what to check, or how to track this? It’s obviously some setting somewhere, perhaps with Curl, but I’m at a loss. Happy to post code/more info once I figure out what direction to go in
TIA,
jeff
Getting POST variables in CodeIgniter is acheived through the input class.
The documentation states that all the superglobal variables are destroyed.
Getting the content of $_POST['something'] should then be done by:
$something = $this->input->post('something');
ok, a little closer observation final tracked it down:
the previous developer had the .htaccess to first add a trailing slash, then remove the .index.php?
it seems the callback was being routed to itself and as part of the process (along with some config settings, maybe) was losing the post vars. not sure if that's a precise description, but it was routing twice through the system
thanks
We understand the hash is for AJAX searches, but the exclamation mark? Anyone know?
Also, the "action" attribute for their search form points to "/search," but when you conduct a search, the hash exclamation mark appears in the URL. Are they simply redirecting from "/search" to "/#!/search"?
Note: the second part of the q remains unanswered: That is, are they redirecting the user from "/search" to "/#!/search", or do they send the user to "/search" and use JS on the page to rewrite the URL? – Crashalot Jan 26 at 23:51
Thanks!
It's become the de facto standard that Google has established to ensure consistency and make ajax urls crawlable.
See http://code.google.com/web/ajaxcrawling/docs/getting-started.html
I believe they are using history.pushState. You can do history.back() in the console and it'll lead you back to the page.
Yes, it redirects with HTTP 302.
By the way, "!" is used to eliminate the case with an empty hash. "http://url#" will make a browser to slide to the top.
To answer the second part then: It is redirecting you to /#!/search.
If you look at the response headers when going to http://twitter.com/britishdev (plug plug) you are returned a 302 (temporary redirect) with the Location header set as "Location: http://twitter.com/#!/britishdev"
Yes JavaScript is then pulling all your detail in on the destination page but regardless that is where you are redirected to.
I have read a lot about URL rewriting but I still don't get it.
I understand that a URL like
http://www.example.com/Blog/Posts.php?Year=2006&Month=12&Day=19
can be replaced with a friendlier one like
http://www.example.com/Blog/2006/12/19/
and the server code can remain unchanged because there is some filter which transforms the new URL and sends it to the old, but does it replace the URLs in the HTML of the response too?
If the server code remains unchanged then it is possible that in my returned HTML code I have links like:
http://www.example.com/Blog/Posts.php?Year=2006&Month=12&Day=20
http://www.example.com/Blog/Posts.php?Year=2006&Month=12&Day=21
http://www.example.com/Blog/Posts.php?Year=2006&Month=12&Day=22
This defeats the purpose of having the nice URLs if in my page I still have the old ones.
Does URL rewriting (with a filter or something) also replace this content in the HTML?
Put another way... do the rewrite rules apply for the incoming request as well as the HTML content of the response?
Thank you!
The URL rewriter simply takes the incoming URL and if it matches a certain pattern it converts it to a URL that the server understands (assuming your rewrite rules are correct).
It does mean that a specific resource can be accessed multiple ways, but this does not "defeat the point", as the point is to have nice looking URLs, which you still do.
They do not rewrite the outgoing content, only the incoming URL.