Schema of URLs not updating

[rusteh]

Hello,

 

I have updated from 1.5.2 to 1.5.3 and now I cant update my schema of urls no matter I do.

 

I tried deleting .htacces, enabling and disabling seo and canonical to regenerate, changing schema and changing back to what i want but it doesnt help, it just gives me the standard schema.

 

I would like to put the id last, for better optimization.

Heres my schema, can someone help me?

 

 

Thanks

Edited January 13, 2013 by rusteh (see edit history)

[Vince84]

Same issue !

 

I spent 2 hours to try all I can do, so I won't be against some help too.

[rusteh]

Anyone have an idea how to fix?

[rusteh]

I found a workaround, I edited directly classes/Dispatcher.php lines that contains Route to products, category, manufacturer, suplier and cms and now everything is like it was before.

 

LE: On second toughts, this isnt solved, because now when i'm trying to add a new rewrite rule to a module, lets say cashondelivery-validation, it redirects me to mywebsite.com/{rewrite}?module/category{:/controller} and it gets me 404 error.

 

Can someone help? Thanks

Edited January 13, 2013 by rusteh (see edit history)

[be_tnt]

I got the same problem: I removed the html extension but it does still appear on front-end.

Do not know how to solve it so far

 

I guess this is a bug in this new version. Can you report it? Is there a way to rollback to the previous one?

Edited January 15, 2013 by be_tnt (see edit history)

[be_tnt]

I have maybe found where is the issue.

 

In \classes\Dispatcher.php, functions loadRoutes(): it loads the default routes in the routes array after the custom ones. Result your custom routes are overwritten by the default ones.

 

To test, I have commented the following code:

 

// Set default routes
 foreach (Language::getLanguages() as $lang)
  foreach ($this->default_routes as $id => $route)
   $this->addRoute(
 $id,
 $route['rule'],
 $route['controller'],
 $lang['id_lang'],
 $route['keywords'],
 isset($route['params']) ? $route['params'] : array()
   );

 

and after that, I got the customized URL format.

 

Looking the code for 1.5.2, you can see that this call to load default routes was done at a first step in this method. This has changed with 1.5.3 (I do not know why).

[be_tnt]

Issue opened on GIT: https://github.com/PrestaShop/PrestaShop/issues/181

[rusteh]

Hello and thanks for your feedback. I will try your fix tomorrow. Right now i deleted prices-drop and when im trying to add again its pricesdrop and it redirects me to index.php?controller=prices-drop. Any idea? Thank you

[be_tnt]

I tried to move this block in different position in the code but it does break the link to CMS page. The only way to make it work was to comment it out. Not sure about impact.

 

Not sure to understand your question about pricesdrop. Is it related to the same topic?

[rusteh]

It works for me commenting the code above. Yes the question about pricesdrop refers to this topic.

 

I did the following:

1. Removed prices-drop from Seo&Urls pages;

2. Tried adding again the same page, but it's named "pricesdrop" and the deleted one was named "prices-drop"

3. If i rewrite the "pricesdrop" page it redirects me to mywebsite/index.php?controller=prices-drop

4. Now I cant add "prices-drop" page because it isnt there

 

Thank you for your feedback.

[be_tnt]

ah ok I see what you are talking about: one of the cms page.

 

