I have a Magento 1.7.0.2 installation and noticed the URL rewrites have been increasing recently.
For example:
Request path: product-27x27-4804.html
Target path : product-27x27-4805.html
All the new rewrites are custom ones and what I've noticed the count increases upon reindex.
These new rewrites are not valid and are basically junk I need to clean safely but at the same time make them stop from appearing again.
Any idea? Thanks!
There are two parts to this:
cleaning up the large URL rewrite table which will slow down your reindexes.
PLEASE BACKUP FIRST!
DELETE FROM core_url_rewrite WHERE category_id IS NOT NULL AND product_id IS NOT NULL;
patching magento to prevent the issue from occurring again. See link below for this, but DON'T follow the part that suggests you should truncate the whole core_url_rewrite table. That will remove all of your custom URL rewrites as well as the system.
https://magento.stackexchange.com/questions/17553/magento-core-url-rewrite-table-excessively-large
Related
I guess, this is an easy one but anyway, I haven't figured it out yet.
After migrating my website from Joomla 3 to Joomla 4 the structure of categories and articles will change. That's why I will need some rules in .htaccess to redirect the old urls to the new ones.
The website is hosted on an Apache server.
The old URL structure looks something like that.
https://www.mydomain.de/category/subcategory/item/[articleID]-[articleAlias].html
[articleID] is a digit.
[articleAlias], e.g. „this-is-article-number-233“
This should be redirected to...
https://www.mydomain.de/newcategory/newsubcategory/[articleAlias].html
An example:
https://www.mydomain.de/category/subcategory/item/2324-this-is-my-latest-article.html
… should be redirected to...
https://www.mydomain.de/newcategory/newsubcategory/this-is-my-latest-article.html
I've played around with RedirectMatch and Rewrite Rule but haven't been successful to make it work. How do I get rid of the article id?
My latest try failed with...
RedirectMatch ^category/subcategory/item/([0-9]+)-(.*)$ /newcategory/newsubcategory/$1
Is there a simple and elegant solution to this? Thanks in advance!
UPDATE
Maybe it's more complex than I thought it was.
Main problem is that not only my categories changed but also the ids of the articles.
So, to stick with my example...
https://www.mydomain.de/category/subcategory/item/2324-this-is-my-latest-article.html
first turns into something like:
https://www.mydomain.de/newcategory/newsubcategory/1223-this-is-my-latest-article.html
Anyway, Joomla 4 is able to drop the article id automatically (guess with an internal rewrite) for seo-friendly URLs. I activated that feature to make the new URLs look like
https://www.mydomain.de/newcategory/newsubcategory/[articleAlias].html
The [articleAlias] stays the same.
A redirection according to what you actually ask should be possible like that:
RewriteEngine on
RedirectRule ^/?category/subcategory/item/[0-9]+-(.*)\.html$ /newcategory/newsubcategory/$1.html [R,L]
However I doubt that this really is what you want: this completely drops the numeric ID of the resource. Which means that it won't be available for processing when the redirected request comes back requesting the new, stripped URL. How do you want to internally rewrite that request back to the internal resource then, without that ID?
I made some more tests and it this is the final solution to my problem:
RedirectMatch 301 ^/?category/subcategory/item/[0-9]+-(.*)\.html$ /newcategory/newsubcategory/$1.html
I have a magento site where I am redirecting some urls to new urls in htaccess
olds urls is like this domain.com/dinnerware-24.html and its number is From 1 to 99 and it is dynamic
now i want create pattern if my url have number, delete it automaticly and redirect to new url e.g
domain.com/dinnerware-25?q=1 or domain.com/dinnerware-99.html
redirect to domain.com/dinnerware?q=1 and domain.com/dinnerware.html
This happens if you have duplicate url's. In some older Magento versions this behaviour is also buggy and leads to urls with new increments after each reindex.
A solution would be to delete values of "url_path" attribute from catalog_product_entity_varchar table, truncate core_url_rewrite table and do a fresh reindex
You may consider to manually add some unique suffixes to your products or categories "name" or "url_key" attribute, to avoid this behaviour in the first place.
There is also a downside of deleting old redirects. From SEO point of view you may lose linkjuice that was distributed from old urls
One of our clients is launching a campaign around our city and one of the requirements they want is to track from what item a visitor has scanned in a QR code. To achieve this I have entered this into my .htaccess file:
RewriteRule ^(beermat|poster|flyer)$ /video?utm_source=$1&utm_medium=PrintedMaterial&utm_campaign=VideoCampaign2012 [R=301]
So if anyone scans in the QR code that has the address: http://www.website.com/beermat it redirects to /video with the relevant attributes.
If I have the google analytics code on the /video page this should work, correct?
Try this plugin to see if google-analytics is recording anything.
This way you can see directly if it is working or not.
https://chrome.google.com/webstore/detail/jnkmfdileelhofjcijamephohjechhna
I think it would be better for you to make "poster" a directory, and the index.php inside it should set $_SESSION['found']="poster" then redirect to the main page which would read from the SESSION.
The added benefit is that you're not left with any ugly GET data, just a nice clean url, but the downside is that you have to manually create the directories, so only do this if you have a manageable amount.
I'm redeveloping a site (replacing it with one based on CodeIgniter), which is currently a horrid mess of repeated procedural code, however, it has good search engine rankings. Because of this, I need to keep the exact same URL structure.
The company has many different quote pages, which are all essentially the same - so I've produced one clean version which can be used everywhere.
The quote system is now in a folder called /get-quote, but due to the old URLs being required, that folder mustn't be visible anywhere.
I'd like the following to happen, but don't know how to:
A user accessing /insurancequote.php should (on the server) load the /get-quote/ directory (which in turn will load the default CI route). The Base URL in CI should be http://www.mysite.com/insurancequote.php (I'm able to do that bit), so moving to step 2 would result in: http://www.mysite.com/insurancequote.php/step2 (which would map to /get-quote/step2).
Secondly, a user accessing /brokerquote.php should show mysite.com/broker in the address bar (redirect?), but on the server access /get-quote/broker.
Thirdly, a user accessing one of many broker-specific pages, e.g. mysite.com/brokername1.php or mysite.com/broker/brokername2.php (yep, they are scattered all over the place! - but I do know where each one is) should show mysite.com/broker/brokername1 or mysite.com/broker/brokername2. On the server, /get-quote/broker/brokername1 or /get-quote/broker/brokername2 should be accessed.
I don't think what I've written is completely clear, so maybe sudocode helps:
If '/insurancequote.php'
Dont Redirect
Use '/get-quote/'
If '/brokerquote.php'
Redirect '/broker/'
Use '/get-quote/broker/'
// Do the following (manually) for each broker
If '/brokername1.php'
Redirect '/broker/brokername1/'
Use '/get-quote/broker/brokername1/'
If '/brokers/bname2.php'
Redirect '/broker/brokername2/'
Use '/get-quote/broker/brokername2/'
If '/mybrokerpage.php'
Redirect '/broker/mybroker/'
Use '/get-quote/broker/mybroker/'
Is this possible? If so, how would I go about doing it?
Thanks!
The risk you take is messing up your new clean code for historical reasons (and the guy coming next you will say, WTF, this is a mess!).
For me the right solution would be handling the url migration in apache and not in your application. Every refferenced url that you do not want to keep should get a 410 - Gone message (think about referenced images for example) and every referenced page which have a new matching page should get a 301 - moved permanently redirection on the right page. Then after some time as gone check the access log of your server, and if nobody checks the old url anymore then remove the rules.
If you know every old url and every matching url then use a matching url file (or hash file, faster) and manage the redirection 301 with rewriteMap. You can have a really big number of files in a hash file, the match should be fast. And it should be a temporary function, waiting for robots to fix the urls.
I want to redirect every post 301 redirect, but I have over 3000 posts.
If I list
Redirect permanent /blog/2010/07/post.html http://new.blog.com/2010/07/23/post/
Redirect permanent /blog/2010/07/post1.html http://new.blog.com/2010/07/24/post1/
Redirect permanent /blog/2010/07/post2.html http://new.blog.com/2010/07/25/post2/
Redirect permanent /blog/2010/07/post3.html http://new.blog.com/2010/07/26/post3/
Redirect per......
for over 3000 url redirect command in .htaccess would this eat my server resource or cause some problem? Im not sure how .htaccess work but if the server is looking at these lists each time user requests for page, I would guess it will be a resource hog.
I can't use RedirectMatch because I added date variable in my new url. Do you have any other suggestions redirecting these posts? Or am I just fine?
Thanks!
I am not an Apache expert, so I cannot speak to whether or not having 3,000 redirects in .htaccess is a problem (though my gut tells me it probably is a bad idea). However, as a simpler solution to your problem, why not use mod_rewrite to do your redirects?
RewriteRule ^/blog/(.+)/(.+)/(.+).html$ http://new.blog.com/$1/$2/$3/ [R=permanent]
This uses a regex to match old URLs and rewrite them to new ones. The [R=permanent] instructs mod_rewrite to issue a 301 with the new URL instead of silently rewriting the request internally.
In your example, it looks like you've added the day of the post to the URL, which does not exist in the old URL. Since you obviously cannot use a regexp to divine the day an arbitrary post was made, this method may not work for you. If you can drop the day from the URL, then you're good to go.
Edit: The first time I read your question, I missed the last paragraph. ("I can't use RedirectMatch because I added date variable in my new url.") In this case, you can use mod_rewrite's RewriteMap to lookup the day component of a post.
You have two options:
Use a hashmap to perform fast lookups in a static file. This means all your old URLs will work, but any new posts cannot be accessed using the old URL scheme.
Use a script to grab the day.
In option one, create a file called posts.txt and put:
/yyyy/mm/pppp dd
...for each post where yyyy is the year of the post, mm is the month, and pppp is the post name (without the .html).
When you're done, run:
$ httxt2dbm -i posts.txt -o posts.map
Then we add to to the server/virtual server config: (Note the path is a filesystem path, not a URL.)
RewriteMap postday dbm:/path/to/file/posts.map
RewriteRule ^/blog/(.+)/(.+)/(.+).html$ http://new.blog.com/$1/$2/${postday:$1/$2/$3}/$3/ [R=permanent]
In option two, use pgm:/path/to/script/lookup.whatever as your RewriteMap. See the mod_rewrite documentation for more info about using a script.
Doing the lookup in mod_rewrite is better than just redirecting to a script which looks up the date and then redirects to the final destination because you should never redirect more than once. Issuing a 301 or 302 incurs a round trip cost, which increases the latency of your page load time.
If you have some way in code to determine the day of a post, you can generate the rewrite on the fly. You can setup a mod_rewrite pattern, something like .html and set up a front controller pattern to calculate the new url from the old and issue the 301 header.
With php as an example:
$_SERVER['REQUEST_URI']
will contain the requested url and
header("Location: http://new.blog.com/$y/$m/$d/$title/",TRUE,301);
will send a redirect.
That's... a lot of redirects. But the first thing I would tell you, and probably the only thing I can tell you without qualification, is that you should run some tests and see what the access times for your blog are like, and also look at the server's CPU and memory usage while you're doing it. If they're fairly low even with that giant list of redirects, you're okay as long as your blog doesn't experience a sudden increase in traffic. (I strongly suspect the 3000 rewrites will be slowing Apache down a lot, though)
That being said, I would second josh's suggestion of replacing the redirects with something dynamic. Like animuson said, if you're willing to drop the day from the URL, it'll be easy to set up a RewriteRule directive to handle the redirection. Otherwise, you could do it with a PHP script, or generally some code in whatever scripting language you (can) use. If you're using one of the popular blog engines, it probably contains code to do this already. Basically you could do something like
RewriteRule .* /blog/index.php
and just let the PHP script sort out which post was requested. It has access to the database so it'll be able to do that, and then you can either display the post directly from the PHP script, or to recover your original redirection behavior, you can send a Location header with the correct URL.
An alternative would be to use RewriteMap, which lets you write a RewriteRule where the target is determined by a program or file of your choice instead of being directly specified in the configuration file. As one option, you can specify a text file that contains the old and new URLs, and Apache will handle searching the file for the appropriate line for any given request. Read the documentation (linked above) for the full details. I will mention that this isn't used very often, and I'm not sure how much faster it would be compared to just having 3000 redirects.
Last tip: Apache can be significantly faster if you're able to move the configuration directives (like Redirect) into the server or virtual host configuration file, and disable reading of .htaccess entirely. I would guess that moving 3000 directives from .htaccess into the virtual host configuration could make your server considerably faster. But even moving the directives into the vhost config file probably wouldn't produce as much of a speedup as using a single RewriteRule.
It's never a good idea to make a massive list of Redirects. A better programming technique is to simply redirect the pages without that date variable then have a small PHP snippet that detects if it's missing and redirects to the URL with it included. The long list looks tacky and slows down Apache because it's checking that URL (any every other URL that might not even be affected by this) against each line. If it were only 5 or so, I'd say fine, but 3,000 is a definite NO.
Although I'm not a big fan of this method, a better choice would be to redirect all those URLs normally using a single match statement, redirecting them to the page without the date part, or with a dash or something, then include a small PHP snippet to check if the date is valid and if not, rewrite the path again to the correctly formed URL.
Honestly, if you didn't have that part there before, you don't need it now, and it will probably just confuse the search engines changing the URL for 3,000 posts. You don't really need a date in the URL, a good title is much more meaningful not only to users, but also to search engines, than a bunch of numbers.