Magento core_url_rewrite table excessively large Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?Understanding Catalog URL Rewrite IndexerMagento product url not working after magento upgrade from 1.5 to 1.8`core_url_rewrite` Table optimizationcore_url_rewrite is too bigCan I Delete The Thousands Of URL Rewrites?What are reasons for a Magento database become huge?Lock wait timeout exceededCore Url Rewrite bug in Magento 1.8?magento url rewrite prevent -1 or -2core_url_rewrite tableHow do I report Magento bugs and submit bugfixes so that they are likely to be closed?Why Magento 1.8 better than older version?Why is my url added to the enterprise_url_rewrite table but not core_url_rewrite?Moving large number of categories URL Rewrite management and SEOcore_url_rewrite doesn't get written during indexingWeird non system rows being added to core_url_rewriteErrors after re-index: Item (Mage_Core_Model_Url_Rewrite) with the same id “0” already exist"How Catalog URL Rewrite works? Is this a bug?core_url_rewrite tableN98 magerun url rewrites command issue - Magento 1.9x
Would color changing eyes affect vision?
Simple Http Server
Getting out of while loop on console
Does silver oxide react with hydrogen sulfide?
Why are vacuum tubes still used in amateur radios?
What does Turing mean by this statement?
White walkers, cemeteries and wights
Printing attributes of selection in ArcPy?
Flight departed from the gate 5 min before scheduled departure time. Refund options
My mentor says to set image to Fine instead of RAW — how is this different from JPG?
Universal covering space of the real projective line?
After Sam didn't return home in the end, were he and Al still friends?
Did Mueller's report provide an evidentiary basis for the claim of Russian govt election interference via social media?
How many time has Arya actually used Needle?
Nose gear failure in single prop aircraft: belly landing or nose-gear up landing?
Why is std::move not [[nodiscard]] in C++20?
What is the origin of 落第?
Did any compiler fully use 80-bit floating point?
Why is it faster to reheat something than it is to cook it?
Differences to CCompactSize and CVarInt
Positioning dot before text in math mode
Weaponising the Grasp-at-a-Distance spell
What is the "studentd" process?
Sally's older brother
Magento core_url_rewrite table excessively large
Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)
Announcing the arrival of Valued Associate #679: Cesar Manara
Unicorn Meta Zoo #1: Why another podcast?Understanding Catalog URL Rewrite IndexerMagento product url not working after magento upgrade from 1.5 to 1.8`core_url_rewrite` Table optimizationcore_url_rewrite is too bigCan I Delete The Thousands Of URL Rewrites?What are reasons for a Magento database become huge?Lock wait timeout exceededCore Url Rewrite bug in Magento 1.8?magento url rewrite prevent -1 or -2core_url_rewrite tableHow do I report Magento bugs and submit bugfixes so that they are likely to be closed?Why Magento 1.8 better than older version?Why is my url added to the enterprise_url_rewrite table but not core_url_rewrite?Moving large number of categories URL Rewrite management and SEOcore_url_rewrite doesn't get written during indexingWeird non system rows being added to core_url_rewriteErrors after re-index: Item (Mage_Core_Model_Url_Rewrite) with the same id “0” already exist"How Catalog URL Rewrite works? Is this a bug?core_url_rewrite tableN98 magerun url rewrites command issue - Magento 1.9x
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
I've noticed a large amount of reports that this table itself can become extremely cluttered, I'm running a site with ~5000 SKUs and ~250 categories (single-store) and a resultant core_url_rewrite
table of over 600,000 lines and over 500MB large which is insane.
This can slow down site performance and result in a very bulky database. I've done some digging and found quite a few posts regarding this, most notably:
Core_url_rewrite bug: Massive amount of duplicate url’s for each product generated on indexMagento Commerce - Bug Tracking - Issue #29020
//These links have been removed since the implementation of the new boards
Now I understand that the table can be truncated and reindexed, but this doesn't solve the problem, it just prolongs the issue from happening again.
From what I understand, part of the issue is products which have the same url key based on the product's name, thus resulting in indexed links.
A fix mentioned is:
app/code/core/Mage/Catalog/Model/Url.php
on line ~807:
Change:
if ($product->getUrlKey() == '' && !empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
To:
if (!empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
But even this does not completely resolve the issue.
My question is as follows:
If you have experienced this issue, have you managed to set up an effective, logical & efficient algorithm which does not involve "managing" the issue repeatedly, but actually resolving the matter once and for all?
Would really appreciate some insight into this.
BTW: Please do yourself a favor and check what your table is looking like right now, you may be experiencing this issue and the performance impact as a result thereof without even knowing it - I didn't.
Edit: I have been in contact with www.Nexcess.net (a Magento platinum hosting partner) and they have confirmed that they have had clients request that their core_url_rewrite
table requires truncation as a result of being too bulky.
A big worry of mine is the SEO impact that this may have, which is why I'd like a solution as opposed to procrastinating the issue from arising again.
Update: Nexcess mentioned that with the duplicate products within the table it may actually be hurting SEO as it is.
magento-1 url-rewrite core bug
|
show 2 more comments
I've noticed a large amount of reports that this table itself can become extremely cluttered, I'm running a site with ~5000 SKUs and ~250 categories (single-store) and a resultant core_url_rewrite
table of over 600,000 lines and over 500MB large which is insane.
This can slow down site performance and result in a very bulky database. I've done some digging and found quite a few posts regarding this, most notably:
Core_url_rewrite bug: Massive amount of duplicate url’s for each product generated on indexMagento Commerce - Bug Tracking - Issue #29020
//These links have been removed since the implementation of the new boards
Now I understand that the table can be truncated and reindexed, but this doesn't solve the problem, it just prolongs the issue from happening again.
From what I understand, part of the issue is products which have the same url key based on the product's name, thus resulting in indexed links.
A fix mentioned is:
app/code/core/Mage/Catalog/Model/Url.php
on line ~807:
Change:
if ($product->getUrlKey() == '' && !empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
To:
if (!empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
But even this does not completely resolve the issue.
My question is as follows:
If you have experienced this issue, have you managed to set up an effective, logical & efficient algorithm which does not involve "managing" the issue repeatedly, but actually resolving the matter once and for all?
Would really appreciate some insight into this.
BTW: Please do yourself a favor and check what your table is looking like right now, you may be experiencing this issue and the performance impact as a result thereof without even knowing it - I didn't.
Edit: I have been in contact with www.Nexcess.net (a Magento platinum hosting partner) and they have confirmed that they have had clients request that their core_url_rewrite
table requires truncation as a result of being too bulky.
A big worry of mine is the SEO impact that this may have, which is why I'd like a solution as opposed to procrastinating the issue from arising again.
Update: Nexcess mentioned that with the duplicate products within the table it may actually be hurting SEO as it is.
magento-1 url-rewrite core bug
Wow, that's a staggeringly large table. I checked my own (200 products) and it only has ~800 rows, but we don't have a problem duplicating product name/URLs. As a reference point, we have about 6.6 rows per visible product. I'll admit this not a terrible realistic comparison, but at that rate, with 5,000 products we'd only have ~30,000 rows or so. I can well understand your need for a solution, and will watch this question as I'm about to implement a much bigger site.
– Pete855217
Mar 29 '14 at 9:23
@Pete855217: this question sounds you interesting even though you had not upvoted it.
– Mohammad Faisal
Mar 29 '14 at 11:00
1
There was a bug in EE1.12 which cause re-writes to be re-created on each save. It is possible that your version of 1.7 has this same bug. As I recall the patch for 1.12 also worked on 1.7
– brentwpeterson
Mar 29 '14 at 13:53
1
Very helpful article! We have 130,000 active products, and 25,000 disabled products, our core_url_rewrite_table has 2744023 records in it..... so this week we are getting to work remedying this!! This article looks to be a good starting point.
– MagentoMac
Jul 28 '14 at 20:36
Edited the post to include how not to delete your custom rewrites in Magento.
– espradley
May 15 '15 at 15:09
|
show 2 more comments
I've noticed a large amount of reports that this table itself can become extremely cluttered, I'm running a site with ~5000 SKUs and ~250 categories (single-store) and a resultant core_url_rewrite
table of over 600,000 lines and over 500MB large which is insane.
This can slow down site performance and result in a very bulky database. I've done some digging and found quite a few posts regarding this, most notably:
Core_url_rewrite bug: Massive amount of duplicate url’s for each product generated on indexMagento Commerce - Bug Tracking - Issue #29020
//These links have been removed since the implementation of the new boards
Now I understand that the table can be truncated and reindexed, but this doesn't solve the problem, it just prolongs the issue from happening again.
From what I understand, part of the issue is products which have the same url key based on the product's name, thus resulting in indexed links.
A fix mentioned is:
app/code/core/Mage/Catalog/Model/Url.php
on line ~807:
Change:
if ($product->getUrlKey() == '' && !empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
To:
if (!empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
But even this does not completely resolve the issue.
My question is as follows:
If you have experienced this issue, have you managed to set up an effective, logical & efficient algorithm which does not involve "managing" the issue repeatedly, but actually resolving the matter once and for all?
Would really appreciate some insight into this.
BTW: Please do yourself a favor and check what your table is looking like right now, you may be experiencing this issue and the performance impact as a result thereof without even knowing it - I didn't.
Edit: I have been in contact with www.Nexcess.net (a Magento platinum hosting partner) and they have confirmed that they have had clients request that their core_url_rewrite
table requires truncation as a result of being too bulky.
A big worry of mine is the SEO impact that this may have, which is why I'd like a solution as opposed to procrastinating the issue from arising again.
Update: Nexcess mentioned that with the duplicate products within the table it may actually be hurting SEO as it is.
magento-1 url-rewrite core bug
I've noticed a large amount of reports that this table itself can become extremely cluttered, I'm running a site with ~5000 SKUs and ~250 categories (single-store) and a resultant core_url_rewrite
table of over 600,000 lines and over 500MB large which is insane.
This can slow down site performance and result in a very bulky database. I've done some digging and found quite a few posts regarding this, most notably:
Core_url_rewrite bug: Massive amount of duplicate url’s for each product generated on indexMagento Commerce - Bug Tracking - Issue #29020
//These links have been removed since the implementation of the new boards
Now I understand that the table can be truncated and reindexed, but this doesn't solve the problem, it just prolongs the issue from happening again.
From what I understand, part of the issue is products which have the same url key based on the product's name, thus resulting in indexed links.
A fix mentioned is:
app/code/core/Mage/Catalog/Model/Url.php
on line ~807:
Change:
if ($product->getUrlKey() == '' && !empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
To:
if (!empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
But even this does not completely resolve the issue.
My question is as follows:
If you have experienced this issue, have you managed to set up an effective, logical & efficient algorithm which does not involve "managing" the issue repeatedly, but actually resolving the matter once and for all?
Would really appreciate some insight into this.
BTW: Please do yourself a favor and check what your table is looking like right now, you may be experiencing this issue and the performance impact as a result thereof without even knowing it - I didn't.
Edit: I have been in contact with www.Nexcess.net (a Magento platinum hosting partner) and they have confirmed that they have had clients request that their core_url_rewrite
table requires truncation as a result of being too bulky.
A big worry of mine is the SEO impact that this may have, which is why I'd like a solution as opposed to procrastinating the issue from arising again.
Update: Nexcess mentioned that with the duplicate products within the table it may actually be hurting SEO as it is.
magento-1 url-rewrite core bug
magento-1 url-rewrite core bug
edited Apr 19 '18 at 14:08
7ochem
5,86493770
5,86493770
asked Mar 29 '14 at 7:39
MooseMoose
5,69563979
5,69563979
Wow, that's a staggeringly large table. I checked my own (200 products) and it only has ~800 rows, but we don't have a problem duplicating product name/URLs. As a reference point, we have about 6.6 rows per visible product. I'll admit this not a terrible realistic comparison, but at that rate, with 5,000 products we'd only have ~30,000 rows or so. I can well understand your need for a solution, and will watch this question as I'm about to implement a much bigger site.
– Pete855217
Mar 29 '14 at 9:23
@Pete855217: this question sounds you interesting even though you had not upvoted it.
– Mohammad Faisal
Mar 29 '14 at 11:00
1
There was a bug in EE1.12 which cause re-writes to be re-created on each save. It is possible that your version of 1.7 has this same bug. As I recall the patch for 1.12 also worked on 1.7
– brentwpeterson
Mar 29 '14 at 13:53
1
Very helpful article! We have 130,000 active products, and 25,000 disabled products, our core_url_rewrite_table has 2744023 records in it..... so this week we are getting to work remedying this!! This article looks to be a good starting point.
– MagentoMac
Jul 28 '14 at 20:36
Edited the post to include how not to delete your custom rewrites in Magento.
– espradley
May 15 '15 at 15:09
|
show 2 more comments
Wow, that's a staggeringly large table. I checked my own (200 products) and it only has ~800 rows, but we don't have a problem duplicating product name/URLs. As a reference point, we have about 6.6 rows per visible product. I'll admit this not a terrible realistic comparison, but at that rate, with 5,000 products we'd only have ~30,000 rows or so. I can well understand your need for a solution, and will watch this question as I'm about to implement a much bigger site.
– Pete855217
Mar 29 '14 at 9:23
@Pete855217: this question sounds you interesting even though you had not upvoted it.
– Mohammad Faisal
Mar 29 '14 at 11:00
1
There was a bug in EE1.12 which cause re-writes to be re-created on each save. It is possible that your version of 1.7 has this same bug. As I recall the patch for 1.12 also worked on 1.7
– brentwpeterson
Mar 29 '14 at 13:53
1
Very helpful article! We have 130,000 active products, and 25,000 disabled products, our core_url_rewrite_table has 2744023 records in it..... so this week we are getting to work remedying this!! This article looks to be a good starting point.
– MagentoMac
Jul 28 '14 at 20:36
Edited the post to include how not to delete your custom rewrites in Magento.
– espradley
May 15 '15 at 15:09
Wow, that's a staggeringly large table. I checked my own (200 products) and it only has ~800 rows, but we don't have a problem duplicating product name/URLs. As a reference point, we have about 6.6 rows per visible product. I'll admit this not a terrible realistic comparison, but at that rate, with 5,000 products we'd only have ~30,000 rows or so. I can well understand your need for a solution, and will watch this question as I'm about to implement a much bigger site.
– Pete855217
Mar 29 '14 at 9:23
Wow, that's a staggeringly large table. I checked my own (200 products) and it only has ~800 rows, but we don't have a problem duplicating product name/URLs. As a reference point, we have about 6.6 rows per visible product. I'll admit this not a terrible realistic comparison, but at that rate, with 5,000 products we'd only have ~30,000 rows or so. I can well understand your need for a solution, and will watch this question as I'm about to implement a much bigger site.
– Pete855217
Mar 29 '14 at 9:23
@Pete855217: this question sounds you interesting even though you had not upvoted it.
– Mohammad Faisal
Mar 29 '14 at 11:00
@Pete855217: this question sounds you interesting even though you had not upvoted it.
– Mohammad Faisal
Mar 29 '14 at 11:00
1
1
There was a bug in EE1.12 which cause re-writes to be re-created on each save. It is possible that your version of 1.7 has this same bug. As I recall the patch for 1.12 also worked on 1.7
– brentwpeterson
Mar 29 '14 at 13:53
There was a bug in EE1.12 which cause re-writes to be re-created on each save. It is possible that your version of 1.7 has this same bug. As I recall the patch for 1.12 also worked on 1.7
– brentwpeterson
Mar 29 '14 at 13:53
1
1
Very helpful article! We have 130,000 active products, and 25,000 disabled products, our core_url_rewrite_table has 2744023 records in it..... so this week we are getting to work remedying this!! This article looks to be a good starting point.
– MagentoMac
Jul 28 '14 at 20:36
Very helpful article! We have 130,000 active products, and 25,000 disabled products, our core_url_rewrite_table has 2744023 records in it..... so this week we are getting to work remedying this!! This article looks to be a good starting point.
– MagentoMac
Jul 28 '14 at 20:36
Edited the post to include how not to delete your custom rewrites in Magento.
– espradley
May 15 '15 at 15:09
Edited the post to include how not to delete your custom rewrites in Magento.
– espradley
May 15 '15 at 15:09
|
show 2 more comments
13 Answers
13
active
oldest
votes
I've managed to stabalize the issue as follows:
Step 1: Rewrite the Catalog URL model (Using your own module: How To)
Note: If you overwrite the core file without using a rewrite this will
render your instance of Magento incapable of future upgrades.
As per Jahnni's solution on the MagentoCommerce boards (no longer active with new board), app/code/core/Mage/Catalog/Model/Url.php
[ around line 807 Mage_Catalog_Model_Url::getProductRequestPath()
]
From:
if ($product->getUrlKey() == '' && !empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
To:
if (!empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
Step 2: Truncate
Truncate the core_url_rewrite
table
Step 3: Reindex & Flush Caches
Initiate the re-indexing process on Core URL Rewrites.
Thereafter, you'll want to flush the Magento cache & storage cache.
System
→ Cache Management
→ Flush Magento Cache
System
→ Cache Management
→ Flush Cache Storage
Voila, you're all set. You'll notice if you re-run the indexer, the table should stay constant in size (unless you've added more products inbetween or if you have duplicate category names).
5
Great, my core_url_rewrite table was 3.2 GB now is 36.8 MB :D by muppet
– Fabian Blechschmidt
Jul 24 '14 at 10:40
I have a similar problem. Magento URL rewrite append random number in Url. Please look at the screenshot attached from google web master tools. As you can see the product "Beige Embroidered Wedding Saree" has nine different URL's but the it is only one product and pointing to only one URL ending with 878. The actual URL key doesn't have a random number in the end(screenshot attached). My store is fairly a new one and the size of core_url_rewrite is not that big. So I am not sure if I should go ahead and do Step 1 & 2 or Only Step 1. If I perform step 2 I will lose my custom rewrites.
– Zoya
May 25 '15 at 9:28
I am running 1.9.1 and here are missed screenshot urls. monosnap.com/image/duL0f64WWlACtlt9kcn04BWqY3L5Xl monosnap.com/image/osFk8kYNAr00XLdFTGTIOaydaW5yqS
– Zoya
May 25 '15 at 9:31
2
I would export the existing table first. Then I would proceed with steps 1, 2 and 3. Take a look atcore_url_rewrite
table now and note down the number of records. Run step 3 again (the re-indexing), and refresh your view on thecore_url_rewrite
table. If the number is the same, you've resolved successfully. Then go ahead and manually merge your custom rewrites. All the best.
– Moose
May 25 '15 at 9:39
2
This fix only works for products, not for categories with identical URL keys. See @Simon s' answer for a better solution (with the patch file)
– Giel Berkers
Jun 25 '15 at 12:22
|
show 2 more comments
While I hope someone here comes up with an answer, I don't know that you'll find one. This table gets bulky for a lot of different reasons. Bugs in earlier (and possibly current) versions of Magento is one. Another is there's logic in this table that tries to track changes to the URL key value so that 301/302 rewrites are setup for old products. Because of this, and complicating things, truncating the table and regenerating may make existing URL rewrites go away, and this will have an unknown effect on your search engine listing (not necessity bad, just hard to predict).
My general advice to clients who ask is
Leave the giant growing table as is if you don't have a good handle on your URL/SEO situation
Until the table size starts being a problem (generating site maps, for example). When that happens, get a handle on your URL/SEO situation.
Once you have a handle on your URL/SEO situation, backup the table, then truncate the table and regenerate. Address any URL/SEO problems caused by the truncating.
Automate step 3
Trying to fix this on the Magento code level is admirable, but you'll be swimming upstream. Sometimes it's better to accept that "That's just Magento being Magento", and to solve the problem with and external process.
thanks for the advice, it's a pity about the situation but I do think that it is going to have to be handled by an external process as you mentioned, urgh.
– Moose
Mar 31 '14 at 5:40
2
This giant table can already cause SEO problems, as the canonical for a given product will change constantly. If you have a seperate storeview for mobile and desktop, then it's even worse as their URLs will differ.
– Melvyn
Mar 28 '15 at 17:48
A bit disappointing answer to me ...
– Fra
Mar 16 '17 at 8:13
@Alan Storm, how do you feel about the answer posted by Moose after you posted this answer? Do you see the same risks?
– Goose
Feb 9 '18 at 12:55
add a comment |
I would like to add a fix for this url rewrite indexer bug which has been developed at the bugathon in March 2013 and which has been further improved afterwards. It should solve this issue. As a reference, here is the patch file from the link:
diff -rupN mage_org/app/code/core/Mage/Catalog/Model/Url.php src_shop/app/code/core/Mage/Catalog/Model/Url.php
--- mage_org/app/code/core/Mage/Catalog/Model/Url.php 2013-11-19 00:48:25.679009391 +0100
+++ src_shop/app/code/core/Mage/Catalog/Model/Url.php 2013-11-19 00:49:24.188005601 +0100
@@ -643,13 +643,24 @@ class Mage_Catalog_Model_Url
$this->_rewrite = $rewrite;
return $requestPath;
}
+
+ // avoid unnecessary creation of new url_keys for duplicate url keys
+ $noSuffixPath = substr($requestPath, 0, -(strlen($suffix)));
+ $regEx = '#^('.preg_quote($noSuffixPath).')(-([0-9]+))?('.preg_quote($suffix).')#i';
+ $currentRewrite = $this->getResource()->getRewriteByIdPath($idPath, $storeId);
+ if ($currentRewrite && preg_match($regEx, $currentRewrite->getRequestPath(), $match))
+ $this->_rewrite = $currentRewrite;
+ return $currentRewrite->getRequestPath();
+
+
// match request_url abcdef1234(-12)(.html) pattern
$match = array();
$regularExpression = '#^([0-9a-z/-]+?)(-([0-9]+))?('.preg_quote($suffix).')?$#i';
if (!preg_match($regularExpression, $requestPath, $match))
return $this->getUnusedPath($storeId, '-', $idPath);
- $match[1] = $match[1] . '-';
+ $match[1] = $noSuffixPath . '-'; // always use full prefix of url_key
+ unset($match[3]); // don't start counting with a possible number in the url_key
$match[4] = isset($match[4]) ? $match[4] : '';
$lastRequestPath = $this->getResource()
Additionally, I would like to add the EE patch PATCH_SUPEE-389_EE_1.12.0.2_v2.sh
, which is now available on GitHub:
#!/bin/bash
# Patch apllying tool template
# v0.1.2
# (c) Copyright 2013. Magento Inc.
#
# DO NOT CHANGE ANY LINE IN THIS FILE.
# 1. Check required system tools
_check_installed_tools()
local missed=""
until [ -z "$1" ]; do
type -t $1 >/dev/null 2>/dev/null
if (( $? != 0 )); then
missed="$missed $1"
fi
shift
done
echo $missed
REQUIRED_UTILS='sed patch'
MISSED_REQUIRED_TOOLS=`_check_installed_tools $REQUIRED_UTILS`
if (( `echo $MISSED_REQUIRED_TOOLS | wc -w` > 0 ));
then
echo -e "Error! Some required system tools, that are utilized in this sh script, are not installed:nTool(s) "$MISSED_REQUIRED_TOOLS" is(are) missed, please install it(them)."
exit 1
fi
# 2. Determine bin path for system tools
CAT_BIN=`which cat`
PATCH_BIN=`which patch`
SED_BIN=`which sed`
PWD_BIN=`which pwd`
BASENAME_BIN=`which basename`
BASE_NAME=`$BASENAME_BIN "$0"`
# 3. Help menu
if [ "$1" = "-?" -o "$1" = "-h" -o "$1" = "--help" ]
then
$CAT_BIN << EOFH
Usage: sh $BASE_NAME [--help] [-R|--revert] [--list]
Apply embedded patch.
-R, --revert Revert previously applied embedded patch
--list Show list of applied patches
--help Show this help message
EOFH
exit 0
fi
# 4. Get "revert" flag and "list applied patches" flag
REVERT_FLAG=
SHOW_APPLIED_LIST=0
if [ "$1" = "-R" -o "$1" = "--revert" ]
then
REVERT_FLAG=-R
fi
if [ "$1" = "--list" ]
then
SHOW_APPLIED_LIST=1
fi
# 5. File pathes
CURRENT_DIR=`$PWD_BIN`/
APP_ETC_DIR=`echo "$CURRENT_DIR""app/etc/"`
APPLIED_PATCHES_LIST_FILE=`echo "$APP_ETC_DIR""applied.patches.list"`
# 6. Show applied patches list if requested
if [ "$SHOW_APPLIED_LIST" -eq 1 ] ; then
echo -e "Applied/reverted patches list:"
if [ -e "$APPLIED_PATCHES_LIST_FILE" ]
then
if [ ! -r "$APPLIED_PATCHES_LIST_FILE" ]
then
echo "ERROR: "$APPLIED_PATCHES_LIST_FILE" must be readable so applied patches list can be shown."
exit 1
else
$SED_BIN -n "/SUP-|SUPEE-/p" $APPLIED_PATCHES_LIST_FILE
fi
else
echo "<empty>"
fi
exit 0
fi
# 7. Check applied patches track file and its directory
_check_files()
if [ ! -e "$APP_ETC_DIR" ]
then
echo "ERROR: "$APP_ETC_DIR" must exist for proper tool work."
exit 1
fi
if [ ! -w "$APP_ETC_DIR" ]
then
echo "ERROR: "$APP_ETC_DIR" must be writeable for proper tool work."
exit 1
fi
if [ -e "$APPLIED_PATCHES_LIST_FILE" ]
then
if [ ! -w "$APPLIED_PATCHES_LIST_FILE" ]
then
echo "ERROR: "$APPLIED_PATCHES_LIST_FILE" must be writeable for proper tool work."
exit 1
fi
fi
_check_files
# 8. Apply/revert patch
# Note: there is no need to check files permissions for files to be patched.
# "patch" tool will not modify any file if there is not enough permissions for all files to be modified.
# Get start points for additional information and patch data
SKIP_LINES=$((`$SED_BIN -n "/^__PATCHFILE_FOLLOWS__$/=" "$CURRENT_DIR""$BASE_NAME"` + 1))
ADDITIONAL_INFO_LINE=$(($SKIP_LINES - 3))p
_apply_revert_patch()
DRY_RUN_FLAG=
if [ "$1" = "dry-run" ]
then
DRY_RUN_FLAG=" --dry-run"
echo "Checking if patch can be applied/reverted successfully..."
fi
PATCH_APPLY_REVERT_RESULT=`$SED_BIN -e '1,/^__PATCHFILE_FOLLOWS__$/d' "$CURRENT_DIR""$BASE_NAME"
REVERTED_PATCH_MARK=
if [ -n "$REVERT_FLAG" ]
then
REVERTED_PATCH_MARK=" | REVERTED"
fi
_apply_revert_patch dry-run
_apply_revert_patch
# 9. Track patch applying result
echo "Patch was applied/reverted successfully."
ADDITIONAL_INFO=`$SED_BIN -n ""$ADDITIONAL_INFO_LINE"" "$CURRENT_DIR""$BASE_NAME"`
APPLIED_REVERTED_ON_DATE=`date -u +"%F %T UTC"`
APPLIED_REVERTED_PATCH_INFO=`echo -n "$APPLIED_REVERTED_ON_DATE"" | ""$ADDITIONAL_INFO""$REVERTED_PATCH_MARK"`
echo -e "$APPLIED_REVERTED_PATCH_INFOn$PATCH_APPLY_REVERT_RESULTnn" >> "$APPLIED_PATCHES_LIST_FILE"
exit 0
SUPEE-389 | EE_1.12.0.2 | v1 | 53c8ca52583358953b143aaa1a78cf409e8dd846 | Thu Jun 20 10:36:39 2013 +0300 | v1.12.0.2..HEAD
__PATCHFILE_FOLLOWS__
diff --git app/code/core/Mage/Catalog/Model/Url.php app/code/core/Mage/Catalog/Model/Url.php
index fa55fc5..a755b46 100644
--- app/code/core/Mage/Catalog/Model/Url.php
+++ app/code/core/Mage/Catalog/Model/Url.php
@@ -609,6 +609,23 @@ class Mage_Catalog_Model_Url
*/
public function getUnusedPath($storeId, $requestPath, $idPath)
+ $urlKey = '';
+ return $this->getUnusedPathByUrlkey($storeId, $requestPath, $idPath, $urlKey);
+
+
+ /**
+ * Get requestPath that was not used yet.
+ *
+ * Will try to get unique path by adding -1 -2 etc. between url_key and optional url_suffix
+ *
+ * @param int $storeId
+ * @param string $requestPath
+ * @param string $idPath
+ * @param string $urlKey
+ * @return string
+ */
+ public function getUnusedPathByUrlkey($storeId, $requestPath, $idPath, $urlKey = '')
+
if (strpos($idPath, 'product') !== false)
$suffix = $this->getProductUrlSuffix($storeId);
else
@@ -645,21 +662,22 @@ class Mage_Catalog_Model_Url
// match request_url abcdef1234(-12)(.html) pattern
$match = array();
- $regularExpression = '#^([0-9a-z/-]+?)(-([0-9]+))?('.preg_quote($suffix).')?$#i';
+ $regularExpression = '#(?P<prefix>(.*/)?' . preg_quote($urlKey) . ')(-(?P<increment>[0-9]+))?(?P<suffix>'
+ . preg_quote($suffix) . ')?$#i';
if (!preg_match($regularExpression, $requestPath, $match))
- return $this->getUnusedPath($storeId, '-', $idPath);
+ return $this->getUnusedPathByUrlkey($storeId, '-', $idPath, $urlKey);
- $match[1] = $match[1] . '-';
- $match[4] = isset($match[4]) ? $match[4] : '';
+ $match['prefix'] = $match['prefix'] . '-';
+ $match['suffix'] = isset($match['suffix']) ? $match['suffix'] : '';
$lastRequestPath = $this->getResource()
- ->getLastUsedRewriteRequestIncrement($match[1], $match[4], $storeId);
+ ->getLastUsedRewriteRequestIncrement($match['prefix'], $match['suffix'], $storeId);
if ($lastRequestPath)
- $match[3] = $lastRequestPath;
+ $match['increment'] = $lastRequestPath;
- return $match[1]
- . (isset($match[3]) ? ($match[3]+1) : '1')
- . $match[4];
+ return $match['prefix']
+ . (isset($match['increment']) ? ($match['increment']+1) : '1')
+ . $match['suffix'];
else
return $requestPath;
@@ -699,7 +717,7 @@ class Mage_Catalog_Model_Url
$storeId = $category->getStoreId();
$idPath = $this->generatePath('id', null, $category);
- $suffix = $this->getCategoryUrlSuffix($storeId);
+ $categoryUrlSuffix = $this->getCategoryUrlSuffix($storeId);
if (isset($this->_rewrites[$idPath]))
$this->_rewrite = $this->_rewrites[$idPath];
@@ -713,27 +731,27 @@ class Mage_Catalog_Model_Url
$urlKey = $this->getCategoryModel()->formatUrlKey($category->getUrlKey());
- $categoryUrlSuffix = $this->getCategoryUrlSuffix($category->getStoreId());
if (null === $parentPath)
$parentPath = $this->getResource()->getCategoryParentPath($category);
elseif ($parentPath == '/')
$parentPath = '';
- $parentPath = Mage::helper('catalog/category')->getCategoryUrlPath($parentPath,
- true, $category->getStoreId());
+ $parentPath = Mage::helper('catalog/category')->getCategoryUrlPath($parentPath, true, $storeId);
- $requestPath = $parentPath . $urlKey . $categoryUrlSuffix;
- if (isset($existingRequestPath) && $existingRequestPath == $requestPath . $suffix)
+ $requestPath = $parentPath . $urlKey;
+ $regexp = '/^' . preg_quote($requestPath, '/') . '(-[0-9]+)?' . preg_quote($categoryUrlSuffix, '/') . '$/i';
+ if (isset($existingRequestPath) && preg_match($regexp, $existingRequestPath))
return $existingRequestPath;
- if ($this->_deleteOldTargetPath($requestPath, $idPath, $storeId))
+ $fullPath = $requestPath . $categoryUrlSuffix;
+ if ($this->_deleteOldTargetPath($fullPath, $idPath, $storeId))
return $requestPath;
- return $this->getUnusedPath($category->getStoreId(), $requestPath,
- $this->generatePath('id', null, $category)
+ return $this->getUnusedPathByUrlkey($storeId, $fullPath,
+ $this->generatePath('id', null, $category), $urlKey
);
@@ -798,7 +816,8 @@ class Mage_Catalog_Model_Url
$this->_rewrite = $this->_rewrites[$idPath];
$existingRequestPath = $this->_rewrites[$idPath]->getRequestPath();
- if ($existingRequestPath == $requestPath . $suffix)
+ $regexp = '/^' . preg_quote($requestPath, '/') . '(-[0-9]+)?' . preg_quote($suffix, '/') . '$/i';
+ if (preg_match($regexp, $existingRequestPath))
return $existingRequestPath;
@@ -836,7 +855,7 @@ class Mage_Catalog_Model_Url
/**
* Use unique path generator
*/
- return $this->getUnusedPath($storeId, $requestPath.$suffix, $idPath);
+ return $this->getUnusedPathByUrlkey($storeId, $requestPath.$suffix, $idPath, $urlKey);
/**
@@ -891,8 +910,8 @@ class Mage_Catalog_Model_Url
$parentPath = Mage::helper('catalog/category')->getCategoryUrlPath($parentPath,
true, $category->getStoreId());
- return $this->getUnusedPath($category->getStoreId(), $parentPath . $urlKey . $categoryUrlSuffix,
- $this->generatePath('id', null, $category)
+ return $this->getUnusedPathByUrlkey($category->getStoreId(), $parentPath . $urlKey . $categoryUrlSuffix,
+ $this->generatePath('id', null, $category), $urlKey
);
@@ -913,14 +932,14 @@ class Mage_Catalog_Model_Url
$this->_addCategoryUrlPath($category);
$categoryUrl = Mage::helper('catalog/category')->getCategoryUrlPath($category->getUrlPath(),
false, $category->getStoreId());
- return $this->getUnusedPath($category->getStoreId(), $categoryUrl . '/' . $urlKey . $productUrlSuffix,
- $this->generatePath('id', $product, $category)
+ return $this->getUnusedPathByUrlkey($category->getStoreId(), $categoryUrl . '/' . $urlKey . $productUrlSuffix,
+ $this->generatePath('id', $product, $category), $urlKey
);
// for product only
- return $this->getUnusedPath($category->getStoreId(), $urlKey . $productUrlSuffix,
- $this->generatePath('id', $product)
+ return $this->getUnusedPathByUrlkey($category->getStoreId(), $urlKey . $productUrlSuffix,
+ $this->generatePath('id', $product), $urlKey
);
If you want to use this patch with CE, make sure to test it properly, because it has been developed for EE.
Have you yourself tested this EE patch on CE?
– Tyler V.
Mar 19 '15 at 18:14
@TylerV. Nope...
– Simon
Mar 20 '15 at 13:22
3
I've tried this patch in EE 1.9.1.1 and can conform it works. It fixes the problem with products and categories with identical url keys. Let's hope they implement this in a future release soon.
– Giel Berkers
Jun 25 '15 at 12:21
1
Thanks Simon, just went from 1GB to 3MB on one clients website... Had to truncate it before every 6 months, hope it will remain small now:)
– willem wigman
Aug 10 '15 at 12:46
1
I've just tried this on my 1.9 CE and although it works for products - the categories are not quite right. If I have a category called 'Test' which gives the url '.../test' and then I create another called 'Test' it should give the url '.../test-2' but instead gives just the number not the name: '.../-2'
– odd_duck
Aug 26 '16 at 15:41
|
show 3 more comments
After you applied the patch posted by Simon, you can use the following query to remove junk data:
DELETE FROM core_url_rewrite
WHERE is_system <> 1 AND id_path REGEXP "^[0-9]+_[0-9]+$" AND
(request_path REGEXP ".*-[0-9]*.html"
OR target_path = request_path);
In contrast to Ashish Hira's query, this only effects URLs which have an integer number as there last part - this was - in my case - the reason for the clutter.
It tries to not touch valid rewrites, which for example might have been created when updating an URL key.
add a comment |
I've implemented the accepted answer with success. On another Magento install I needed to preserve some custom rewrites so I deleted all entries that ended in a - and then a number up to 5 digits long with:
DELETE FROM `core_url_rewrite` WHERE `request_path` REGEXP '\-[0-9]1,5$';
This mostly worked but I still get 2 more rows on each re-index. Not sure why. I thought I would share this experience.
1
You probably deleted URLs that are valid, yet end in a number. You'd find those with$collection = Mage::getModel('catalog/product')->getCollection()->addAttributeToFilter('url_key', array('regexp' => '[0-9]$'));
– Melvyn
Mar 28 '15 at 17:43
add a comment |
The core change that you mentioned only seems to be needed if you have products without url_keys, however Magento should always create url_keys for you. If you have some importer which is creating products without url_keys, then this problem will crop up for those products. Try running the following query to find such products:
SELECT cpe.entity_id, cpe.sku, cpev.value
FROM catalog_product_entity cpe
LEFT JOIN catalog_product_entity_varchar cpev
ON cpe.entity_id = cpev.entity_id AND cpev.attribute_id = (
SELECT attribute_id
FROM eav_attribute
WHERE `entity_type_id` = 4
AND `attribute_code` = 'url_key'
)
WHERE cpev.value IS NULL OR cpev.value = ''
If any products return from that query, they don't have a url_key and are going to be a problem.
2
Mind that the defaultentity_type_id
for products is 4 and not 10.
– Simon
Jan 20 '16 at 15:07
add a comment |
I followed approved solution to prevent duplicate URL rewrites, then exported core_url_rewrite
as CSV file. Was able to open this CSV and delete all but manually created URL rewrites.
Then I truncated core_url_rewrite
table, and imported my saved CSV with manually created URL rewrites.
After all changes, went from 940K rows to 32K. Huge improvement.
add a comment |
Here is patch (local rewrite) for Magento Community for fix that https://github.com/biotech/Magento-URL-Rewrite In fact does the same as EE patch PATCH_SUPEE-389_EE_1.12.0.2_v2.sh - check every rewrite and avoid creation of duplicated records. Works well last 2 months on production CE 1.9 , 15k products , 4 stores , full re-index every night after bulk product import changes.
How thoroughly has this been tested? It looks like it was posted just an hour ago....
– SR_Magento
Aug 11 '15 at 15:20
Has this been fixed in 1.9.2.x so we no longer need worry about table bloat?
– Fiasco Labs
Aug 11 '15 at 15:21
Single link answers are not the best answers even if they might solve the problem. Please explain a bit what your code does.
– Marius♦
Aug 11 '15 at 15:23
@FiascoLabs yes, works good on all CE 1.9.x
– FireBear
Aug 12 '15 at 16:11
1
@FiascoLabs: 1.9.2.x still has this "rewrite bloat" issue, and doesn't include this fix, however, as FireBear said, the EE patch will work with CE 1.9.2.x. (have not tried personally; only wanted to clarify that 1.9.2.2 definitely still has this issue)
– Eric Seastrand
Jan 5 '16 at 23:06
|
show 3 more comments
Since this is not yet mentioned in this thread, I wanted to share the cool news that this issue is fixed in Magento 1.9.3.9 and later. See the related release notes:
Magento no longer performs unnecessary write operations on the core_url_rewrite table.
So all fixes for this issue mentioned here are not necessary when using a version of Magento greater or equal than 1.9.3.9. I still suggest deleting the old values as described in Alex answer.
add a comment |
Run this query
DELETE FROM core_url_rewrite WHERE is_system <> 1 AND id_path REGEXP "^[0-9]+_[0-9]+$";
This will surely help you reduce the size of core_url_size
table by deleting junk data.
Are you sure this is junk data? I think it deleted also rewrites which were created when changing an URL key!
– Alex
Mar 15 '16 at 10:10
Check the regex. this mean which don't have valid id
– Asish Hira
Mar 15 '16 at 10:13
But those IDs are also created when changing the URL key manually in the backend. See also my answer.
– Alex
Mar 15 '16 at 11:07
add a comment |
Get rid of .html
- Do not use suffix
.html
Set in .htaccess
## Redirect all htmls.
RewriteRule (.+).html$ /$1 [L,R=301]Erase all
.html
redirects:DELETE FROM core_url_rewrite WHERE request_path LIKE '%.html'
add a comment |
The official answer should be to install SUPEE-389. Simple as that.
It perfectly works with Magento CE since they share the very same piece of code in this area.
You can find the patch file here, https://gist.github.com/piotrekkaminski/c348538ca91ba35773be#file-patch_supee-389_ee_1-12-0-2_v2-sh
We had this issue and it generated thousands of new rows after each Catalog URL re-index. Now the problem is gone... except for the fact that we have to clean the DB.
The script provided here seems like a good start but it is not a perfect solution,
php shell/rewrites_doctor.php --remove_rewrites 4
See https://www.atwix.com/magento/duplicated-product-url-keys-in-community-edition/
add a comment |
There is also a dedicated module https://github.com/vladsmirnov/url-rewrites, so you don’t have to re-apply the patch after the each Magento update. Module contains of two parts: actual module, to prevent duplication from now on and the shell script to cleanup the existing database.
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "479"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmagento.stackexchange.com%2fquestions%2f17553%2fmagento-core-url-rewrite-table-excessively-large%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
13 Answers
13
active
oldest
votes
13 Answers
13
active
oldest
votes
active
oldest
votes
active
oldest
votes
I've managed to stabalize the issue as follows:
Step 1: Rewrite the Catalog URL model (Using your own module: How To)
Note: If you overwrite the core file without using a rewrite this will
render your instance of Magento incapable of future upgrades.
As per Jahnni's solution on the MagentoCommerce boards (no longer active with new board), app/code/core/Mage/Catalog/Model/Url.php
[ around line 807 Mage_Catalog_Model_Url::getProductRequestPath()
]
From:
if ($product->getUrlKey() == '' && !empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
To:
if (!empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
Step 2: Truncate
Truncate the core_url_rewrite
table
Step 3: Reindex & Flush Caches
Initiate the re-indexing process on Core URL Rewrites.
Thereafter, you'll want to flush the Magento cache & storage cache.
System
→ Cache Management
→ Flush Magento Cache
System
→ Cache Management
→ Flush Cache Storage
Voila, you're all set. You'll notice if you re-run the indexer, the table should stay constant in size (unless you've added more products inbetween or if you have duplicate category names).
5
Great, my core_url_rewrite table was 3.2 GB now is 36.8 MB :D by muppet
– Fabian Blechschmidt
Jul 24 '14 at 10:40
I have a similar problem. Magento URL rewrite append random number in Url. Please look at the screenshot attached from google web master tools. As you can see the product "Beige Embroidered Wedding Saree" has nine different URL's but the it is only one product and pointing to only one URL ending with 878. The actual URL key doesn't have a random number in the end(screenshot attached). My store is fairly a new one and the size of core_url_rewrite is not that big. So I am not sure if I should go ahead and do Step 1 & 2 or Only Step 1. If I perform step 2 I will lose my custom rewrites.
– Zoya
May 25 '15 at 9:28
I am running 1.9.1 and here are missed screenshot urls. monosnap.com/image/duL0f64WWlACtlt9kcn04BWqY3L5Xl monosnap.com/image/osFk8kYNAr00XLdFTGTIOaydaW5yqS
– Zoya
May 25 '15 at 9:31
2
I would export the existing table first. Then I would proceed with steps 1, 2 and 3. Take a look atcore_url_rewrite
table now and note down the number of records. Run step 3 again (the re-indexing), and refresh your view on thecore_url_rewrite
table. If the number is the same, you've resolved successfully. Then go ahead and manually merge your custom rewrites. All the best.
– Moose
May 25 '15 at 9:39
2
This fix only works for products, not for categories with identical URL keys. See @Simon s' answer for a better solution (with the patch file)
– Giel Berkers
Jun 25 '15 at 12:22
|
show 2 more comments
I've managed to stabalize the issue as follows:
Step 1: Rewrite the Catalog URL model (Using your own module: How To)
Note: If you overwrite the core file without using a rewrite this will
render your instance of Magento incapable of future upgrades.
As per Jahnni's solution on the MagentoCommerce boards (no longer active with new board), app/code/core/Mage/Catalog/Model/Url.php
[ around line 807 Mage_Catalog_Model_Url::getProductRequestPath()
]
From:
if ($product->getUrlKey() == '' && !empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
To:
if (!empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
Step 2: Truncate
Truncate the core_url_rewrite
table
Step 3: Reindex & Flush Caches
Initiate the re-indexing process on Core URL Rewrites.
Thereafter, you'll want to flush the Magento cache & storage cache.
System
→ Cache Management
→ Flush Magento Cache
System
→ Cache Management
→ Flush Cache Storage
Voila, you're all set. You'll notice if you re-run the indexer, the table should stay constant in size (unless you've added more products inbetween or if you have duplicate category names).
5
Great, my core_url_rewrite table was 3.2 GB now is 36.8 MB :D by muppet
– Fabian Blechschmidt
Jul 24 '14 at 10:40
I have a similar problem. Magento URL rewrite append random number in Url. Please look at the screenshot attached from google web master tools. As you can see the product "Beige Embroidered Wedding Saree" has nine different URL's but the it is only one product and pointing to only one URL ending with 878. The actual URL key doesn't have a random number in the end(screenshot attached). My store is fairly a new one and the size of core_url_rewrite is not that big. So I am not sure if I should go ahead and do Step 1 & 2 or Only Step 1. If I perform step 2 I will lose my custom rewrites.
– Zoya
May 25 '15 at 9:28
I am running 1.9.1 and here are missed screenshot urls. monosnap.com/image/duL0f64WWlACtlt9kcn04BWqY3L5Xl monosnap.com/image/osFk8kYNAr00XLdFTGTIOaydaW5yqS
– Zoya
May 25 '15 at 9:31
2
I would export the existing table first. Then I would proceed with steps 1, 2 and 3. Take a look atcore_url_rewrite
table now and note down the number of records. Run step 3 again (the re-indexing), and refresh your view on thecore_url_rewrite
table. If the number is the same, you've resolved successfully. Then go ahead and manually merge your custom rewrites. All the best.
– Moose
May 25 '15 at 9:39
2
This fix only works for products, not for categories with identical URL keys. See @Simon s' answer for a better solution (with the patch file)
– Giel Berkers
Jun 25 '15 at 12:22
|
show 2 more comments
I've managed to stabalize the issue as follows:
Step 1: Rewrite the Catalog URL model (Using your own module: How To)
Note: If you overwrite the core file without using a rewrite this will
render your instance of Magento incapable of future upgrades.
As per Jahnni's solution on the MagentoCommerce boards (no longer active with new board), app/code/core/Mage/Catalog/Model/Url.php
[ around line 807 Mage_Catalog_Model_Url::getProductRequestPath()
]
From:
if ($product->getUrlKey() == '' && !empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
To:
if (!empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
Step 2: Truncate
Truncate the core_url_rewrite
table
Step 3: Reindex & Flush Caches
Initiate the re-indexing process on Core URL Rewrites.
Thereafter, you'll want to flush the Magento cache & storage cache.
System
→ Cache Management
→ Flush Magento Cache
System
→ Cache Management
→ Flush Cache Storage
Voila, you're all set. You'll notice if you re-run the indexer, the table should stay constant in size (unless you've added more products inbetween or if you have duplicate category names).
I've managed to stabalize the issue as follows:
Step 1: Rewrite the Catalog URL model (Using your own module: How To)
Note: If you overwrite the core file without using a rewrite this will
render your instance of Magento incapable of future upgrades.
As per Jahnni's solution on the MagentoCommerce boards (no longer active with new board), app/code/core/Mage/Catalog/Model/Url.php
[ around line 807 Mage_Catalog_Model_Url::getProductRequestPath()
]
From:
if ($product->getUrlKey() == '' && !empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
To:
if (!empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
Step 2: Truncate
Truncate the core_url_rewrite
table
Step 3: Reindex & Flush Caches
Initiate the re-indexing process on Core URL Rewrites.
Thereafter, you'll want to flush the Magento cache & storage cache.
System
→ Cache Management
→ Flush Magento Cache
System
→ Cache Management
→ Flush Cache Storage
Voila, you're all set. You'll notice if you re-run the indexer, the table should stay constant in size (unless you've added more products inbetween or if you have duplicate category names).
edited Mar 16 '17 at 8:07
Fra
4,575115194
4,575115194
answered Apr 22 '14 at 7:51
MooseMoose
5,69563979
5,69563979
5
Great, my core_url_rewrite table was 3.2 GB now is 36.8 MB :D by muppet
– Fabian Blechschmidt
Jul 24 '14 at 10:40
I have a similar problem. Magento URL rewrite append random number in Url. Please look at the screenshot attached from google web master tools. As you can see the product "Beige Embroidered Wedding Saree" has nine different URL's but the it is only one product and pointing to only one URL ending with 878. The actual URL key doesn't have a random number in the end(screenshot attached). My store is fairly a new one and the size of core_url_rewrite is not that big. So I am not sure if I should go ahead and do Step 1 & 2 or Only Step 1. If I perform step 2 I will lose my custom rewrites.
– Zoya
May 25 '15 at 9:28
I am running 1.9.1 and here are missed screenshot urls. monosnap.com/image/duL0f64WWlACtlt9kcn04BWqY3L5Xl monosnap.com/image/osFk8kYNAr00XLdFTGTIOaydaW5yqS
– Zoya
May 25 '15 at 9:31
2
I would export the existing table first. Then I would proceed with steps 1, 2 and 3. Take a look atcore_url_rewrite
table now and note down the number of records. Run step 3 again (the re-indexing), and refresh your view on thecore_url_rewrite
table. If the number is the same, you've resolved successfully. Then go ahead and manually merge your custom rewrites. All the best.
– Moose
May 25 '15 at 9:39
2
This fix only works for products, not for categories with identical URL keys. See @Simon s' answer for a better solution (with the patch file)
– Giel Berkers
Jun 25 '15 at 12:22
|
show 2 more comments
5
Great, my core_url_rewrite table was 3.2 GB now is 36.8 MB :D by muppet
– Fabian Blechschmidt
Jul 24 '14 at 10:40
I have a similar problem. Magento URL rewrite append random number in Url. Please look at the screenshot attached from google web master tools. As you can see the product "Beige Embroidered Wedding Saree" has nine different URL's but the it is only one product and pointing to only one URL ending with 878. The actual URL key doesn't have a random number in the end(screenshot attached). My store is fairly a new one and the size of core_url_rewrite is not that big. So I am not sure if I should go ahead and do Step 1 & 2 or Only Step 1. If I perform step 2 I will lose my custom rewrites.
– Zoya
May 25 '15 at 9:28
I am running 1.9.1 and here are missed screenshot urls. monosnap.com/image/duL0f64WWlACtlt9kcn04BWqY3L5Xl monosnap.com/image/osFk8kYNAr00XLdFTGTIOaydaW5yqS
– Zoya
May 25 '15 at 9:31
2
I would export the existing table first. Then I would proceed with steps 1, 2 and 3. Take a look atcore_url_rewrite
table now and note down the number of records. Run step 3 again (the re-indexing), and refresh your view on thecore_url_rewrite
table. If the number is the same, you've resolved successfully. Then go ahead and manually merge your custom rewrites. All the best.
– Moose
May 25 '15 at 9:39
2
This fix only works for products, not for categories with identical URL keys. See @Simon s' answer for a better solution (with the patch file)
– Giel Berkers
Jun 25 '15 at 12:22
5
5
Great, my core_url_rewrite table was 3.2 GB now is 36.8 MB :D by muppet
– Fabian Blechschmidt
Jul 24 '14 at 10:40
Great, my core_url_rewrite table was 3.2 GB now is 36.8 MB :D by muppet
– Fabian Blechschmidt
Jul 24 '14 at 10:40
I have a similar problem. Magento URL rewrite append random number in Url. Please look at the screenshot attached from google web master tools. As you can see the product "Beige Embroidered Wedding Saree" has nine different URL's but the it is only one product and pointing to only one URL ending with 878. The actual URL key doesn't have a random number in the end(screenshot attached). My store is fairly a new one and the size of core_url_rewrite is not that big. So I am not sure if I should go ahead and do Step 1 & 2 or Only Step 1. If I perform step 2 I will lose my custom rewrites.
– Zoya
May 25 '15 at 9:28
I have a similar problem. Magento URL rewrite append random number in Url. Please look at the screenshot attached from google web master tools. As you can see the product "Beige Embroidered Wedding Saree" has nine different URL's but the it is only one product and pointing to only one URL ending with 878. The actual URL key doesn't have a random number in the end(screenshot attached). My store is fairly a new one and the size of core_url_rewrite is not that big. So I am not sure if I should go ahead and do Step 1 & 2 or Only Step 1. If I perform step 2 I will lose my custom rewrites.
– Zoya
May 25 '15 at 9:28
I am running 1.9.1 and here are missed screenshot urls. monosnap.com/image/duL0f64WWlACtlt9kcn04BWqY3L5Xl monosnap.com/image/osFk8kYNAr00XLdFTGTIOaydaW5yqS
– Zoya
May 25 '15 at 9:31
I am running 1.9.1 and here are missed screenshot urls. monosnap.com/image/duL0f64WWlACtlt9kcn04BWqY3L5Xl monosnap.com/image/osFk8kYNAr00XLdFTGTIOaydaW5yqS
– Zoya
May 25 '15 at 9:31
2
2
I would export the existing table first. Then I would proceed with steps 1, 2 and 3. Take a look at
core_url_rewrite
table now and note down the number of records. Run step 3 again (the re-indexing), and refresh your view on the core_url_rewrite
table. If the number is the same, you've resolved successfully. Then go ahead and manually merge your custom rewrites. All the best.– Moose
May 25 '15 at 9:39
I would export the existing table first. Then I would proceed with steps 1, 2 and 3. Take a look at
core_url_rewrite
table now and note down the number of records. Run step 3 again (the re-indexing), and refresh your view on the core_url_rewrite
table. If the number is the same, you've resolved successfully. Then go ahead and manually merge your custom rewrites. All the best.– Moose
May 25 '15 at 9:39
2
2
This fix only works for products, not for categories with identical URL keys. See @Simon s' answer for a better solution (with the patch file)
– Giel Berkers
Jun 25 '15 at 12:22
This fix only works for products, not for categories with identical URL keys. See @Simon s' answer for a better solution (with the patch file)
– Giel Berkers
Jun 25 '15 at 12:22
|
show 2 more comments
While I hope someone here comes up with an answer, I don't know that you'll find one. This table gets bulky for a lot of different reasons. Bugs in earlier (and possibly current) versions of Magento is one. Another is there's logic in this table that tries to track changes to the URL key value so that 301/302 rewrites are setup for old products. Because of this, and complicating things, truncating the table and regenerating may make existing URL rewrites go away, and this will have an unknown effect on your search engine listing (not necessity bad, just hard to predict).
My general advice to clients who ask is
Leave the giant growing table as is if you don't have a good handle on your URL/SEO situation
Until the table size starts being a problem (generating site maps, for example). When that happens, get a handle on your URL/SEO situation.
Once you have a handle on your URL/SEO situation, backup the table, then truncate the table and regenerate. Address any URL/SEO problems caused by the truncating.
Automate step 3
Trying to fix this on the Magento code level is admirable, but you'll be swimming upstream. Sometimes it's better to accept that "That's just Magento being Magento", and to solve the problem with and external process.
thanks for the advice, it's a pity about the situation but I do think that it is going to have to be handled by an external process as you mentioned, urgh.
– Moose
Mar 31 '14 at 5:40
2
This giant table can already cause SEO problems, as the canonical for a given product will change constantly. If you have a seperate storeview for mobile and desktop, then it's even worse as their URLs will differ.
– Melvyn
Mar 28 '15 at 17:48
A bit disappointing answer to me ...
– Fra
Mar 16 '17 at 8:13
@Alan Storm, how do you feel about the answer posted by Moose after you posted this answer? Do you see the same risks?
– Goose
Feb 9 '18 at 12:55
add a comment |
While I hope someone here comes up with an answer, I don't know that you'll find one. This table gets bulky for a lot of different reasons. Bugs in earlier (and possibly current) versions of Magento is one. Another is there's logic in this table that tries to track changes to the URL key value so that 301/302 rewrites are setup for old products. Because of this, and complicating things, truncating the table and regenerating may make existing URL rewrites go away, and this will have an unknown effect on your search engine listing (not necessity bad, just hard to predict).
My general advice to clients who ask is
Leave the giant growing table as is if you don't have a good handle on your URL/SEO situation
Until the table size starts being a problem (generating site maps, for example). When that happens, get a handle on your URL/SEO situation.
Once you have a handle on your URL/SEO situation, backup the table, then truncate the table and regenerate. Address any URL/SEO problems caused by the truncating.
Automate step 3
Trying to fix this on the Magento code level is admirable, but you'll be swimming upstream. Sometimes it's better to accept that "That's just Magento being Magento", and to solve the problem with and external process.
thanks for the advice, it's a pity about the situation but I do think that it is going to have to be handled by an external process as you mentioned, urgh.
– Moose
Mar 31 '14 at 5:40
2
This giant table can already cause SEO problems, as the canonical for a given product will change constantly. If you have a seperate storeview for mobile and desktop, then it's even worse as their URLs will differ.
– Melvyn
Mar 28 '15 at 17:48
A bit disappointing answer to me ...
– Fra
Mar 16 '17 at 8:13
@Alan Storm, how do you feel about the answer posted by Moose after you posted this answer? Do you see the same risks?
– Goose
Feb 9 '18 at 12:55
add a comment |
While I hope someone here comes up with an answer, I don't know that you'll find one. This table gets bulky for a lot of different reasons. Bugs in earlier (and possibly current) versions of Magento is one. Another is there's logic in this table that tries to track changes to the URL key value so that 301/302 rewrites are setup for old products. Because of this, and complicating things, truncating the table and regenerating may make existing URL rewrites go away, and this will have an unknown effect on your search engine listing (not necessity bad, just hard to predict).
My general advice to clients who ask is
Leave the giant growing table as is if you don't have a good handle on your URL/SEO situation
Until the table size starts being a problem (generating site maps, for example). When that happens, get a handle on your URL/SEO situation.
Once you have a handle on your URL/SEO situation, backup the table, then truncate the table and regenerate. Address any URL/SEO problems caused by the truncating.
Automate step 3
Trying to fix this on the Magento code level is admirable, but you'll be swimming upstream. Sometimes it's better to accept that "That's just Magento being Magento", and to solve the problem with and external process.
While I hope someone here comes up with an answer, I don't know that you'll find one. This table gets bulky for a lot of different reasons. Bugs in earlier (and possibly current) versions of Magento is one. Another is there's logic in this table that tries to track changes to the URL key value so that 301/302 rewrites are setup for old products. Because of this, and complicating things, truncating the table and regenerating may make existing URL rewrites go away, and this will have an unknown effect on your search engine listing (not necessity bad, just hard to predict).
My general advice to clients who ask is
Leave the giant growing table as is if you don't have a good handle on your URL/SEO situation
Until the table size starts being a problem (generating site maps, for example). When that happens, get a handle on your URL/SEO situation.
Once you have a handle on your URL/SEO situation, backup the table, then truncate the table and regenerate. Address any URL/SEO problems caused by the truncating.
Automate step 3
Trying to fix this on the Magento code level is admirable, but you'll be swimming upstream. Sometimes it's better to accept that "That's just Magento being Magento", and to solve the problem with and external process.
edited Jan 2 '15 at 17:12
answered Mar 29 '14 at 21:09
Alan StormAlan Storm
29.3k22120309
29.3k22120309
thanks for the advice, it's a pity about the situation but I do think that it is going to have to be handled by an external process as you mentioned, urgh.
– Moose
Mar 31 '14 at 5:40
2
This giant table can already cause SEO problems, as the canonical for a given product will change constantly. If you have a seperate storeview for mobile and desktop, then it's even worse as their URLs will differ.
– Melvyn
Mar 28 '15 at 17:48
A bit disappointing answer to me ...
– Fra
Mar 16 '17 at 8:13
@Alan Storm, how do you feel about the answer posted by Moose after you posted this answer? Do you see the same risks?
– Goose
Feb 9 '18 at 12:55
add a comment |
thanks for the advice, it's a pity about the situation but I do think that it is going to have to be handled by an external process as you mentioned, urgh.
– Moose
Mar 31 '14 at 5:40
2
This giant table can already cause SEO problems, as the canonical for a given product will change constantly. If you have a seperate storeview for mobile and desktop, then it's even worse as their URLs will differ.
– Melvyn
Mar 28 '15 at 17:48
A bit disappointing answer to me ...
– Fra
Mar 16 '17 at 8:13
@Alan Storm, how do you feel about the answer posted by Moose after you posted this answer? Do you see the same risks?
– Goose
Feb 9 '18 at 12:55
thanks for the advice, it's a pity about the situation but I do think that it is going to have to be handled by an external process as you mentioned, urgh.
– Moose
Mar 31 '14 at 5:40
thanks for the advice, it's a pity about the situation but I do think that it is going to have to be handled by an external process as you mentioned, urgh.
– Moose
Mar 31 '14 at 5:40
2
2
This giant table can already cause SEO problems, as the canonical for a given product will change constantly. If you have a seperate storeview for mobile and desktop, then it's even worse as their URLs will differ.
– Melvyn
Mar 28 '15 at 17:48
This giant table can already cause SEO problems, as the canonical for a given product will change constantly. If you have a seperate storeview for mobile and desktop, then it's even worse as their URLs will differ.
– Melvyn
Mar 28 '15 at 17:48
A bit disappointing answer to me ...
– Fra
Mar 16 '17 at 8:13
A bit disappointing answer to me ...
– Fra
Mar 16 '17 at 8:13
@Alan Storm, how do you feel about the answer posted by Moose after you posted this answer? Do you see the same risks?
– Goose
Feb 9 '18 at 12:55
@Alan Storm, how do you feel about the answer posted by Moose after you posted this answer? Do you see the same risks?
– Goose
Feb 9 '18 at 12:55
add a comment |
I would like to add a fix for this url rewrite indexer bug which has been developed at the bugathon in March 2013 and which has been further improved afterwards. It should solve this issue. As a reference, here is the patch file from the link:
diff -rupN mage_org/app/code/core/Mage/Catalog/Model/Url.php src_shop/app/code/core/Mage/Catalog/Model/Url.php
--- mage_org/app/code/core/Mage/Catalog/Model/Url.php 2013-11-19 00:48:25.679009391 +0100
+++ src_shop/app/code/core/Mage/Catalog/Model/Url.php 2013-11-19 00:49:24.188005601 +0100
@@ -643,13 +643,24 @@ class Mage_Catalog_Model_Url
$this->_rewrite = $rewrite;
return $requestPath;
}
+
+ // avoid unnecessary creation of new url_keys for duplicate url keys
+ $noSuffixPath = substr($requestPath, 0, -(strlen($suffix)));
+ $regEx = '#^('.preg_quote($noSuffixPath).')(-([0-9]+))?('.preg_quote($suffix).')#i';
+ $currentRewrite = $this->getResource()->getRewriteByIdPath($idPath, $storeId);
+ if ($currentRewrite && preg_match($regEx, $currentRewrite->getRequestPath(), $match))
+ $this->_rewrite = $currentRewrite;
+ return $currentRewrite->getRequestPath();
+
+
// match request_url abcdef1234(-12)(.html) pattern
$match = array();
$regularExpression = '#^([0-9a-z/-]+?)(-([0-9]+))?('.preg_quote($suffix).')?$#i';
if (!preg_match($regularExpression, $requestPath, $match))
return $this->getUnusedPath($storeId, '-', $idPath);
- $match[1] = $match[1] . '-';
+ $match[1] = $noSuffixPath . '-'; // always use full prefix of url_key
+ unset($match[3]); // don't start counting with a possible number in the url_key
$match[4] = isset($match[4]) ? $match[4] : '';
$lastRequestPath = $this->getResource()
Additionally, I would like to add the EE patch PATCH_SUPEE-389_EE_1.12.0.2_v2.sh
, which is now available on GitHub:
#!/bin/bash
# Patch apllying tool template
# v0.1.2
# (c) Copyright 2013. Magento Inc.
#
# DO NOT CHANGE ANY LINE IN THIS FILE.
# 1. Check required system tools
_check_installed_tools()
local missed=""
until [ -z "$1" ]; do
type -t $1 >/dev/null 2>/dev/null
if (( $? != 0 )); then
missed="$missed $1"
fi
shift
done
echo $missed
REQUIRED_UTILS='sed patch'
MISSED_REQUIRED_TOOLS=`_check_installed_tools $REQUIRED_UTILS`
if (( `echo $MISSED_REQUIRED_TOOLS | wc -w` > 0 ));
then
echo -e "Error! Some required system tools, that are utilized in this sh script, are not installed:nTool(s) "$MISSED_REQUIRED_TOOLS" is(are) missed, please install it(them)."
exit 1
fi
# 2. Determine bin path for system tools
CAT_BIN=`which cat`
PATCH_BIN=`which patch`
SED_BIN=`which sed`
PWD_BIN=`which pwd`
BASENAME_BIN=`which basename`
BASE_NAME=`$BASENAME_BIN "$0"`
# 3. Help menu
if [ "$1" = "-?" -o "$1" = "-h" -o "$1" = "--help" ]
then
$CAT_BIN << EOFH
Usage: sh $BASE_NAME [--help] [-R|--revert] [--list]
Apply embedded patch.
-R, --revert Revert previously applied embedded patch
--list Show list of applied patches
--help Show this help message
EOFH
exit 0
fi
# 4. Get "revert" flag and "list applied patches" flag
REVERT_FLAG=
SHOW_APPLIED_LIST=0
if [ "$1" = "-R" -o "$1" = "--revert" ]
then
REVERT_FLAG=-R
fi
if [ "$1" = "--list" ]
then
SHOW_APPLIED_LIST=1
fi
# 5. File pathes
CURRENT_DIR=`$PWD_BIN`/
APP_ETC_DIR=`echo "$CURRENT_DIR""app/etc/"`
APPLIED_PATCHES_LIST_FILE=`echo "$APP_ETC_DIR""applied.patches.list"`
# 6. Show applied patches list if requested
if [ "$SHOW_APPLIED_LIST" -eq 1 ] ; then
echo -e "Applied/reverted patches list:"
if [ -e "$APPLIED_PATCHES_LIST_FILE" ]
then
if [ ! -r "$APPLIED_PATCHES_LIST_FILE" ]
then
echo "ERROR: "$APPLIED_PATCHES_LIST_FILE" must be readable so applied patches list can be shown."
exit 1
else
$SED_BIN -n "/SUP-|SUPEE-/p" $APPLIED_PATCHES_LIST_FILE
fi
else
echo "<empty>"
fi
exit 0
fi
# 7. Check applied patches track file and its directory
_check_files()
if [ ! -e "$APP_ETC_DIR" ]
then
echo "ERROR: "$APP_ETC_DIR" must exist for proper tool work."
exit 1
fi
if [ ! -w "$APP_ETC_DIR" ]
then
echo "ERROR: "$APP_ETC_DIR" must be writeable for proper tool work."
exit 1
fi
if [ -e "$APPLIED_PATCHES_LIST_FILE" ]
then
if [ ! -w "$APPLIED_PATCHES_LIST_FILE" ]
then
echo "ERROR: "$APPLIED_PATCHES_LIST_FILE" must be writeable for proper tool work."
exit 1
fi
fi
_check_files
# 8. Apply/revert patch
# Note: there is no need to check files permissions for files to be patched.
# "patch" tool will not modify any file if there is not enough permissions for all files to be modified.
# Get start points for additional information and patch data
SKIP_LINES=$((`$SED_BIN -n "/^__PATCHFILE_FOLLOWS__$/=" "$CURRENT_DIR""$BASE_NAME"` + 1))
ADDITIONAL_INFO_LINE=$(($SKIP_LINES - 3))p
_apply_revert_patch()
DRY_RUN_FLAG=
if [ "$1" = "dry-run" ]
then
DRY_RUN_FLAG=" --dry-run"
echo "Checking if patch can be applied/reverted successfully..."
fi
PATCH_APPLY_REVERT_RESULT=`$SED_BIN -e '1,/^__PATCHFILE_FOLLOWS__$/d' "$CURRENT_DIR""$BASE_NAME"
REVERTED_PATCH_MARK=
if [ -n "$REVERT_FLAG" ]
then
REVERTED_PATCH_MARK=" | REVERTED"
fi
_apply_revert_patch dry-run
_apply_revert_patch
# 9. Track patch applying result
echo "Patch was applied/reverted successfully."
ADDITIONAL_INFO=`$SED_BIN -n ""$ADDITIONAL_INFO_LINE"" "$CURRENT_DIR""$BASE_NAME"`
APPLIED_REVERTED_ON_DATE=`date -u +"%F %T UTC"`
APPLIED_REVERTED_PATCH_INFO=`echo -n "$APPLIED_REVERTED_ON_DATE"" | ""$ADDITIONAL_INFO""$REVERTED_PATCH_MARK"`
echo -e "$APPLIED_REVERTED_PATCH_INFOn$PATCH_APPLY_REVERT_RESULTnn" >> "$APPLIED_PATCHES_LIST_FILE"
exit 0
SUPEE-389 | EE_1.12.0.2 | v1 | 53c8ca52583358953b143aaa1a78cf409e8dd846 | Thu Jun 20 10:36:39 2013 +0300 | v1.12.0.2..HEAD
__PATCHFILE_FOLLOWS__
diff --git app/code/core/Mage/Catalog/Model/Url.php app/code/core/Mage/Catalog/Model/Url.php
index fa55fc5..a755b46 100644
--- app/code/core/Mage/Catalog/Model/Url.php
+++ app/code/core/Mage/Catalog/Model/Url.php
@@ -609,6 +609,23 @@ class Mage_Catalog_Model_Url
*/
public function getUnusedPath($storeId, $requestPath, $idPath)
+ $urlKey = '';
+ return $this->getUnusedPathByUrlkey($storeId, $requestPath, $idPath, $urlKey);
+
+
+ /**
+ * Get requestPath that was not used yet.
+ *
+ * Will try to get unique path by adding -1 -2 etc. between url_key and optional url_suffix
+ *
+ * @param int $storeId
+ * @param string $requestPath
+ * @param string $idPath
+ * @param string $urlKey
+ * @return string
+ */
+ public function getUnusedPathByUrlkey($storeId, $requestPath, $idPath, $urlKey = '')
+
if (strpos($idPath, 'product') !== false)
$suffix = $this->getProductUrlSuffix($storeId);
else
@@ -645,21 +662,22 @@ class Mage_Catalog_Model_Url
// match request_url abcdef1234(-12)(.html) pattern
$match = array();
- $regularExpression = '#^([0-9a-z/-]+?)(-([0-9]+))?('.preg_quote($suffix).')?$#i';
+ $regularExpression = '#(?P<prefix>(.*/)?' . preg_quote($urlKey) . ')(-(?P<increment>[0-9]+))?(?P<suffix>'
+ . preg_quote($suffix) . ')?$#i';
if (!preg_match($regularExpression, $requestPath, $match))
- return $this->getUnusedPath($storeId, '-', $idPath);
+ return $this->getUnusedPathByUrlkey($storeId, '-', $idPath, $urlKey);
- $match[1] = $match[1] . '-';
- $match[4] = isset($match[4]) ? $match[4] : '';
+ $match['prefix'] = $match['prefix'] . '-';
+ $match['suffix'] = isset($match['suffix']) ? $match['suffix'] : '';
$lastRequestPath = $this->getResource()
- ->getLastUsedRewriteRequestIncrement($match[1], $match[4], $storeId);
+ ->getLastUsedRewriteRequestIncrement($match['prefix'], $match['suffix'], $storeId);
if ($lastRequestPath)
- $match[3] = $lastRequestPath;
+ $match['increment'] = $lastRequestPath;
- return $match[1]
- . (isset($match[3]) ? ($match[3]+1) : '1')
- . $match[4];
+ return $match['prefix']
+ . (isset($match['increment']) ? ($match['increment']+1) : '1')
+ . $match['suffix'];
else
return $requestPath;
@@ -699,7 +717,7 @@ class Mage_Catalog_Model_Url
$storeId = $category->getStoreId();
$idPath = $this->generatePath('id', null, $category);
- $suffix = $this->getCategoryUrlSuffix($storeId);
+ $categoryUrlSuffix = $this->getCategoryUrlSuffix($storeId);
if (isset($this->_rewrites[$idPath]))
$this->_rewrite = $this->_rewrites[$idPath];
@@ -713,27 +731,27 @@ class Mage_Catalog_Model_Url
$urlKey = $this->getCategoryModel()->formatUrlKey($category->getUrlKey());
- $categoryUrlSuffix = $this->getCategoryUrlSuffix($category->getStoreId());
if (null === $parentPath)
$parentPath = $this->getResource()->getCategoryParentPath($category);
elseif ($parentPath == '/')
$parentPath = '';
- $parentPath = Mage::helper('catalog/category')->getCategoryUrlPath($parentPath,
- true, $category->getStoreId());
+ $parentPath = Mage::helper('catalog/category')->getCategoryUrlPath($parentPath, true, $storeId);
- $requestPath = $parentPath . $urlKey . $categoryUrlSuffix;
- if (isset($existingRequestPath) && $existingRequestPath == $requestPath . $suffix)
+ $requestPath = $parentPath . $urlKey;
+ $regexp = '/^' . preg_quote($requestPath, '/') . '(-[0-9]+)?' . preg_quote($categoryUrlSuffix, '/') . '$/i';
+ if (isset($existingRequestPath) && preg_match($regexp, $existingRequestPath))
return $existingRequestPath;
- if ($this->_deleteOldTargetPath($requestPath, $idPath, $storeId))
+ $fullPath = $requestPath . $categoryUrlSuffix;
+ if ($this->_deleteOldTargetPath($fullPath, $idPath, $storeId))
return $requestPath;
- return $this->getUnusedPath($category->getStoreId(), $requestPath,
- $this->generatePath('id', null, $category)
+ return $this->getUnusedPathByUrlkey($storeId, $fullPath,
+ $this->generatePath('id', null, $category), $urlKey
);
@@ -798,7 +816,8 @@ class Mage_Catalog_Model_Url
$this->_rewrite = $this->_rewrites[$idPath];
$existingRequestPath = $this->_rewrites[$idPath]->getRequestPath();
- if ($existingRequestPath == $requestPath . $suffix)
+ $regexp = '/^' . preg_quote($requestPath, '/') . '(-[0-9]+)?' . preg_quote($suffix, '/') . '$/i';
+ if (preg_match($regexp, $existingRequestPath))
return $existingRequestPath;
@@ -836,7 +855,7 @@ class Mage_Catalog_Model_Url
/**
* Use unique path generator
*/
- return $this->getUnusedPath($storeId, $requestPath.$suffix, $idPath);
+ return $this->getUnusedPathByUrlkey($storeId, $requestPath.$suffix, $idPath, $urlKey);
/**
@@ -891,8 +910,8 @@ class Mage_Catalog_Model_Url
$parentPath = Mage::helper('catalog/category')->getCategoryUrlPath($parentPath,
true, $category->getStoreId());
- return $this->getUnusedPath($category->getStoreId(), $parentPath . $urlKey . $categoryUrlSuffix,
- $this->generatePath('id', null, $category)
+ return $this->getUnusedPathByUrlkey($category->getStoreId(), $parentPath . $urlKey . $categoryUrlSuffix,
+ $this->generatePath('id', null, $category), $urlKey
);
@@ -913,14 +932,14 @@ class Mage_Catalog_Model_Url
$this->_addCategoryUrlPath($category);
$categoryUrl = Mage::helper('catalog/category')->getCategoryUrlPath($category->getUrlPath(),
false, $category->getStoreId());
- return $this->getUnusedPath($category->getStoreId(), $categoryUrl . '/' . $urlKey . $productUrlSuffix,
- $this->generatePath('id', $product, $category)
+ return $this->getUnusedPathByUrlkey($category->getStoreId(), $categoryUrl . '/' . $urlKey . $productUrlSuffix,
+ $this->generatePath('id', $product, $category), $urlKey
);
// for product only
- return $this->getUnusedPath($category->getStoreId(), $urlKey . $productUrlSuffix,
- $this->generatePath('id', $product)
+ return $this->getUnusedPathByUrlkey($category->getStoreId(), $urlKey . $productUrlSuffix,
+ $this->generatePath('id', $product), $urlKey
);
If you want to use this patch with CE, make sure to test it properly, because it has been developed for EE.
Have you yourself tested this EE patch on CE?
– Tyler V.
Mar 19 '15 at 18:14
@TylerV. Nope...
– Simon
Mar 20 '15 at 13:22
3
I've tried this patch in EE 1.9.1.1 and can conform it works. It fixes the problem with products and categories with identical url keys. Let's hope they implement this in a future release soon.
– Giel Berkers
Jun 25 '15 at 12:21
1
Thanks Simon, just went from 1GB to 3MB on one clients website... Had to truncate it before every 6 months, hope it will remain small now:)
– willem wigman
Aug 10 '15 at 12:46
1
I've just tried this on my 1.9 CE and although it works for products - the categories are not quite right. If I have a category called 'Test' which gives the url '.../test' and then I create another called 'Test' it should give the url '.../test-2' but instead gives just the number not the name: '.../-2'
– odd_duck
Aug 26 '16 at 15:41
|
show 3 more comments
I would like to add a fix for this url rewrite indexer bug which has been developed at the bugathon in March 2013 and which has been further improved afterwards. It should solve this issue. As a reference, here is the patch file from the link:
diff -rupN mage_org/app/code/core/Mage/Catalog/Model/Url.php src_shop/app/code/core/Mage/Catalog/Model/Url.php
--- mage_org/app/code/core/Mage/Catalog/Model/Url.php 2013-11-19 00:48:25.679009391 +0100
+++ src_shop/app/code/core/Mage/Catalog/Model/Url.php 2013-11-19 00:49:24.188005601 +0100
@@ -643,13 +643,24 @@ class Mage_Catalog_Model_Url
$this->_rewrite = $rewrite;
return $requestPath;
}
+
+ // avoid unnecessary creation of new url_keys for duplicate url keys
+ $noSuffixPath = substr($requestPath, 0, -(strlen($suffix)));
+ $regEx = '#^('.preg_quote($noSuffixPath).')(-([0-9]+))?('.preg_quote($suffix).')#i';
+ $currentRewrite = $this->getResource()->getRewriteByIdPath($idPath, $storeId);
+ if ($currentRewrite && preg_match($regEx, $currentRewrite->getRequestPath(), $match))
+ $this->_rewrite = $currentRewrite;
+ return $currentRewrite->getRequestPath();
+
+
// match request_url abcdef1234(-12)(.html) pattern
$match = array();
$regularExpression = '#^([0-9a-z/-]+?)(-([0-9]+))?('.preg_quote($suffix).')?$#i';
if (!preg_match($regularExpression, $requestPath, $match))
return $this->getUnusedPath($storeId, '-', $idPath);
- $match[1] = $match[1] . '-';
+ $match[1] = $noSuffixPath . '-'; // always use full prefix of url_key
+ unset($match[3]); // don't start counting with a possible number in the url_key
$match[4] = isset($match[4]) ? $match[4] : '';
$lastRequestPath = $this->getResource()
Additionally, I would like to add the EE patch PATCH_SUPEE-389_EE_1.12.0.2_v2.sh
, which is now available on GitHub:
#!/bin/bash
# Patch apllying tool template
# v0.1.2
# (c) Copyright 2013. Magento Inc.
#
# DO NOT CHANGE ANY LINE IN THIS FILE.
# 1. Check required system tools
_check_installed_tools()
local missed=""
until [ -z "$1" ]; do
type -t $1 >/dev/null 2>/dev/null
if (( $? != 0 )); then
missed="$missed $1"
fi
shift
done
echo $missed
REQUIRED_UTILS='sed patch'
MISSED_REQUIRED_TOOLS=`_check_installed_tools $REQUIRED_UTILS`
if (( `echo $MISSED_REQUIRED_TOOLS | wc -w` > 0 ));
then
echo -e "Error! Some required system tools, that are utilized in this sh script, are not installed:nTool(s) "$MISSED_REQUIRED_TOOLS" is(are) missed, please install it(them)."
exit 1
fi
# 2. Determine bin path for system tools
CAT_BIN=`which cat`
PATCH_BIN=`which patch`
SED_BIN=`which sed`
PWD_BIN=`which pwd`
BASENAME_BIN=`which basename`
BASE_NAME=`$BASENAME_BIN "$0"`
# 3. Help menu
if [ "$1" = "-?" -o "$1" = "-h" -o "$1" = "--help" ]
then
$CAT_BIN << EOFH
Usage: sh $BASE_NAME [--help] [-R|--revert] [--list]
Apply embedded patch.
-R, --revert Revert previously applied embedded patch
--list Show list of applied patches
--help Show this help message
EOFH
exit 0
fi
# 4. Get "revert" flag and "list applied patches" flag
REVERT_FLAG=
SHOW_APPLIED_LIST=0
if [ "$1" = "-R" -o "$1" = "--revert" ]
then
REVERT_FLAG=-R
fi
if [ "$1" = "--list" ]
then
SHOW_APPLIED_LIST=1
fi
# 5. File pathes
CURRENT_DIR=`$PWD_BIN`/
APP_ETC_DIR=`echo "$CURRENT_DIR""app/etc/"`
APPLIED_PATCHES_LIST_FILE=`echo "$APP_ETC_DIR""applied.patches.list"`
# 6. Show applied patches list if requested
if [ "$SHOW_APPLIED_LIST" -eq 1 ] ; then
echo -e "Applied/reverted patches list:"
if [ -e "$APPLIED_PATCHES_LIST_FILE" ]
then
if [ ! -r "$APPLIED_PATCHES_LIST_FILE" ]
then
echo "ERROR: "$APPLIED_PATCHES_LIST_FILE" must be readable so applied patches list can be shown."
exit 1
else
$SED_BIN -n "/SUP-|SUPEE-/p" $APPLIED_PATCHES_LIST_FILE
fi
else
echo "<empty>"
fi
exit 0
fi
# 7. Check applied patches track file and its directory
_check_files()
if [ ! -e "$APP_ETC_DIR" ]
then
echo "ERROR: "$APP_ETC_DIR" must exist for proper tool work."
exit 1
fi
if [ ! -w "$APP_ETC_DIR" ]
then
echo "ERROR: "$APP_ETC_DIR" must be writeable for proper tool work."
exit 1
fi
if [ -e "$APPLIED_PATCHES_LIST_FILE" ]
then
if [ ! -w "$APPLIED_PATCHES_LIST_FILE" ]
then
echo "ERROR: "$APPLIED_PATCHES_LIST_FILE" must be writeable for proper tool work."
exit 1
fi
fi
_check_files
# 8. Apply/revert patch
# Note: there is no need to check files permissions for files to be patched.
# "patch" tool will not modify any file if there is not enough permissions for all files to be modified.
# Get start points for additional information and patch data
SKIP_LINES=$((`$SED_BIN -n "/^__PATCHFILE_FOLLOWS__$/=" "$CURRENT_DIR""$BASE_NAME"` + 1))
ADDITIONAL_INFO_LINE=$(($SKIP_LINES - 3))p
_apply_revert_patch()
DRY_RUN_FLAG=
if [ "$1" = "dry-run" ]
then
DRY_RUN_FLAG=" --dry-run"
echo "Checking if patch can be applied/reverted successfully..."
fi
PATCH_APPLY_REVERT_RESULT=`$SED_BIN -e '1,/^__PATCHFILE_FOLLOWS__$/d' "$CURRENT_DIR""$BASE_NAME"
REVERTED_PATCH_MARK=
if [ -n "$REVERT_FLAG" ]
then
REVERTED_PATCH_MARK=" | REVERTED"
fi
_apply_revert_patch dry-run
_apply_revert_patch
# 9. Track patch applying result
echo "Patch was applied/reverted successfully."
ADDITIONAL_INFO=`$SED_BIN -n ""$ADDITIONAL_INFO_LINE"" "$CURRENT_DIR""$BASE_NAME"`
APPLIED_REVERTED_ON_DATE=`date -u +"%F %T UTC"`
APPLIED_REVERTED_PATCH_INFO=`echo -n "$APPLIED_REVERTED_ON_DATE"" | ""$ADDITIONAL_INFO""$REVERTED_PATCH_MARK"`
echo -e "$APPLIED_REVERTED_PATCH_INFOn$PATCH_APPLY_REVERT_RESULTnn" >> "$APPLIED_PATCHES_LIST_FILE"
exit 0
SUPEE-389 | EE_1.12.0.2 | v1 | 53c8ca52583358953b143aaa1a78cf409e8dd846 | Thu Jun 20 10:36:39 2013 +0300 | v1.12.0.2..HEAD
__PATCHFILE_FOLLOWS__
diff --git app/code/core/Mage/Catalog/Model/Url.php app/code/core/Mage/Catalog/Model/Url.php
index fa55fc5..a755b46 100644
--- app/code/core/Mage/Catalog/Model/Url.php
+++ app/code/core/Mage/Catalog/Model/Url.php
@@ -609,6 +609,23 @@ class Mage_Catalog_Model_Url
*/
public function getUnusedPath($storeId, $requestPath, $idPath)
+ $urlKey = '';
+ return $this->getUnusedPathByUrlkey($storeId, $requestPath, $idPath, $urlKey);
+
+
+ /**
+ * Get requestPath that was not used yet.
+ *
+ * Will try to get unique path by adding -1 -2 etc. between url_key and optional url_suffix
+ *
+ * @param int $storeId
+ * @param string $requestPath
+ * @param string $idPath
+ * @param string $urlKey
+ * @return string
+ */
+ public function getUnusedPathByUrlkey($storeId, $requestPath, $idPath, $urlKey = '')
+
if (strpos($idPath, 'product') !== false)
$suffix = $this->getProductUrlSuffix($storeId);
else
@@ -645,21 +662,22 @@ class Mage_Catalog_Model_Url
// match request_url abcdef1234(-12)(.html) pattern
$match = array();
- $regularExpression = '#^([0-9a-z/-]+?)(-([0-9]+))?('.preg_quote($suffix).')?$#i';
+ $regularExpression = '#(?P<prefix>(.*/)?' . preg_quote($urlKey) . ')(-(?P<increment>[0-9]+))?(?P<suffix>'
+ . preg_quote($suffix) . ')?$#i';
if (!preg_match($regularExpression, $requestPath, $match))
- return $this->getUnusedPath($storeId, '-', $idPath);
+ return $this->getUnusedPathByUrlkey($storeId, '-', $idPath, $urlKey);
- $match[1] = $match[1] . '-';
- $match[4] = isset($match[4]) ? $match[4] : '';
+ $match['prefix'] = $match['prefix'] . '-';
+ $match['suffix'] = isset($match['suffix']) ? $match['suffix'] : '';
$lastRequestPath = $this->getResource()
- ->getLastUsedRewriteRequestIncrement($match[1], $match[4], $storeId);
+ ->getLastUsedRewriteRequestIncrement($match['prefix'], $match['suffix'], $storeId);
if ($lastRequestPath)
- $match[3] = $lastRequestPath;
+ $match['increment'] = $lastRequestPath;
- return $match[1]
- . (isset($match[3]) ? ($match[3]+1) : '1')
- . $match[4];
+ return $match['prefix']
+ . (isset($match['increment']) ? ($match['increment']+1) : '1')
+ . $match['suffix'];
else
return $requestPath;
@@ -699,7 +717,7 @@ class Mage_Catalog_Model_Url
$storeId = $category->getStoreId();
$idPath = $this->generatePath('id', null, $category);
- $suffix = $this->getCategoryUrlSuffix($storeId);
+ $categoryUrlSuffix = $this->getCategoryUrlSuffix($storeId);
if (isset($this->_rewrites[$idPath]))
$this->_rewrite = $this->_rewrites[$idPath];
@@ -713,27 +731,27 @@ class Mage_Catalog_Model_Url
$urlKey = $this->getCategoryModel()->formatUrlKey($category->getUrlKey());
- $categoryUrlSuffix = $this->getCategoryUrlSuffix($category->getStoreId());
if (null === $parentPath)
$parentPath = $this->getResource()->getCategoryParentPath($category);
elseif ($parentPath == '/')
$parentPath = '';
- $parentPath = Mage::helper('catalog/category')->getCategoryUrlPath($parentPath,
- true, $category->getStoreId());
+ $parentPath = Mage::helper('catalog/category')->getCategoryUrlPath($parentPath, true, $storeId);
- $requestPath = $parentPath . $urlKey . $categoryUrlSuffix;
- if (isset($existingRequestPath) && $existingRequestPath == $requestPath . $suffix)
+ $requestPath = $parentPath . $urlKey;
+ $regexp = '/^' . preg_quote($requestPath, '/') . '(-[0-9]+)?' . preg_quote($categoryUrlSuffix, '/') . '$/i';
+ if (isset($existingRequestPath) && preg_match($regexp, $existingRequestPath))
return $existingRequestPath;
- if ($this->_deleteOldTargetPath($requestPath, $idPath, $storeId))
+ $fullPath = $requestPath . $categoryUrlSuffix;
+ if ($this->_deleteOldTargetPath($fullPath, $idPath, $storeId))
return $requestPath;
- return $this->getUnusedPath($category->getStoreId(), $requestPath,
- $this->generatePath('id', null, $category)
+ return $this->getUnusedPathByUrlkey($storeId, $fullPath,
+ $this->generatePath('id', null, $category), $urlKey
);
@@ -798,7 +816,8 @@ class Mage_Catalog_Model_Url
$this->_rewrite = $this->_rewrites[$idPath];
$existingRequestPath = $this->_rewrites[$idPath]->getRequestPath();
- if ($existingRequestPath == $requestPath . $suffix)
+ $regexp = '/^' . preg_quote($requestPath, '/') . '(-[0-9]+)?' . preg_quote($suffix, '/') . '$/i';
+ if (preg_match($regexp, $existingRequestPath))
return $existingRequestPath;
@@ -836,7 +855,7 @@ class Mage_Catalog_Model_Url
/**
* Use unique path generator
*/
- return $this->getUnusedPath($storeId, $requestPath.$suffix, $idPath);
+ return $this->getUnusedPathByUrlkey($storeId, $requestPath.$suffix, $idPath, $urlKey);
/**
@@ -891,8 +910,8 @@ class Mage_Catalog_Model_Url
$parentPath = Mage::helper('catalog/category')->getCategoryUrlPath($parentPath,
true, $category->getStoreId());
- return $this->getUnusedPath($category->getStoreId(), $parentPath . $urlKey . $categoryUrlSuffix,
- $this->generatePath('id', null, $category)
+ return $this->getUnusedPathByUrlkey($category->getStoreId(), $parentPath . $urlKey . $categoryUrlSuffix,
+ $this->generatePath('id', null, $category), $urlKey
);
@@ -913,14 +932,14 @@ class Mage_Catalog_Model_Url
$this->_addCategoryUrlPath($category);
$categoryUrl = Mage::helper('catalog/category')->getCategoryUrlPath($category->getUrlPath(),
false, $category->getStoreId());
- return $this->getUnusedPath($category->getStoreId(), $categoryUrl . '/' . $urlKey . $productUrlSuffix,
- $this->generatePath('id', $product, $category)
+ return $this->getUnusedPathByUrlkey($category->getStoreId(), $categoryUrl . '/' . $urlKey . $productUrlSuffix,
+ $this->generatePath('id', $product, $category), $urlKey
);
// for product only
- return $this->getUnusedPath($category->getStoreId(), $urlKey . $productUrlSuffix,
- $this->generatePath('id', $product)
+ return $this->getUnusedPathByUrlkey($category->getStoreId(), $urlKey . $productUrlSuffix,
+ $this->generatePath('id', $product), $urlKey
);
If you want to use this patch with CE, make sure to test it properly, because it has been developed for EE.
Have you yourself tested this EE patch on CE?
– Tyler V.
Mar 19 '15 at 18:14
@TylerV. Nope...
– Simon
Mar 20 '15 at 13:22
3
I've tried this patch in EE 1.9.1.1 and can conform it works. It fixes the problem with products and categories with identical url keys. Let's hope they implement this in a future release soon.
– Giel Berkers
Jun 25 '15 at 12:21
1
Thanks Simon, just went from 1GB to 3MB on one clients website... Had to truncate it before every 6 months, hope it will remain small now:)
– willem wigman
Aug 10 '15 at 12:46
1
I've just tried this on my 1.9 CE and although it works for products - the categories are not quite right. If I have a category called 'Test' which gives the url '.../test' and then I create another called 'Test' it should give the url '.../test-2' but instead gives just the number not the name: '.../-2'
– odd_duck
Aug 26 '16 at 15:41
|
show 3 more comments
I would like to add a fix for this url rewrite indexer bug which has been developed at the bugathon in March 2013 and which has been further improved afterwards. It should solve this issue. As a reference, here is the patch file from the link:
diff -rupN mage_org/app/code/core/Mage/Catalog/Model/Url.php src_shop/app/code/core/Mage/Catalog/Model/Url.php
--- mage_org/app/code/core/Mage/Catalog/Model/Url.php 2013-11-19 00:48:25.679009391 +0100
+++ src_shop/app/code/core/Mage/Catalog/Model/Url.php 2013-11-19 00:49:24.188005601 +0100
@@ -643,13 +643,24 @@ class Mage_Catalog_Model_Url
$this->_rewrite = $rewrite;
return $requestPath;
}
+
+ // avoid unnecessary creation of new url_keys for duplicate url keys
+ $noSuffixPath = substr($requestPath, 0, -(strlen($suffix)));
+ $regEx = '#^('.preg_quote($noSuffixPath).')(-([0-9]+))?('.preg_quote($suffix).')#i';
+ $currentRewrite = $this->getResource()->getRewriteByIdPath($idPath, $storeId);
+ if ($currentRewrite && preg_match($regEx, $currentRewrite->getRequestPath(), $match))
+ $this->_rewrite = $currentRewrite;
+ return $currentRewrite->getRequestPath();
+
+
// match request_url abcdef1234(-12)(.html) pattern
$match = array();
$regularExpression = '#^([0-9a-z/-]+?)(-([0-9]+))?('.preg_quote($suffix).')?$#i';
if (!preg_match($regularExpression, $requestPath, $match))
return $this->getUnusedPath($storeId, '-', $idPath);
- $match[1] = $match[1] . '-';
+ $match[1] = $noSuffixPath . '-'; // always use full prefix of url_key
+ unset($match[3]); // don't start counting with a possible number in the url_key
$match[4] = isset($match[4]) ? $match[4] : '';
$lastRequestPath = $this->getResource()
Additionally, I would like to add the EE patch PATCH_SUPEE-389_EE_1.12.0.2_v2.sh
, which is now available on GitHub:
#!/bin/bash
# Patch apllying tool template
# v0.1.2
# (c) Copyright 2013. Magento Inc.
#
# DO NOT CHANGE ANY LINE IN THIS FILE.
# 1. Check required system tools
_check_installed_tools()
local missed=""
until [ -z "$1" ]; do
type -t $1 >/dev/null 2>/dev/null
if (( $? != 0 )); then
missed="$missed $1"
fi
shift
done
echo $missed
REQUIRED_UTILS='sed patch'
MISSED_REQUIRED_TOOLS=`_check_installed_tools $REQUIRED_UTILS`
if (( `echo $MISSED_REQUIRED_TOOLS | wc -w` > 0 ));
then
echo -e "Error! Some required system tools, that are utilized in this sh script, are not installed:nTool(s) "$MISSED_REQUIRED_TOOLS" is(are) missed, please install it(them)."
exit 1
fi
# 2. Determine bin path for system tools
CAT_BIN=`which cat`
PATCH_BIN=`which patch`
SED_BIN=`which sed`
PWD_BIN=`which pwd`
BASENAME_BIN=`which basename`
BASE_NAME=`$BASENAME_BIN "$0"`
# 3. Help menu
if [ "$1" = "-?" -o "$1" = "-h" -o "$1" = "--help" ]
then
$CAT_BIN << EOFH
Usage: sh $BASE_NAME [--help] [-R|--revert] [--list]
Apply embedded patch.
-R, --revert Revert previously applied embedded patch
--list Show list of applied patches
--help Show this help message
EOFH
exit 0
fi
# 4. Get "revert" flag and "list applied patches" flag
REVERT_FLAG=
SHOW_APPLIED_LIST=0
if [ "$1" = "-R" -o "$1" = "--revert" ]
then
REVERT_FLAG=-R
fi
if [ "$1" = "--list" ]
then
SHOW_APPLIED_LIST=1
fi
# 5. File pathes
CURRENT_DIR=`$PWD_BIN`/
APP_ETC_DIR=`echo "$CURRENT_DIR""app/etc/"`
APPLIED_PATCHES_LIST_FILE=`echo "$APP_ETC_DIR""applied.patches.list"`
# 6. Show applied patches list if requested
if [ "$SHOW_APPLIED_LIST" -eq 1 ] ; then
echo -e "Applied/reverted patches list:"
if [ -e "$APPLIED_PATCHES_LIST_FILE" ]
then
if [ ! -r "$APPLIED_PATCHES_LIST_FILE" ]
then
echo "ERROR: "$APPLIED_PATCHES_LIST_FILE" must be readable so applied patches list can be shown."
exit 1
else
$SED_BIN -n "/SUP-|SUPEE-/p" $APPLIED_PATCHES_LIST_FILE
fi
else
echo "<empty>"
fi
exit 0
fi
# 7. Check applied patches track file and its directory
_check_files()
if [ ! -e "$APP_ETC_DIR" ]
then
echo "ERROR: "$APP_ETC_DIR" must exist for proper tool work."
exit 1
fi
if [ ! -w "$APP_ETC_DIR" ]
then
echo "ERROR: "$APP_ETC_DIR" must be writeable for proper tool work."
exit 1
fi
if [ -e "$APPLIED_PATCHES_LIST_FILE" ]
then
if [ ! -w "$APPLIED_PATCHES_LIST_FILE" ]
then
echo "ERROR: "$APPLIED_PATCHES_LIST_FILE" must be writeable for proper tool work."
exit 1
fi
fi
_check_files
# 8. Apply/revert patch
# Note: there is no need to check files permissions for files to be patched.
# "patch" tool will not modify any file if there is not enough permissions for all files to be modified.
# Get start points for additional information and patch data
SKIP_LINES=$((`$SED_BIN -n "/^__PATCHFILE_FOLLOWS__$/=" "$CURRENT_DIR""$BASE_NAME"` + 1))
ADDITIONAL_INFO_LINE=$(($SKIP_LINES - 3))p
_apply_revert_patch()
DRY_RUN_FLAG=
if [ "$1" = "dry-run" ]
then
DRY_RUN_FLAG=" --dry-run"
echo "Checking if patch can be applied/reverted successfully..."
fi
PATCH_APPLY_REVERT_RESULT=`$SED_BIN -e '1,/^__PATCHFILE_FOLLOWS__$/d' "$CURRENT_DIR""$BASE_NAME"
REVERTED_PATCH_MARK=
if [ -n "$REVERT_FLAG" ]
then
REVERTED_PATCH_MARK=" | REVERTED"
fi
_apply_revert_patch dry-run
_apply_revert_patch
# 9. Track patch applying result
echo "Patch was applied/reverted successfully."
ADDITIONAL_INFO=`$SED_BIN -n ""$ADDITIONAL_INFO_LINE"" "$CURRENT_DIR""$BASE_NAME"`
APPLIED_REVERTED_ON_DATE=`date -u +"%F %T UTC"`
APPLIED_REVERTED_PATCH_INFO=`echo -n "$APPLIED_REVERTED_ON_DATE"" | ""$ADDITIONAL_INFO""$REVERTED_PATCH_MARK"`
echo -e "$APPLIED_REVERTED_PATCH_INFOn$PATCH_APPLY_REVERT_RESULTnn" >> "$APPLIED_PATCHES_LIST_FILE"
exit 0
SUPEE-389 | EE_1.12.0.2 | v1 | 53c8ca52583358953b143aaa1a78cf409e8dd846 | Thu Jun 20 10:36:39 2013 +0300 | v1.12.0.2..HEAD
__PATCHFILE_FOLLOWS__
diff --git app/code/core/Mage/Catalog/Model/Url.php app/code/core/Mage/Catalog/Model/Url.php
index fa55fc5..a755b46 100644
--- app/code/core/Mage/Catalog/Model/Url.php
+++ app/code/core/Mage/Catalog/Model/Url.php
@@ -609,6 +609,23 @@ class Mage_Catalog_Model_Url
*/
public function getUnusedPath($storeId, $requestPath, $idPath)
+ $urlKey = '';
+ return $this->getUnusedPathByUrlkey($storeId, $requestPath, $idPath, $urlKey);
+
+
+ /**
+ * Get requestPath that was not used yet.
+ *
+ * Will try to get unique path by adding -1 -2 etc. between url_key and optional url_suffix
+ *
+ * @param int $storeId
+ * @param string $requestPath
+ * @param string $idPath
+ * @param string $urlKey
+ * @return string
+ */
+ public function getUnusedPathByUrlkey($storeId, $requestPath, $idPath, $urlKey = '')
+
if (strpos($idPath, 'product') !== false)
$suffix = $this->getProductUrlSuffix($storeId);
else
@@ -645,21 +662,22 @@ class Mage_Catalog_Model_Url
// match request_url abcdef1234(-12)(.html) pattern
$match = array();
- $regularExpression = '#^([0-9a-z/-]+?)(-([0-9]+))?('.preg_quote($suffix).')?$#i';
+ $regularExpression = '#(?P<prefix>(.*/)?' . preg_quote($urlKey) . ')(-(?P<increment>[0-9]+))?(?P<suffix>'
+ . preg_quote($suffix) . ')?$#i';
if (!preg_match($regularExpression, $requestPath, $match))
- return $this->getUnusedPath($storeId, '-', $idPath);
+ return $this->getUnusedPathByUrlkey($storeId, '-', $idPath, $urlKey);
- $match[1] = $match[1] . '-';
- $match[4] = isset($match[4]) ? $match[4] : '';
+ $match['prefix'] = $match['prefix'] . '-';
+ $match['suffix'] = isset($match['suffix']) ? $match['suffix'] : '';
$lastRequestPath = $this->getResource()
- ->getLastUsedRewriteRequestIncrement($match[1], $match[4], $storeId);
+ ->getLastUsedRewriteRequestIncrement($match['prefix'], $match['suffix'], $storeId);
if ($lastRequestPath)
- $match[3] = $lastRequestPath;
+ $match['increment'] = $lastRequestPath;
- return $match[1]
- . (isset($match[3]) ? ($match[3]+1) : '1')
- . $match[4];
+ return $match['prefix']
+ . (isset($match['increment']) ? ($match['increment']+1) : '1')
+ . $match['suffix'];
else
return $requestPath;
@@ -699,7 +717,7 @@ class Mage_Catalog_Model_Url
$storeId = $category->getStoreId();
$idPath = $this->generatePath('id', null, $category);
- $suffix = $this->getCategoryUrlSuffix($storeId);
+ $categoryUrlSuffix = $this->getCategoryUrlSuffix($storeId);
if (isset($this->_rewrites[$idPath]))
$this->_rewrite = $this->_rewrites[$idPath];
@@ -713,27 +731,27 @@ class Mage_Catalog_Model_Url
$urlKey = $this->getCategoryModel()->formatUrlKey($category->getUrlKey());
- $categoryUrlSuffix = $this->getCategoryUrlSuffix($category->getStoreId());
if (null === $parentPath)
$parentPath = $this->getResource()->getCategoryParentPath($category);
elseif ($parentPath == '/')
$parentPath = '';
- $parentPath = Mage::helper('catalog/category')->getCategoryUrlPath($parentPath,
- true, $category->getStoreId());
+ $parentPath = Mage::helper('catalog/category')->getCategoryUrlPath($parentPath, true, $storeId);
- $requestPath = $parentPath . $urlKey . $categoryUrlSuffix;
- if (isset($existingRequestPath) && $existingRequestPath == $requestPath . $suffix)
+ $requestPath = $parentPath . $urlKey;
+ $regexp = '/^' . preg_quote($requestPath, '/') . '(-[0-9]+)?' . preg_quote($categoryUrlSuffix, '/') . '$/i';
+ if (isset($existingRequestPath) && preg_match($regexp, $existingRequestPath))
return $existingRequestPath;
- if ($this->_deleteOldTargetPath($requestPath, $idPath, $storeId))
+ $fullPath = $requestPath . $categoryUrlSuffix;
+ if ($this->_deleteOldTargetPath($fullPath, $idPath, $storeId))
return $requestPath;
- return $this->getUnusedPath($category->getStoreId(), $requestPath,
- $this->generatePath('id', null, $category)
+ return $this->getUnusedPathByUrlkey($storeId, $fullPath,
+ $this->generatePath('id', null, $category), $urlKey
);
@@ -798,7 +816,8 @@ class Mage_Catalog_Model_Url
$this->_rewrite = $this->_rewrites[$idPath];
$existingRequestPath = $this->_rewrites[$idPath]->getRequestPath();
- if ($existingRequestPath == $requestPath . $suffix)
+ $regexp = '/^' . preg_quote($requestPath, '/') . '(-[0-9]+)?' . preg_quote($suffix, '/') . '$/i';
+ if (preg_match($regexp, $existingRequestPath))
return $existingRequestPath;
@@ -836,7 +855,7 @@ class Mage_Catalog_Model_Url
/**
* Use unique path generator
*/
- return $this->getUnusedPath($storeId, $requestPath.$suffix, $idPath);
+ return $this->getUnusedPathByUrlkey($storeId, $requestPath.$suffix, $idPath, $urlKey);
/**
@@ -891,8 +910,8 @@ class Mage_Catalog_Model_Url
$parentPath = Mage::helper('catalog/category')->getCategoryUrlPath($parentPath,
true, $category->getStoreId());
- return $this->getUnusedPath($category->getStoreId(), $parentPath . $urlKey . $categoryUrlSuffix,
- $this->generatePath('id', null, $category)
+ return $this->getUnusedPathByUrlkey($category->getStoreId(), $parentPath . $urlKey . $categoryUrlSuffix,
+ $this->generatePath('id', null, $category), $urlKey
);
@@ -913,14 +932,14 @@ class Mage_Catalog_Model_Url
$this->_addCategoryUrlPath($category);
$categoryUrl = Mage::helper('catalog/category')->getCategoryUrlPath($category->getUrlPath(),
false, $category->getStoreId());
- return $this->getUnusedPath($category->getStoreId(), $categoryUrl . '/' . $urlKey . $productUrlSuffix,
- $this->generatePath('id', $product, $category)
+ return $this->getUnusedPathByUrlkey($category->getStoreId(), $categoryUrl . '/' . $urlKey . $productUrlSuffix,
+ $this->generatePath('id', $product, $category), $urlKey
);
// for product only
- return $this->getUnusedPath($category->getStoreId(), $urlKey . $productUrlSuffix,
- $this->generatePath('id', $product)
+ return $this->getUnusedPathByUrlkey($category->getStoreId(), $urlKey . $productUrlSuffix,
+ $this->generatePath('id', $product), $urlKey
);
If you want to use this patch with CE, make sure to test it properly, because it has been developed for EE.
I would like to add a fix for this url rewrite indexer bug which has been developed at the bugathon in March 2013 and which has been further improved afterwards. It should solve this issue. As a reference, here is the patch file from the link:
diff -rupN mage_org/app/code/core/Mage/Catalog/Model/Url.php src_shop/app/code/core/Mage/Catalog/Model/Url.php
--- mage_org/app/code/core/Mage/Catalog/Model/Url.php 2013-11-19 00:48:25.679009391 +0100
+++ src_shop/app/code/core/Mage/Catalog/Model/Url.php 2013-11-19 00:49:24.188005601 +0100
@@ -643,13 +643,24 @@ class Mage_Catalog_Model_Url
$this->_rewrite = $rewrite;
return $requestPath;
}
+
+ // avoid unnecessary creation of new url_keys for duplicate url keys
+ $noSuffixPath = substr($requestPath, 0, -(strlen($suffix)));
+ $regEx = '#^('.preg_quote($noSuffixPath).')(-([0-9]+))?('.preg_quote($suffix).')#i';
+ $currentRewrite = $this->getResource()->getRewriteByIdPath($idPath, $storeId);
+ if ($currentRewrite && preg_match($regEx, $currentRewrite->getRequestPath(), $match))
+ $this->_rewrite = $currentRewrite;
+ return $currentRewrite->getRequestPath();
+
+
// match request_url abcdef1234(-12)(.html) pattern
$match = array();
$regularExpression = '#^([0-9a-z/-]+?)(-([0-9]+))?('.preg_quote($suffix).')?$#i';
if (!preg_match($regularExpression, $requestPath, $match))
return $this->getUnusedPath($storeId, '-', $idPath);
- $match[1] = $match[1] . '-';
+ $match[1] = $noSuffixPath . '-'; // always use full prefix of url_key
+ unset($match[3]); // don't start counting with a possible number in the url_key
$match[4] = isset($match[4]) ? $match[4] : '';
$lastRequestPath = $this->getResource()
Additionally, I would like to add the EE patch PATCH_SUPEE-389_EE_1.12.0.2_v2.sh
, which is now available on GitHub:
#!/bin/bash
# Patch apllying tool template
# v0.1.2
# (c) Copyright 2013. Magento Inc.
#
# DO NOT CHANGE ANY LINE IN THIS FILE.
# 1. Check required system tools
_check_installed_tools()
local missed=""
until [ -z "$1" ]; do
type -t $1 >/dev/null 2>/dev/null
if (( $? != 0 )); then
missed="$missed $1"
fi
shift
done
echo $missed
REQUIRED_UTILS='sed patch'
MISSED_REQUIRED_TOOLS=`_check_installed_tools $REQUIRED_UTILS`
if (( `echo $MISSED_REQUIRED_TOOLS | wc -w` > 0 ));
then
echo -e "Error! Some required system tools, that are utilized in this sh script, are not installed:nTool(s) "$MISSED_REQUIRED_TOOLS" is(are) missed, please install it(them)."
exit 1
fi
# 2. Determine bin path for system tools
CAT_BIN=`which cat`
PATCH_BIN=`which patch`
SED_BIN=`which sed`
PWD_BIN=`which pwd`
BASENAME_BIN=`which basename`
BASE_NAME=`$BASENAME_BIN "$0"`
# 3. Help menu
if [ "$1" = "-?" -o "$1" = "-h" -o "$1" = "--help" ]
then
$CAT_BIN << EOFH
Usage: sh $BASE_NAME [--help] [-R|--revert] [--list]
Apply embedded patch.
-R, --revert Revert previously applied embedded patch
--list Show list of applied patches
--help Show this help message
EOFH
exit 0
fi
# 4. Get "revert" flag and "list applied patches" flag
REVERT_FLAG=
SHOW_APPLIED_LIST=0
if [ "$1" = "-R" -o "$1" = "--revert" ]
then
REVERT_FLAG=-R
fi
if [ "$1" = "--list" ]
then
SHOW_APPLIED_LIST=1
fi
# 5. File pathes
CURRENT_DIR=`$PWD_BIN`/
APP_ETC_DIR=`echo "$CURRENT_DIR""app/etc/"`
APPLIED_PATCHES_LIST_FILE=`echo "$APP_ETC_DIR""applied.patches.list"`
# 6. Show applied patches list if requested
if [ "$SHOW_APPLIED_LIST" -eq 1 ] ; then
echo -e "Applied/reverted patches list:"
if [ -e "$APPLIED_PATCHES_LIST_FILE" ]
then
if [ ! -r "$APPLIED_PATCHES_LIST_FILE" ]
then
echo "ERROR: "$APPLIED_PATCHES_LIST_FILE" must be readable so applied patches list can be shown."
exit 1
else
$SED_BIN -n "/SUP-|SUPEE-/p" $APPLIED_PATCHES_LIST_FILE
fi
else
echo "<empty>"
fi
exit 0
fi
# 7. Check applied patches track file and its directory
_check_files()
if [ ! -e "$APP_ETC_DIR" ]
then
echo "ERROR: "$APP_ETC_DIR" must exist for proper tool work."
exit 1
fi
if [ ! -w "$APP_ETC_DIR" ]
then
echo "ERROR: "$APP_ETC_DIR" must be writeable for proper tool work."
exit 1
fi
if [ -e "$APPLIED_PATCHES_LIST_FILE" ]
then
if [ ! -w "$APPLIED_PATCHES_LIST_FILE" ]
then
echo "ERROR: "$APPLIED_PATCHES_LIST_FILE" must be writeable for proper tool work."
exit 1
fi
fi
_check_files
# 8. Apply/revert patch
# Note: there is no need to check files permissions for files to be patched.
# "patch" tool will not modify any file if there is not enough permissions for all files to be modified.
# Get start points for additional information and patch data
SKIP_LINES=$((`$SED_BIN -n "/^__PATCHFILE_FOLLOWS__$/=" "$CURRENT_DIR""$BASE_NAME"` + 1))
ADDITIONAL_INFO_LINE=$(($SKIP_LINES - 3))p
_apply_revert_patch()
DRY_RUN_FLAG=
if [ "$1" = "dry-run" ]
then
DRY_RUN_FLAG=" --dry-run"
echo "Checking if patch can be applied/reverted successfully..."
fi
PATCH_APPLY_REVERT_RESULT=`$SED_BIN -e '1,/^__PATCHFILE_FOLLOWS__$/d' "$CURRENT_DIR""$BASE_NAME"
REVERTED_PATCH_MARK=
if [ -n "$REVERT_FLAG" ]
then
REVERTED_PATCH_MARK=" | REVERTED"
fi
_apply_revert_patch dry-run
_apply_revert_patch
# 9. Track patch applying result
echo "Patch was applied/reverted successfully."
ADDITIONAL_INFO=`$SED_BIN -n ""$ADDITIONAL_INFO_LINE"" "$CURRENT_DIR""$BASE_NAME"`
APPLIED_REVERTED_ON_DATE=`date -u +"%F %T UTC"`
APPLIED_REVERTED_PATCH_INFO=`echo -n "$APPLIED_REVERTED_ON_DATE"" | ""$ADDITIONAL_INFO""$REVERTED_PATCH_MARK"`
echo -e "$APPLIED_REVERTED_PATCH_INFOn$PATCH_APPLY_REVERT_RESULTnn" >> "$APPLIED_PATCHES_LIST_FILE"
exit 0
SUPEE-389 | EE_1.12.0.2 | v1 | 53c8ca52583358953b143aaa1a78cf409e8dd846 | Thu Jun 20 10:36:39 2013 +0300 | v1.12.0.2..HEAD
__PATCHFILE_FOLLOWS__
diff --git app/code/core/Mage/Catalog/Model/Url.php app/code/core/Mage/Catalog/Model/Url.php
index fa55fc5..a755b46 100644
--- app/code/core/Mage/Catalog/Model/Url.php
+++ app/code/core/Mage/Catalog/Model/Url.php
@@ -609,6 +609,23 @@ class Mage_Catalog_Model_Url
*/
public function getUnusedPath($storeId, $requestPath, $idPath)
+ $urlKey = '';
+ return $this->getUnusedPathByUrlkey($storeId, $requestPath, $idPath, $urlKey);
+
+
+ /**
+ * Get requestPath that was not used yet.
+ *
+ * Will try to get unique path by adding -1 -2 etc. between url_key and optional url_suffix
+ *
+ * @param int $storeId
+ * @param string $requestPath
+ * @param string $idPath
+ * @param string $urlKey
+ * @return string
+ */
+ public function getUnusedPathByUrlkey($storeId, $requestPath, $idPath, $urlKey = '')
+
if (strpos($idPath, 'product') !== false)
$suffix = $this->getProductUrlSuffix($storeId);
else
@@ -645,21 +662,22 @@ class Mage_Catalog_Model_Url
// match request_url abcdef1234(-12)(.html) pattern
$match = array();
- $regularExpression = '#^([0-9a-z/-]+?)(-([0-9]+))?('.preg_quote($suffix).')?$#i';
+ $regularExpression = '#(?P<prefix>(.*/)?' . preg_quote($urlKey) . ')(-(?P<increment>[0-9]+))?(?P<suffix>'
+ . preg_quote($suffix) . ')?$#i';
if (!preg_match($regularExpression, $requestPath, $match))
- return $this->getUnusedPath($storeId, '-', $idPath);
+ return $this->getUnusedPathByUrlkey($storeId, '-', $idPath, $urlKey);
- $match[1] = $match[1] . '-';
- $match[4] = isset($match[4]) ? $match[4] : '';
+ $match['prefix'] = $match['prefix'] . '-';
+ $match['suffix'] = isset($match['suffix']) ? $match['suffix'] : '';
$lastRequestPath = $this->getResource()
- ->getLastUsedRewriteRequestIncrement($match[1], $match[4], $storeId);
+ ->getLastUsedRewriteRequestIncrement($match['prefix'], $match['suffix'], $storeId);
if ($lastRequestPath)
- $match[3] = $lastRequestPath;
+ $match['increment'] = $lastRequestPath;
- return $match[1]
- . (isset($match[3]) ? ($match[3]+1) : '1')
- . $match[4];
+ return $match['prefix']
+ . (isset($match['increment']) ? ($match['increment']+1) : '1')
+ . $match['suffix'];
else
return $requestPath;
@@ -699,7 +717,7 @@ class Mage_Catalog_Model_Url
$storeId = $category->getStoreId();
$idPath = $this->generatePath('id', null, $category);
- $suffix = $this->getCategoryUrlSuffix($storeId);
+ $categoryUrlSuffix = $this->getCategoryUrlSuffix($storeId);
if (isset($this->_rewrites[$idPath]))
$this->_rewrite = $this->_rewrites[$idPath];
@@ -713,27 +731,27 @@ class Mage_Catalog_Model_Url
$urlKey = $this->getCategoryModel()->formatUrlKey($category->getUrlKey());
- $categoryUrlSuffix = $this->getCategoryUrlSuffix($category->getStoreId());
if (null === $parentPath)
$parentPath = $this->getResource()->getCategoryParentPath($category);
elseif ($parentPath == '/')
$parentPath = '';
- $parentPath = Mage::helper('catalog/category')->getCategoryUrlPath($parentPath,
- true, $category->getStoreId());
+ $parentPath = Mage::helper('catalog/category')->getCategoryUrlPath($parentPath, true, $storeId);
- $requestPath = $parentPath . $urlKey . $categoryUrlSuffix;
- if (isset($existingRequestPath) && $existingRequestPath == $requestPath . $suffix)
+ $requestPath = $parentPath . $urlKey;
+ $regexp = '/^' . preg_quote($requestPath, '/') . '(-[0-9]+)?' . preg_quote($categoryUrlSuffix, '/') . '$/i';
+ if (isset($existingRequestPath) && preg_match($regexp, $existingRequestPath))
return $existingRequestPath;
- if ($this->_deleteOldTargetPath($requestPath, $idPath, $storeId))
+ $fullPath = $requestPath . $categoryUrlSuffix;
+ if ($this->_deleteOldTargetPath($fullPath, $idPath, $storeId))
return $requestPath;
- return $this->getUnusedPath($category->getStoreId(), $requestPath,
- $this->generatePath('id', null, $category)
+ return $this->getUnusedPathByUrlkey($storeId, $fullPath,
+ $this->generatePath('id', null, $category), $urlKey
);
@@ -798,7 +816,8 @@ class Mage_Catalog_Model_Url
$this->_rewrite = $this->_rewrites[$idPath];
$existingRequestPath = $this->_rewrites[$idPath]->getRequestPath();
- if ($existingRequestPath == $requestPath . $suffix)
+ $regexp = '/^' . preg_quote($requestPath, '/') . '(-[0-9]+)?' . preg_quote($suffix, '/') . '$/i';
+ if (preg_match($regexp, $existingRequestPath))
return $existingRequestPath;
@@ -836,7 +855,7 @@ class Mage_Catalog_Model_Url
/**
* Use unique path generator
*/
- return $this->getUnusedPath($storeId, $requestPath.$suffix, $idPath);
+ return $this->getUnusedPathByUrlkey($storeId, $requestPath.$suffix, $idPath, $urlKey);
/**
@@ -891,8 +910,8 @@ class Mage_Catalog_Model_Url
$parentPath = Mage::helper('catalog/category')->getCategoryUrlPath($parentPath,
true, $category->getStoreId());
- return $this->getUnusedPath($category->getStoreId(), $parentPath . $urlKey . $categoryUrlSuffix,
- $this->generatePath('id', null, $category)
+ return $this->getUnusedPathByUrlkey($category->getStoreId(), $parentPath . $urlKey . $categoryUrlSuffix,
+ $this->generatePath('id', null, $category), $urlKey
);
@@ -913,14 +932,14 @@ class Mage_Catalog_Model_Url
$this->_addCategoryUrlPath($category);
$categoryUrl = Mage::helper('catalog/category')->getCategoryUrlPath($category->getUrlPath(),
false, $category->getStoreId());
- return $this->getUnusedPath($category->getStoreId(), $categoryUrl . '/' . $urlKey . $productUrlSuffix,
- $this->generatePath('id', $product, $category)
+ return $this->getUnusedPathByUrlkey($category->getStoreId(), $categoryUrl . '/' . $urlKey . $productUrlSuffix,
+ $this->generatePath('id', $product, $category), $urlKey
);
// for product only
- return $this->getUnusedPath($category->getStoreId(), $urlKey . $productUrlSuffix,
- $this->generatePath('id', $product)
+ return $this->getUnusedPathByUrlkey($category->getStoreId(), $urlKey . $productUrlSuffix,
+ $this->generatePath('id', $product), $urlKey
);
If you want to use this patch with CE, make sure to test it properly, because it has been developed for EE.
edited Sep 5 '14 at 20:43
answered Aug 20 '14 at 20:30
SimonSimon
4,63911960
4,63911960
Have you yourself tested this EE patch on CE?
– Tyler V.
Mar 19 '15 at 18:14
@TylerV. Nope...
– Simon
Mar 20 '15 at 13:22
3
I've tried this patch in EE 1.9.1.1 and can conform it works. It fixes the problem with products and categories with identical url keys. Let's hope they implement this in a future release soon.
– Giel Berkers
Jun 25 '15 at 12:21
1
Thanks Simon, just went from 1GB to 3MB on one clients website... Had to truncate it before every 6 months, hope it will remain small now:)
– willem wigman
Aug 10 '15 at 12:46
1
I've just tried this on my 1.9 CE and although it works for products - the categories are not quite right. If I have a category called 'Test' which gives the url '.../test' and then I create another called 'Test' it should give the url '.../test-2' but instead gives just the number not the name: '.../-2'
– odd_duck
Aug 26 '16 at 15:41
|
show 3 more comments
Have you yourself tested this EE patch on CE?
– Tyler V.
Mar 19 '15 at 18:14
@TylerV. Nope...
– Simon
Mar 20 '15 at 13:22
3
I've tried this patch in EE 1.9.1.1 and can conform it works. It fixes the problem with products and categories with identical url keys. Let's hope they implement this in a future release soon.
– Giel Berkers
Jun 25 '15 at 12:21
1
Thanks Simon, just went from 1GB to 3MB on one clients website... Had to truncate it before every 6 months, hope it will remain small now:)
– willem wigman
Aug 10 '15 at 12:46
1
I've just tried this on my 1.9 CE and although it works for products - the categories are not quite right. If I have a category called 'Test' which gives the url '.../test' and then I create another called 'Test' it should give the url '.../test-2' but instead gives just the number not the name: '.../-2'
– odd_duck
Aug 26 '16 at 15:41
Have you yourself tested this EE patch on CE?
– Tyler V.
Mar 19 '15 at 18:14
Have you yourself tested this EE patch on CE?
– Tyler V.
Mar 19 '15 at 18:14
@TylerV. Nope...
– Simon
Mar 20 '15 at 13:22
@TylerV. Nope...
– Simon
Mar 20 '15 at 13:22
3
3
I've tried this patch in EE 1.9.1.1 and can conform it works. It fixes the problem with products and categories with identical url keys. Let's hope they implement this in a future release soon.
– Giel Berkers
Jun 25 '15 at 12:21
I've tried this patch in EE 1.9.1.1 and can conform it works. It fixes the problem with products and categories with identical url keys. Let's hope they implement this in a future release soon.
– Giel Berkers
Jun 25 '15 at 12:21
1
1
Thanks Simon, just went from 1GB to 3MB on one clients website... Had to truncate it before every 6 months, hope it will remain small now:)
– willem wigman
Aug 10 '15 at 12:46
Thanks Simon, just went from 1GB to 3MB on one clients website... Had to truncate it before every 6 months, hope it will remain small now:)
– willem wigman
Aug 10 '15 at 12:46
1
1
I've just tried this on my 1.9 CE and although it works for products - the categories are not quite right. If I have a category called 'Test' which gives the url '.../test' and then I create another called 'Test' it should give the url '.../test-2' but instead gives just the number not the name: '.../-2'
– odd_duck
Aug 26 '16 at 15:41
I've just tried this on my 1.9 CE and although it works for products - the categories are not quite right. If I have a category called 'Test' which gives the url '.../test' and then I create another called 'Test' it should give the url '.../test-2' but instead gives just the number not the name: '.../-2'
– odd_duck
Aug 26 '16 at 15:41
|
show 3 more comments
After you applied the patch posted by Simon, you can use the following query to remove junk data:
DELETE FROM core_url_rewrite
WHERE is_system <> 1 AND id_path REGEXP "^[0-9]+_[0-9]+$" AND
(request_path REGEXP ".*-[0-9]*.html"
OR target_path = request_path);
In contrast to Ashish Hira's query, this only effects URLs which have an integer number as there last part - this was - in my case - the reason for the clutter.
It tries to not touch valid rewrites, which for example might have been created when updating an URL key.
add a comment |
After you applied the patch posted by Simon, you can use the following query to remove junk data:
DELETE FROM core_url_rewrite
WHERE is_system <> 1 AND id_path REGEXP "^[0-9]+_[0-9]+$" AND
(request_path REGEXP ".*-[0-9]*.html"
OR target_path = request_path);
In contrast to Ashish Hira's query, this only effects URLs which have an integer number as there last part - this was - in my case - the reason for the clutter.
It tries to not touch valid rewrites, which for example might have been created when updating an URL key.
add a comment |
After you applied the patch posted by Simon, you can use the following query to remove junk data:
DELETE FROM core_url_rewrite
WHERE is_system <> 1 AND id_path REGEXP "^[0-9]+_[0-9]+$" AND
(request_path REGEXP ".*-[0-9]*.html"
OR target_path = request_path);
In contrast to Ashish Hira's query, this only effects URLs which have an integer number as there last part - this was - in my case - the reason for the clutter.
It tries to not touch valid rewrites, which for example might have been created when updating an URL key.
After you applied the patch posted by Simon, you can use the following query to remove junk data:
DELETE FROM core_url_rewrite
WHERE is_system <> 1 AND id_path REGEXP "^[0-9]+_[0-9]+$" AND
(request_path REGEXP ".*-[0-9]*.html"
OR target_path = request_path);
In contrast to Ashish Hira's query, this only effects URLs which have an integer number as there last part - this was - in my case - the reason for the clutter.
It tries to not touch valid rewrites, which for example might have been created when updating an URL key.
answered Mar 15 '16 at 10:23
AlexAlex
9,7201754114
9,7201754114
add a comment |
add a comment |
I've implemented the accepted answer with success. On another Magento install I needed to preserve some custom rewrites so I deleted all entries that ended in a - and then a number up to 5 digits long with:
DELETE FROM `core_url_rewrite` WHERE `request_path` REGEXP '\-[0-9]1,5$';
This mostly worked but I still get 2 more rows on each re-index. Not sure why. I thought I would share this experience.
1
You probably deleted URLs that are valid, yet end in a number. You'd find those with$collection = Mage::getModel('catalog/product')->getCollection()->addAttributeToFilter('url_key', array('regexp' => '[0-9]$'));
– Melvyn
Mar 28 '15 at 17:43
add a comment |
I've implemented the accepted answer with success. On another Magento install I needed to preserve some custom rewrites so I deleted all entries that ended in a - and then a number up to 5 digits long with:
DELETE FROM `core_url_rewrite` WHERE `request_path` REGEXP '\-[0-9]1,5$';
This mostly worked but I still get 2 more rows on each re-index. Not sure why. I thought I would share this experience.
1
You probably deleted URLs that are valid, yet end in a number. You'd find those with$collection = Mage::getModel('catalog/product')->getCollection()->addAttributeToFilter('url_key', array('regexp' => '[0-9]$'));
– Melvyn
Mar 28 '15 at 17:43
add a comment |
I've implemented the accepted answer with success. On another Magento install I needed to preserve some custom rewrites so I deleted all entries that ended in a - and then a number up to 5 digits long with:
DELETE FROM `core_url_rewrite` WHERE `request_path` REGEXP '\-[0-9]1,5$';
This mostly worked but I still get 2 more rows on each re-index. Not sure why. I thought I would share this experience.
I've implemented the accepted answer with success. On another Magento install I needed to preserve some custom rewrites so I deleted all entries that ended in a - and then a number up to 5 digits long with:
DELETE FROM `core_url_rewrite` WHERE `request_path` REGEXP '\-[0-9]1,5$';
This mostly worked but I still get 2 more rows on each re-index. Not sure why. I thought I would share this experience.
answered Mar 19 '15 at 16:07
Andy MyersAndy Myers
14614
14614
1
You probably deleted URLs that are valid, yet end in a number. You'd find those with$collection = Mage::getModel('catalog/product')->getCollection()->addAttributeToFilter('url_key', array('regexp' => '[0-9]$'));
– Melvyn
Mar 28 '15 at 17:43
add a comment |
1
You probably deleted URLs that are valid, yet end in a number. You'd find those with$collection = Mage::getModel('catalog/product')->getCollection()->addAttributeToFilter('url_key', array('regexp' => '[0-9]$'));
– Melvyn
Mar 28 '15 at 17:43
1
1
You probably deleted URLs that are valid, yet end in a number. You'd find those with
$collection = Mage::getModel('catalog/product')->getCollection()->addAttributeToFilter('url_key', array('regexp' => '[0-9]$'));
– Melvyn
Mar 28 '15 at 17:43
You probably deleted URLs that are valid, yet end in a number. You'd find those with
$collection = Mage::getModel('catalog/product')->getCollection()->addAttributeToFilter('url_key', array('regexp' => '[0-9]$'));
– Melvyn
Mar 28 '15 at 17:43
add a comment |
The core change that you mentioned only seems to be needed if you have products without url_keys, however Magento should always create url_keys for you. If you have some importer which is creating products without url_keys, then this problem will crop up for those products. Try running the following query to find such products:
SELECT cpe.entity_id, cpe.sku, cpev.value
FROM catalog_product_entity cpe
LEFT JOIN catalog_product_entity_varchar cpev
ON cpe.entity_id = cpev.entity_id AND cpev.attribute_id = (
SELECT attribute_id
FROM eav_attribute
WHERE `entity_type_id` = 4
AND `attribute_code` = 'url_key'
)
WHERE cpev.value IS NULL OR cpev.value = ''
If any products return from that query, they don't have a url_key and are going to be a problem.
2
Mind that the defaultentity_type_id
for products is 4 and not 10.
– Simon
Jan 20 '16 at 15:07
add a comment |
The core change that you mentioned only seems to be needed if you have products without url_keys, however Magento should always create url_keys for you. If you have some importer which is creating products without url_keys, then this problem will crop up for those products. Try running the following query to find such products:
SELECT cpe.entity_id, cpe.sku, cpev.value
FROM catalog_product_entity cpe
LEFT JOIN catalog_product_entity_varchar cpev
ON cpe.entity_id = cpev.entity_id AND cpev.attribute_id = (
SELECT attribute_id
FROM eav_attribute
WHERE `entity_type_id` = 4
AND `attribute_code` = 'url_key'
)
WHERE cpev.value IS NULL OR cpev.value = ''
If any products return from that query, they don't have a url_key and are going to be a problem.
2
Mind that the defaultentity_type_id
for products is 4 and not 10.
– Simon
Jan 20 '16 at 15:07
add a comment |
The core change that you mentioned only seems to be needed if you have products without url_keys, however Magento should always create url_keys for you. If you have some importer which is creating products without url_keys, then this problem will crop up for those products. Try running the following query to find such products:
SELECT cpe.entity_id, cpe.sku, cpev.value
FROM catalog_product_entity cpe
LEFT JOIN catalog_product_entity_varchar cpev
ON cpe.entity_id = cpev.entity_id AND cpev.attribute_id = (
SELECT attribute_id
FROM eav_attribute
WHERE `entity_type_id` = 4
AND `attribute_code` = 'url_key'
)
WHERE cpev.value IS NULL OR cpev.value = ''
If any products return from that query, they don't have a url_key and are going to be a problem.
The core change that you mentioned only seems to be needed if you have products without url_keys, however Magento should always create url_keys for you. If you have some importer which is creating products without url_keys, then this problem will crop up for those products. Try running the following query to find such products:
SELECT cpe.entity_id, cpe.sku, cpev.value
FROM catalog_product_entity cpe
LEFT JOIN catalog_product_entity_varchar cpev
ON cpe.entity_id = cpev.entity_id AND cpev.attribute_id = (
SELECT attribute_id
FROM eav_attribute
WHERE `entity_type_id` = 4
AND `attribute_code` = 'url_key'
)
WHERE cpev.value IS NULL OR cpev.value = ''
If any products return from that query, they don't have a url_key and are going to be a problem.
edited Jan 13 '17 at 5:27
answered Nov 8 '14 at 1:56
Tyler V.Tyler V.
2,07721740
2,07721740
2
Mind that the defaultentity_type_id
for products is 4 and not 10.
– Simon
Jan 20 '16 at 15:07
add a comment |
2
Mind that the defaultentity_type_id
for products is 4 and not 10.
– Simon
Jan 20 '16 at 15:07
2
2
Mind that the default
entity_type_id
for products is 4 and not 10.– Simon
Jan 20 '16 at 15:07
Mind that the default
entity_type_id
for products is 4 and not 10.– Simon
Jan 20 '16 at 15:07
add a comment |
I followed approved solution to prevent duplicate URL rewrites, then exported core_url_rewrite
as CSV file. Was able to open this CSV and delete all but manually created URL rewrites.
Then I truncated core_url_rewrite
table, and imported my saved CSV with manually created URL rewrites.
After all changes, went from 940K rows to 32K. Huge improvement.
add a comment |
I followed approved solution to prevent duplicate URL rewrites, then exported core_url_rewrite
as CSV file. Was able to open this CSV and delete all but manually created URL rewrites.
Then I truncated core_url_rewrite
table, and imported my saved CSV with manually created URL rewrites.
After all changes, went from 940K rows to 32K. Huge improvement.
add a comment |
I followed approved solution to prevent duplicate URL rewrites, then exported core_url_rewrite
as CSV file. Was able to open this CSV and delete all but manually created URL rewrites.
Then I truncated core_url_rewrite
table, and imported my saved CSV with manually created URL rewrites.
After all changes, went from 940K rows to 32K. Huge improvement.
I followed approved solution to prevent duplicate URL rewrites, then exported core_url_rewrite
as CSV file. Was able to open this CSV and delete all but manually created URL rewrites.
Then I truncated core_url_rewrite
table, and imported my saved CSV with manually created URL rewrites.
After all changes, went from 940K rows to 32K. Huge improvement.
edited Apr 6 '15 at 19:38
SR_Magento
3,434115296
3,434115296
answered Apr 6 '15 at 17:00
JonWJonW
787
787
add a comment |
add a comment |
Here is patch (local rewrite) for Magento Community for fix that https://github.com/biotech/Magento-URL-Rewrite In fact does the same as EE patch PATCH_SUPEE-389_EE_1.12.0.2_v2.sh - check every rewrite and avoid creation of duplicated records. Works well last 2 months on production CE 1.9 , 15k products , 4 stores , full re-index every night after bulk product import changes.
How thoroughly has this been tested? It looks like it was posted just an hour ago....
– SR_Magento
Aug 11 '15 at 15:20
Has this been fixed in 1.9.2.x so we no longer need worry about table bloat?
– Fiasco Labs
Aug 11 '15 at 15:21
Single link answers are not the best answers even if they might solve the problem. Please explain a bit what your code does.
– Marius♦
Aug 11 '15 at 15:23
@FiascoLabs yes, works good on all CE 1.9.x
– FireBear
Aug 12 '15 at 16:11
1
@FiascoLabs: 1.9.2.x still has this "rewrite bloat" issue, and doesn't include this fix, however, as FireBear said, the EE patch will work with CE 1.9.2.x. (have not tried personally; only wanted to clarify that 1.9.2.2 definitely still has this issue)
– Eric Seastrand
Jan 5 '16 at 23:06
|
show 3 more comments
Here is patch (local rewrite) for Magento Community for fix that https://github.com/biotech/Magento-URL-Rewrite In fact does the same as EE patch PATCH_SUPEE-389_EE_1.12.0.2_v2.sh - check every rewrite and avoid creation of duplicated records. Works well last 2 months on production CE 1.9 , 15k products , 4 stores , full re-index every night after bulk product import changes.
How thoroughly has this been tested? It looks like it was posted just an hour ago....
– SR_Magento
Aug 11 '15 at 15:20
Has this been fixed in 1.9.2.x so we no longer need worry about table bloat?
– Fiasco Labs
Aug 11 '15 at 15:21
Single link answers are not the best answers even if they might solve the problem. Please explain a bit what your code does.
– Marius♦
Aug 11 '15 at 15:23
@FiascoLabs yes, works good on all CE 1.9.x
– FireBear
Aug 12 '15 at 16:11
1
@FiascoLabs: 1.9.2.x still has this "rewrite bloat" issue, and doesn't include this fix, however, as FireBear said, the EE patch will work with CE 1.9.2.x. (have not tried personally; only wanted to clarify that 1.9.2.2 definitely still has this issue)
– Eric Seastrand
Jan 5 '16 at 23:06
|
show 3 more comments
Here is patch (local rewrite) for Magento Community for fix that https://github.com/biotech/Magento-URL-Rewrite In fact does the same as EE patch PATCH_SUPEE-389_EE_1.12.0.2_v2.sh - check every rewrite and avoid creation of duplicated records. Works well last 2 months on production CE 1.9 , 15k products , 4 stores , full re-index every night after bulk product import changes.
Here is patch (local rewrite) for Magento Community for fix that https://github.com/biotech/Magento-URL-Rewrite In fact does the same as EE patch PATCH_SUPEE-389_EE_1.12.0.2_v2.sh - check every rewrite and avoid creation of duplicated records. Works well last 2 months on production CE 1.9 , 15k products , 4 stores , full re-index every night after bulk product import changes.
edited Aug 12 '15 at 16:14
answered Aug 11 '15 at 14:54
FireBearFireBear
1,97011025
1,97011025
How thoroughly has this been tested? It looks like it was posted just an hour ago....
– SR_Magento
Aug 11 '15 at 15:20
Has this been fixed in 1.9.2.x so we no longer need worry about table bloat?
– Fiasco Labs
Aug 11 '15 at 15:21
Single link answers are not the best answers even if they might solve the problem. Please explain a bit what your code does.
– Marius♦
Aug 11 '15 at 15:23
@FiascoLabs yes, works good on all CE 1.9.x
– FireBear
Aug 12 '15 at 16:11
1
@FiascoLabs: 1.9.2.x still has this "rewrite bloat" issue, and doesn't include this fix, however, as FireBear said, the EE patch will work with CE 1.9.2.x. (have not tried personally; only wanted to clarify that 1.9.2.2 definitely still has this issue)
– Eric Seastrand
Jan 5 '16 at 23:06
|
show 3 more comments
How thoroughly has this been tested? It looks like it was posted just an hour ago....
– SR_Magento
Aug 11 '15 at 15:20
Has this been fixed in 1.9.2.x so we no longer need worry about table bloat?
– Fiasco Labs
Aug 11 '15 at 15:21
Single link answers are not the best answers even if they might solve the problem. Please explain a bit what your code does.
– Marius♦
Aug 11 '15 at 15:23
@FiascoLabs yes, works good on all CE 1.9.x
– FireBear
Aug 12 '15 at 16:11
1
@FiascoLabs: 1.9.2.x still has this "rewrite bloat" issue, and doesn't include this fix, however, as FireBear said, the EE patch will work with CE 1.9.2.x. (have not tried personally; only wanted to clarify that 1.9.2.2 definitely still has this issue)
– Eric Seastrand
Jan 5 '16 at 23:06
How thoroughly has this been tested? It looks like it was posted just an hour ago....
– SR_Magento
Aug 11 '15 at 15:20
How thoroughly has this been tested? It looks like it was posted just an hour ago....
– SR_Magento
Aug 11 '15 at 15:20
Has this been fixed in 1.9.2.x so we no longer need worry about table bloat?
– Fiasco Labs
Aug 11 '15 at 15:21
Has this been fixed in 1.9.2.x so we no longer need worry about table bloat?
– Fiasco Labs
Aug 11 '15 at 15:21
Single link answers are not the best answers even if they might solve the problem. Please explain a bit what your code does.
– Marius♦
Aug 11 '15 at 15:23
Single link answers are not the best answers even if they might solve the problem. Please explain a bit what your code does.
– Marius♦
Aug 11 '15 at 15:23
@FiascoLabs yes, works good on all CE 1.9.x
– FireBear
Aug 12 '15 at 16:11
@FiascoLabs yes, works good on all CE 1.9.x
– FireBear
Aug 12 '15 at 16:11
1
1
@FiascoLabs: 1.9.2.x still has this "rewrite bloat" issue, and doesn't include this fix, however, as FireBear said, the EE patch will work with CE 1.9.2.x. (have not tried personally; only wanted to clarify that 1.9.2.2 definitely still has this issue)
– Eric Seastrand
Jan 5 '16 at 23:06
@FiascoLabs: 1.9.2.x still has this "rewrite bloat" issue, and doesn't include this fix, however, as FireBear said, the EE patch will work with CE 1.9.2.x. (have not tried personally; only wanted to clarify that 1.9.2.2 definitely still has this issue)
– Eric Seastrand
Jan 5 '16 at 23:06
|
show 3 more comments
Since this is not yet mentioned in this thread, I wanted to share the cool news that this issue is fixed in Magento 1.9.3.9 and later. See the related release notes:
Magento no longer performs unnecessary write operations on the core_url_rewrite table.
So all fixes for this issue mentioned here are not necessary when using a version of Magento greater or equal than 1.9.3.9. I still suggest deleting the old values as described in Alex answer.
add a comment |
Since this is not yet mentioned in this thread, I wanted to share the cool news that this issue is fixed in Magento 1.9.3.9 and later. See the related release notes:
Magento no longer performs unnecessary write operations on the core_url_rewrite table.
So all fixes for this issue mentioned here are not necessary when using a version of Magento greater or equal than 1.9.3.9. I still suggest deleting the old values as described in Alex answer.
add a comment |
Since this is not yet mentioned in this thread, I wanted to share the cool news that this issue is fixed in Magento 1.9.3.9 and later. See the related release notes:
Magento no longer performs unnecessary write operations on the core_url_rewrite table.
So all fixes for this issue mentioned here are not necessary when using a version of Magento greater or equal than 1.9.3.9. I still suggest deleting the old values as described in Alex answer.
Since this is not yet mentioned in this thread, I wanted to share the cool news that this issue is fixed in Magento 1.9.3.9 and later. See the related release notes:
Magento no longer performs unnecessary write operations on the core_url_rewrite table.
So all fixes for this issue mentioned here are not necessary when using a version of Magento greater or equal than 1.9.3.9. I still suggest deleting the old values as described in Alex answer.
answered Dec 13 '18 at 15:05
SimonSimon
4,63911960
4,63911960
add a comment |
add a comment |
Run this query
DELETE FROM core_url_rewrite WHERE is_system <> 1 AND id_path REGEXP "^[0-9]+_[0-9]+$";
This will surely help you reduce the size of core_url_size
table by deleting junk data.
Are you sure this is junk data? I think it deleted also rewrites which were created when changing an URL key!
– Alex
Mar 15 '16 at 10:10
Check the regex. this mean which don't have valid id
– Asish Hira
Mar 15 '16 at 10:13
But those IDs are also created when changing the URL key manually in the backend. See also my answer.
– Alex
Mar 15 '16 at 11:07
add a comment |
Run this query
DELETE FROM core_url_rewrite WHERE is_system <> 1 AND id_path REGEXP "^[0-9]+_[0-9]+$";
This will surely help you reduce the size of core_url_size
table by deleting junk data.
Are you sure this is junk data? I think it deleted also rewrites which were created when changing an URL key!
– Alex
Mar 15 '16 at 10:10
Check the regex. this mean which don't have valid id
– Asish Hira
Mar 15 '16 at 10:13
But those IDs are also created when changing the URL key manually in the backend. See also my answer.
– Alex
Mar 15 '16 at 11:07
add a comment |
Run this query
DELETE FROM core_url_rewrite WHERE is_system <> 1 AND id_path REGEXP "^[0-9]+_[0-9]+$";
This will surely help you reduce the size of core_url_size
table by deleting junk data.
Run this query
DELETE FROM core_url_rewrite WHERE is_system <> 1 AND id_path REGEXP "^[0-9]+_[0-9]+$";
This will surely help you reduce the size of core_url_size
table by deleting junk data.
edited Mar 2 '16 at 14:07
7ochem
5,86493770
5,86493770
answered Mar 2 '16 at 13:47
Asish HiraAsish Hira
1,68611036
1,68611036
Are you sure this is junk data? I think it deleted also rewrites which were created when changing an URL key!
– Alex
Mar 15 '16 at 10:10
Check the regex. this mean which don't have valid id
– Asish Hira
Mar 15 '16 at 10:13
But those IDs are also created when changing the URL key manually in the backend. See also my answer.
– Alex
Mar 15 '16 at 11:07
add a comment |
Are you sure this is junk data? I think it deleted also rewrites which were created when changing an URL key!
– Alex
Mar 15 '16 at 10:10
Check the regex. this mean which don't have valid id
– Asish Hira
Mar 15 '16 at 10:13
But those IDs are also created when changing the URL key manually in the backend. See also my answer.
– Alex
Mar 15 '16 at 11:07
Are you sure this is junk data? I think it deleted also rewrites which were created when changing an URL key!
– Alex
Mar 15 '16 at 10:10
Are you sure this is junk data? I think it deleted also rewrites which were created when changing an URL key!
– Alex
Mar 15 '16 at 10:10
Check the regex. this mean which don't have valid id
– Asish Hira
Mar 15 '16 at 10:13
Check the regex. this mean which don't have valid id
– Asish Hira
Mar 15 '16 at 10:13
But those IDs are also created when changing the URL key manually in the backend. See also my answer.
– Alex
Mar 15 '16 at 11:07
But those IDs are also created when changing the URL key manually in the backend. See also my answer.
– Alex
Mar 15 '16 at 11:07
add a comment |
Get rid of .html
- Do not use suffix
.html
Set in .htaccess
## Redirect all htmls.
RewriteRule (.+).html$ /$1 [L,R=301]Erase all
.html
redirects:DELETE FROM core_url_rewrite WHERE request_path LIKE '%.html'
add a comment |
Get rid of .html
- Do not use suffix
.html
Set in .htaccess
## Redirect all htmls.
RewriteRule (.+).html$ /$1 [L,R=301]Erase all
.html
redirects:DELETE FROM core_url_rewrite WHERE request_path LIKE '%.html'
add a comment |
Get rid of .html
- Do not use suffix
.html
Set in .htaccess
## Redirect all htmls.
RewriteRule (.+).html$ /$1 [L,R=301]Erase all
.html
redirects:DELETE FROM core_url_rewrite WHERE request_path LIKE '%.html'
Get rid of .html
- Do not use suffix
.html
Set in .htaccess
## Redirect all htmls.
RewriteRule (.+).html$ /$1 [L,R=301]Erase all
.html
redirects:DELETE FROM core_url_rewrite WHERE request_path LIKE '%.html'
edited Aug 25 '17 at 4:28
Siarhey Uchukhlebau
10.1k93058
10.1k93058
answered Aug 25 '17 at 4:26
lycenoklycenok
1
1
add a comment |
add a comment |
The official answer should be to install SUPEE-389. Simple as that.
It perfectly works with Magento CE since they share the very same piece of code in this area.
You can find the patch file here, https://gist.github.com/piotrekkaminski/c348538ca91ba35773be#file-patch_supee-389_ee_1-12-0-2_v2-sh
We had this issue and it generated thousands of new rows after each Catalog URL re-index. Now the problem is gone... except for the fact that we have to clean the DB.
The script provided here seems like a good start but it is not a perfect solution,
php shell/rewrites_doctor.php --remove_rewrites 4
See https://www.atwix.com/magento/duplicated-product-url-keys-in-community-edition/
add a comment |
The official answer should be to install SUPEE-389. Simple as that.
It perfectly works with Magento CE since they share the very same piece of code in this area.
You can find the patch file here, https://gist.github.com/piotrekkaminski/c348538ca91ba35773be#file-patch_supee-389_ee_1-12-0-2_v2-sh
We had this issue and it generated thousands of new rows after each Catalog URL re-index. Now the problem is gone... except for the fact that we have to clean the DB.
The script provided here seems like a good start but it is not a perfect solution,
php shell/rewrites_doctor.php --remove_rewrites 4
See https://www.atwix.com/magento/duplicated-product-url-keys-in-community-edition/
add a comment |
The official answer should be to install SUPEE-389. Simple as that.
It perfectly works with Magento CE since they share the very same piece of code in this area.
You can find the patch file here, https://gist.github.com/piotrekkaminski/c348538ca91ba35773be#file-patch_supee-389_ee_1-12-0-2_v2-sh
We had this issue and it generated thousands of new rows after each Catalog URL re-index. Now the problem is gone... except for the fact that we have to clean the DB.
The script provided here seems like a good start but it is not a perfect solution,
php shell/rewrites_doctor.php --remove_rewrites 4
See https://www.atwix.com/magento/duplicated-product-url-keys-in-community-edition/
The official answer should be to install SUPEE-389. Simple as that.
It perfectly works with Magento CE since they share the very same piece of code in this area.
You can find the patch file here, https://gist.github.com/piotrekkaminski/c348538ca91ba35773be#file-patch_supee-389_ee_1-12-0-2_v2-sh
We had this issue and it generated thousands of new rows after each Catalog URL re-index. Now the problem is gone... except for the fact that we have to clean the DB.
The script provided here seems like a good start but it is not a perfect solution,
php shell/rewrites_doctor.php --remove_rewrites 4
See https://www.atwix.com/magento/duplicated-product-url-keys-in-community-edition/
answered Oct 23 '17 at 13:10
Frédéric Gauthier-BoutinFrédéric Gauthier-Boutin
1
1
add a comment |
add a comment |
There is also a dedicated module https://github.com/vladsmirnov/url-rewrites, so you don’t have to re-apply the patch after the each Magento update. Module contains of two parts: actual module, to prevent duplication from now on and the shell script to cleanup the existing database.
add a comment |
There is also a dedicated module https://github.com/vladsmirnov/url-rewrites, so you don’t have to re-apply the patch after the each Magento update. Module contains of two parts: actual module, to prevent duplication from now on and the shell script to cleanup the existing database.
add a comment |
There is also a dedicated module https://github.com/vladsmirnov/url-rewrites, so you don’t have to re-apply the patch after the each Magento update. Module contains of two parts: actual module, to prevent duplication from now on and the shell script to cleanup the existing database.
There is also a dedicated module https://github.com/vladsmirnov/url-rewrites, so you don’t have to re-apply the patch after the each Magento update. Module contains of two parts: actual module, to prevent duplication from now on and the shell script to cleanup the existing database.
edited 2 days ago
Teja Bhagavan Kollepara
2,99241949
2,99241949
answered Nov 14 '17 at 20:07
Vladyslav SmirnovVladyslav Smirnov
11
11
add a comment |
add a comment |
Thanks for contributing an answer to Magento Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmagento.stackexchange.com%2fquestions%2f17553%2fmagento-core-url-rewrite-table-excessively-large%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Wow, that's a staggeringly large table. I checked my own (200 products) and it only has ~800 rows, but we don't have a problem duplicating product name/URLs. As a reference point, we have about 6.6 rows per visible product. I'll admit this not a terrible realistic comparison, but at that rate, with 5,000 products we'd only have ~30,000 rows or so. I can well understand your need for a solution, and will watch this question as I'm about to implement a much bigger site.
– Pete855217
Mar 29 '14 at 9:23
@Pete855217: this question sounds you interesting even though you had not upvoted it.
– Mohammad Faisal
Mar 29 '14 at 11:00
1
There was a bug in EE1.12 which cause re-writes to be re-created on each save. It is possible that your version of 1.7 has this same bug. As I recall the patch for 1.12 also worked on 1.7
– brentwpeterson
Mar 29 '14 at 13:53
1
Very helpful article! We have 130,000 active products, and 25,000 disabled products, our core_url_rewrite_table has 2744023 records in it..... so this week we are getting to work remedying this!! This article looks to be a good starting point.
– MagentoMac
Jul 28 '14 at 20:36
Edited the post to include how not to delete your custom rewrites in Magento.
– espradley
May 15 '15 at 15:09