Did you remove the cms page or only the SEO information? Did you try cleaning your cache (browser and smarty [btw better for dev env to force the recompile each time)?

[rusteh]

I removed it from seo information but now when im trting to add it again there is no prices-drop. Its named pricesdrop and i believe that its not the same page. Deleted cache from smarty compile and theme and still the same result.

[be_tnt]

Do not see what's the issue but I have noticed that if I comment out the "set default routes", the top menu does not have the correct link anymore (it does use non SEF links).

 

If I uncomment it and just have it at a first place, any CMS page access return 404 ... pfffff

 

Is there anyone knowing a little more prestashop development??

[be_tnt]

oh my mistake ... some CMS pages do not seem to exist by default so the 404 lol

 

So for the moment, the best (at least forme) is to move the default routes juste after the $context variable assignment.

[rusteh]

This solution still works as the previous, i mean. It redirect corectly for categories/products but doesnt work for cms pages, and pages added from seo-url.

 

I'm currently sticking to the first fix.

 

Did u try to rewrite wishlist page, favorite products page or cashondelivery-validation page?

It redirects to mysite/{rewrite}?module=blockwishlist&controller=mywishlist and should redirect to mysite/{rewrite}.

 

I really dont undestand whats happening with this functionality.

Edited January 17, 2013 by rusteh (see edit history)

[be_tnt]

I have not idea of what is going on. I am quite newbie with prestashop ...

[be_tnt]

to make it work, I have commented the code for the default routes AND deactivated in the backoffice the automatic redirection to canonical URL.

[rusteh]

to make it work, I have commented the code for the default routes AND deactivated in the backoffice the automatic redirection to canonical URL.

 

That works for pricesdrop now, redirect corectly to mysite/discounted but dont work for other modules.

 

I've tried adding again wishlist as {rewrite} to wishlist, but i think it must be added in dispatcher and I dont know how to remove the conditioning of {module} and {controller} it should be only mysite/{rewrite} as in mysite/wishlists not mysite/wishlist?module=blockwishlists,etc.

 

A help from a moderator would be nice, because I still think its a bug.

Edited January 17, 2013 by rusteh (see edit history)

[be_tnt]

aaahhhhh this SEF stuff will make me crazy.

 

This morning I have changed the URL of my site (defined without www) as suggested by BO and since that, the SEF links are not working correctly anymore.

 

First I had to regenerate the .htaccess file because pictures disappeared after the change.

Now I am still facing one issue: the top menu got incorrect link: index.php?controller=category_rule&id=3&rewrite=musicotherapie&meta_keywords=&meta_title=

 

What is going on with SEF?

 

As asked by rusteh, could a moderator have a look on this topic?

 

Thx!

[be_tnt]

Checking the content of the loaded routes (when generating the top menu), I miss the category_rule ..; trying to find why ...

 

hmmm the ps_configuration table has a null value for PS_ROUTE_category_rule ....

 

ok found ... if you use a default rule value (in BO - section SEF), the ps_configuration contains NULL. As the default routes load has been commented out to solve other problems, that's why I do not have the default routes in routes variable and so the links are incorrect

Edited January 18, 2013 by be_tnt (see edit history)

[be_tnt]

ok I think I have found a more stable solution to fix SEF schema.

 

It's only missing a test in the load of default rules: if the route is not defined, then add the default one. So it gives:

 

  // Set default routes
		foreach (Language::getLanguages() as $lang)
			foreach ($this->default_routes as $id => $route)
				if (!isset($this->routes[$lang['id_lang']][$id]))
					$this->addRoute(
						$id,
						$route['rule'],
						$route['controller'],
						$lang['id_lang'],
						$route['keywords'],
						isset($route['params']) ? $route['params'] : array()
					);

 

This code has to be at the end of the loadRoutes() function.

Edited January 18, 2013 by be_tnt (see edit history)

[rusteh]

Hi,

 

Ok, so how is this more stable then the last one? I'm still with comment and disabled cannonical.

You have enabled canonical url and it works too?

 

Did you tried adding new pages?

 

Thanks

[be_tnt]

Now it will load the default routes in the routes variable without overwritting your custom ones. As you can see the code is not commented anymore.

 

I did not try with canonical URL yet.

[be_tnt]

ok I enabled Canonical URL again and it looks like everything is working. Hope it's the same for you.

[benjamin utterback]

Hi be_tnt, can you try this new dispatcher.php file , it was updated 2 weeks ago to fix the schema update.

 

Here it is at github...https://github.com/B-Utterback/PrestaShop/commit/d49b13579b08111f8b7f59277126783a86cdfdf4

[be_tnt]

Hi Ben,

 

I have proposed a fix on github for this issue : https://github.com/PrestaShop/PrestaShop/pull/228

 

The one in the link you gave is not enough from mypoint of view to fix the issue.

[eduardo.miranda]

Hi Benjamin,

 

I agree with be_tnt. The updated Dispatcher.php class you referenced at github is an old one, which in fact is already part of PS v1.5.3.1. And this version do have the critical issue that everybody is complaining about at this post.

 

I'm using the last fix proposed by be_tnt and it was the best solution I've found so far. But I still don't know if it may cause other side effects.

 

Is there a planned official fix for this bug?

 

Since this bug causes heavy impact on SEO (due to the crashed URLs), I understand it is a critical one.

 

Thanks

[be_tnt]

hello,

 

fyi i am still waiting for a feedback about this fix.

[rusteh]

It would be great to have a fix for this as it's a critical bug.

[perusi]

same f***** problem here with the latest PS 1.5.3.3 released on 31th of Dec 2012. I made the modification suggested by be_tnt. I don't know how PS team can allow this kinds of problems... rumours are that some of PS team managers were fired last year and now they hired some beginners

[shoulders]

For those of use who cannot use github. here is the PS 1.5.3.1 Dispatcher.php file with the modification in.

 

This fix is working on my site, basic tests run etc..

 

@be_tnt - thanks for the work to fix this. i really do not understand why the PS have been so lazy about this issue considering it must of broke a majority of the sites that upgraded out there.

modified 1.5.3.1 -Dispatcher.php

Edited February 21, 2013 by shoulders (see edit history)

[shoulders]

@be_tnt

 

my Dispatcher.php seem to make the category block not work. i must of made a mistake. i cannot understand github whatsoever it is confusing. is there any chacne you could supply your working 1.5.3.1 Dispatcher.php for me and i will remove this one.

 

thanks

 

shoulders

[be_tnt]

@shoulders,

 

Attached the overriden class Dispatcher. Please copy this file under /override/classes (check first if the file already present there does not have content in it).

 

Dispatcher.php

Edited February 27, 2013 by be_tnt (see edit history)

[rusteh]

I'll try to update this tommorow and get back to you. Did u try updating to 1.5.3.3 and see if it was fixed this issue? Thank you!

[shoulders]

I havent tried the latest version. I don't know how to download from github.

 

I have now made sure i am subscribed to this thread.lol

 

[shoulders]

I have maybe found where is the issue.

 

In \classes\Dispatcher.php, functions loadRoutes(): it loads the default routes in the routes array after the custom ones. Result your custom routes are overwritten by the default ones.

 

To test, I have commented the following code:

 

// Set default routes
 foreach (Language::getLanguages() as $lang)
  foreach ($this->default_routes as $id => $route)
$this->addRoute(
 $id,
 $route['rule'],
 $route['controller'],
 $lang['id_lang'],
 $route['keywords'],
 isset($route['params']) ? $route['params'] : array()
);

 

and after that, I got the customized URL format.

 

Looking the code for 1.5.2, you can see that this call to load default routes was done at a first step in this method. This has changed with 1.5.3 (I do not know why).

 

just incase this makes any difference. this was altered to prevent an infinite loop

[benjamin utterback]

I havent tried the latest version. I don't know how to download from github.

 

I have now made sure i am subscribed to this thread.lol

 

You don't need to actually download, you can just copy and paste the code.

 

(If you can download the code, I'm not sure how to)

[shoulders]

You don't need to actually download, you can just copy and paste the code.

 

(If you can download the code, I'm not sure how to)

 

many thanks, i am just trying to get my head around it. not as tricky as the forge though. I jhave just found a button called 'RAW' and that seems to of given me a page i can just cop and paste, hopefully with the applied changes.

[shoulders]

i can confirm the update code (i applied it right yay) allows the actuall products to work but mangles up the categories block. it causes the links in categories to go to products.

 

I am going to have a play.

[shoulders]

My url set

• custom product url - {id}-{rewrite}{-:ean13}
  
• rest standard and untouched
  

 

i have tried everything within my coding skills and i have come to the conclusion the code is flawed.

 

basically the custom url section build all potention custom urls for the request and then the default rules section overide all of the rules just created.

 

be_tnt had the right idea to add a conditional statement into the default rules section. but it is impossible to set a rule based on what the customurls section has done because it seems to populate all version of the url so they are all 'true' and i cannot distinguish between them.

 

i have tried

• be_tnt method - best is the product urls work. categories show correct link but redirect to a product when clicked
  
• !array_key_exists() - category links show non sef links but dont work, get a 404 product links work
  
• deleting the default rules - causes no links to work
  
• tried putting default rules first - causes the infinite route
  
• some oher things i forget now
  

if anyone can help. i am surprised how few people are having this issue.

[shoulders]

DIRTY SOLUTION

 

edit the default rules in Dispatcher.php untill the prestashop team fix it. Go on, you know you want to.

[gonssal]

Hi.

This is working for the rewrite rules I have set on my installation, version 1.5.3.1.

 

For what I've seen on the code, this might not work for all your rewrites due to the regular expressions used being not the best I've seen. So if some rewrites fail, modify them.

 

File to modify: /classes/Dispatcher.php

 

Remove the foreach that follows the "Load custom routes" comment (line 428).

 

Replace the foreach that follows the "Set default routes" comment (line 442) with this one:

 foreach (Language::getLanguages() as $lang) {
  foreach ($this->default_routes as $id => $route) {
if ($this->use_routes and $custom_route = Configuration::get('PS_ROUTE_'.$id)) {
 $this->addRoute(
  $id,
  $custom_route,
  $route['controller'],
  $lang['id_lang'],
  $route['keywords'],
  isset($route['params']) ? $route['params'] : array()
 );
 $this->default_routes[$id]['rule'] = $custom_route;
}
else {
 $this->addRoute(
  $id,
  $route['rule'],
  $route['controller'],
  $lang['id_lang'],
  $route['keywords'],
  isset($route['params']) ? $route['params'] : array()
 );
}
  }
 }

 

Please note this is a fix i've put in place after looking at code for like 10 minutes. It shouldn't, but it could break things, so check that everything works on your installation.

 

Also please note that the proper way of doing this is by using overrides, not modifying the original file.

Edited March 9, 2013 by gonssal (see edit history)

[charlie123]

DIRTY SOLUTION

 

edit the default rules in Dispatcher.php untill the prestashop team fix it. Go on, you know you want to.

 

I just wanted to remove EAN13 from my links at the end, so I've changed line 123 from:

 

'rule' => '{id}-{rewrite}{-:ean13}.html',

 

to

 

'rule' => '{id}-{rewrite}.html',

 

So far everything is ok.. is it the safe solution tho?

[artofadornment]

@shoulders,

 

Attached the overriden class Dispatcher. Please copy this file under /override/classes (check first if the file already present there does not have content in it).

 

Dispatcher.php

 

I'm using 1.5.3.1 and tried be_tnt's solution and it works great! I'm still clicking everything I can possibly click to make sure nothing is broken, so I'll post here is I discover anything. But so far, everything is working well. Thanks!!

[skyavis]

First install:

http://www.prestashop.com/forums/topic/204935-override-friendly-urls-without-id-number-for-v15/

 

Then try this .... {category}/{-:ean13}{rewrite}/

 

This worked for me!

[Crympton]

Many thanks, helpful discussion about this problem.

[cutecat]

I am using 1.5.4 currently.

 

starting I had change my default code from {category:/}{id}-{rewrite}{-:ean13}.html to {id}-{rewrite}{-:ean13}.html and it works fine.

 

Then I thought, I have already pasted quite a lot of my products on other site to promote them. When they click on that link, it will show 404. So I have changed back to default.

 

Now I am having an issue in the backend. When I click on my product review, it turns out to be {id}-{rewrite}{-:ean13}.html instead of {category:/}{id}-{rewrite}{-:ean13}.html

 

Can anyone help?

 

Would like to seek for some help.

Either by redirect {category:/}{id}-{rewrite}{-:ean13}.html to {id}-{rewrite}{-:ean13}.html, so that my customers will not see the 404 error code.

 

Or change the backend preview to {category:/}{id}-{rewrite}{-:ean13}.html again...

[cutecat]

anyone got this problem that i am currently having?

[subfor]

SOLUTION GOES LIKE THIS

 

1) Open classes/Dispatcher.php

2) Find:

 

// Set default routes

foreach (Language::getLanguages() as $lang)

foreach ($this->default_routes as $id => $route)

$this->addRoute(

$id,

$route['rule'],

$route['controller'],

$lang['id_lang'],

$route['keywords'],

isset($route['params']) ? $route['params'] : array()

);

 

3) Move that code part above:

 

// Load custom routes

foreach ($this->default_routes as $route_id => $route_data)

if ($custom_route = Configuration::get('PS_ROUTE_'.$route_id))

foreach (Language::getLanguages() as $lang)

$this->addRoute(

$route_id,........

 

That's it.

 

P.S. The code might differ due different Prestashop versions but the main idea is that Default Routes loading would be before custom routes loading.

Edited June 19, 2013 by subfor (see edit history)