Problem saving SEO url routes

[braffas]

Hello

First of all: Thanks for doing this! I really like the code changes in have seen in TB so far :)

There seems to be a problem with saving SEO url routes (nothing is saved in configuration). The default values from the dispatcher class is used when the form is reloaded.

I have upgradede a PS shop (1.6.1.11) to TB (1.0.1).

I have tried with no overrides and only native modules.

[Pilou]

Hello,

Have the same problem here https://forum.thirtybees.com/topic/249/url-changed-after-migration/26

[braffas]

The problem for me was that my changes did not show in the admin section, but they were applied.

The problem seems to be with the method below in AdminMetaController

/**
 * @param string $routeId
 * @param string $title
 *
 * @since 1.0.0
 */
public function addFieldRoute($routeId, $title)
{
    $keywords = array();
    foreach (Dispatcher::getInstance()->default_routes[$routeId]['keywords'] as $keyword => $data) {
        $keywords[] = ((isset($data['param'])) ? '<span class="red">'.$keyword.'*</span>' : $keyword);
    }
    $this->fields_options['routes']['fields']['PS_ROUTE_'.$routeId] = array(
        'title' =>    $title,
        'desc' => sprintf($this->l('Keywords: %s'), implode(', ', $keywords)),
        'validation' => 'isString',
        'type' => 'text', //<----- that needs to be 'textLang'
        'size' => 70,
        'defaultValue' => Dispatcher::getInstance()->default_routes[$routeId]['rule'],
    );
}

[Traumflug]

Thanks for providing this patch, @braffas. I can confirm this misbehavior.

While this change indeed appears to work, I think it's the wrong solution. This makes rewriting rules language dependent, rules are then stored in table tb_configuration_lang instead of tb_configuration. I don't think setting different rules for distinct languages works.

I'm currently searching for a better solution.

[Traumflug]

Funny: without the patch, these values aren't stored at all. The shown values are the default ones.

[braffas]

I just looked at my notes. I'm pretty sure the config is still stored in configuration_lang without the patch (AdminMetaController.php ~ 711 - 715), but the default values are shown because 'type' => 'text' are not handled by generateOptions in HelperOptions.php which fills the form. (textLang is handled)

[Traumflug]

Code snippets I found are a bit contradicting. Default values ignore the language. Installer installs apparently empty fields in configuration. Other code snippets, the one you found, too, handle it as language dependent.

This raises the question whether language dependent rewrite rules can work and if yes, whether they're a wanted feature. Having language dependent rewrite rules easily opens a can of worms, e.g. just switching the language might lead to a 404 page.

[braffas]

I totally agree. It was just a quick fix (I'm only using 1 lang so it worked for me). But you are totally right about the can of worms :)

I think the routes are better stored with no language dependency. It should be a pretty easy fix.

[Traumflug]

Done: https://github.com/thirtybees/thirtybees/pull/249

A couple of things I learned along the way:

• Language-aware rewrite rules are a pretty young, 30bz-only feature.
• They do work, switching languages on a product page changes it's URL as appropriate.
• Entries in configuration_lang aren't self-sufficient. They're kind of an add-on to an entry in configuration.
• Installer does indeed create ..._lang entries, my installed DB was too old.
• @braffas' patch is spot-on. Thank you.

[wakabayashi]

@Traumflug Thx a lot for this fix!

I noticed that the url showed on product editing (tab: SEO) doesn't show the correct path:

I use: {categories:/}{id}-{rewrite}

So the id is just missing. It's ofc not so important, but just wanted to note...

Edit: Just to make sure... "4" isnt the id. thats part of url rewrite...