Тут всё описано - Screenshot by Lightshot
файл - /app/addons/seo/func.php
Например урл
domen1/blog
domen2/blog
Не даст сделать так, потому у двух клиент сломано и пустота идет в - $condition
где должно быть проверка на айди витрины.
1 лайк
Не проходит проверку условие - fn_allowed_for(‘ULTIMATE’)
у клиента версия - define(‘PRODUCT_EDITION’, ‘ULTIMATE’);
и куча витрин, вообще не понятно как оно ещё работает без этих проверок в режиме мультивитрины - Screenshot by Lightshot
В итоге понял что для урлов в seo_names не хранятся данные по айди компании.
Шейринг урлов на витрины идет тут - cscart_ult_objects_sharing
Уважаемая тех поддержка напишите пожалуйста. Так и должно работать?
Если урл - blog есть на одной витрине, его нельзя использовать на другой? - Screenshot by Lightshot
Присоединяюсь к важности проблемы.
И еще добавлю аналогичную проблему для мультиязычных сайтов.
Где в урл есть язык.
Невозможно сделать
Сайт/ru/blog
Сайт/en/blog
Только так
Сайт/ru/blog
Сайт/en/blog-en
Нужна привязка урлов к витрине и к языкам при проверке их занятости.
2 лайка
На языки я фикс написал, скину позже. Даёт делать один код для разных языков
1 лайк
@Upmycart Контентные страницы (в том числе страницы блога) можно пошарить на несколько витрин, поэтому CS-Cart не дает создать повторяющиеся SEO имена.
2 лайка
И не даёт править страницу на расшаренных витринах - Screenshot by Lightshot, чтобы поставить свой контент.
Кто это придумал? Правильное решение убрать этот шейринг, я не знаю кому нужны одиннаковые страницы на разных витринах(доменах)
Банально страница контакты, как мне клиенту обьяснить, что она должны быть одиннаковая везде, или ему надо везде ставить новый урл?
contacts
contacts-ru
contacts-ru-1
contacts-ru-2
Идеально убрать возможность шейрить на витрины. Писать пометку company_id прямо в seo_names и проверять хотя бы для типа - “a” на компани и давать делать один раз, свой урл для каждой storefront
2 лайка
Так а почему нельзя?
Домен будет разный. Поэтому полный URL страницы будет также разный для разных витрин.
Поэтому проблем для индексации не возникнет.
Сопровождать такие барикады сложно, что мешает просто назвать чуть по иному страницу, суть от этого не меняется.
Мелкая хотелка, а головников на месяцы разработки
site1.com/blog
site2.com/blog? почему для второго сайта должен быть другой урл? тем более он часть используется как путь для статей в нём.
Я не понимаю, почему вопрос логичности всегда в сторону того, какую не логичную логику заложили изначально и нету желания баги, называть багами.
"Невозможно сделать
Сайт/ru/blog
Сайт/en/blog
Только так
Сайт/ru/blog
Сайт/en/blog-en"
- это тоже нормально?
Вот другая ветка - Урлы с "/0/" - #8 от пользователя Upmycart
Серьезная проблема и нету реакции. И потом проекты обрастают вот такими фиксами…
1 лайк
Как и обещал. Я делал примерно так, по коду там понятно. Это вместо строки:
$exist = db_get_field(
“SELECT name FROM ?:seo_names WHERE name = ?s ?p AND (object_id != ?i OR type != ?s OR dispatch != ?s OR lang_code != ?s) ?p”,
$_object_name, $path_condition, $object_id, $object_type, $dispatch, $lang_code, $condition
);
//Kucher, фикс, чтобы давало использовать один и тот же урл, для двух языков
if(Registry::get('addons.seo.seo_language') == 'Y'){//Проверка, что включено выводить две буквы языка в url
$exist = db_get_field(
"SELECT name FROM ?:seo_names WHERE name = ?s ?p AND (object_id != ?i OR type != ?s OR dispatch != ?s) ?p",
$_object_name, $path_condition, $object_id, $object_type, $dispatch, $condition
);//Kucher, убрали проверку по языку
}
else{
$exist = db_get_field(
"SELECT name FROM ?:seo_names WHERE name = ?s ?p AND (object_id != ?i OR type != ?s OR dispatch != ?s OR lang_code != ?s) ?p",
$_object_name, $path_condition, $object_id, $object_type, $dispatch, $lang_code, $condition
);
}
/*Kucher, old
$exist = db_get_field(
"SELECT name FROM ?:seo_names WHERE name = ?s ?p AND (object_id != ?i OR type != ?s OR dispatch != ?s OR lang_code != ?s) ?p",
$_object_name, $path_condition, $object_id, $object_type, $dispatch, $lang_code, $condition
);
*/
2 лайка
Сейчс все работает в разрезе страница + в базе хранится информация в разрезе языков и если их много то база раздувается, если идти простым путем и хранить информацию в разрезе ещё и витрин, то БД можно будет с лёгкостью загладить.
Сейчс администрирование мультиязычности то ещё удовольствие, а если сопровождать ещё и мультивитринность, то это будет приводить в фатальным ошибкам, тормозам и головникам для разработчиков приложений.
Ещё один пример, в модуле ТИЛЬДА мы выгружаем контент в разрезе языков и макетов для конкретной страницы, а если использовать иную логику то это усложнит администрирование и разработку.
Тогда проще не продавать версию Ультимейт. Потому что нету не одного нормально для клиента объяснения почему:
Нельзя использовать на двух витринах использовать
http://site1.com/blog
http://site2.com/blog
и
"Невозможно сделать
Сайт/ru/blog
Сайт/en/blog
Только так
Сайт/ru/blog
Сайт/en/blog-en"
Второе я поправил, там нету проблемы никакой. Можно было бы давно поменять в движке.
Второй вариант, если давать share страницы на другие витрины, как сейчас в коробке, то сделать чтобы название, описание, мета теги, можно было прописывать свои для каждой витрины, как “расшаренные” карточки товара. Это как второй вариант решения. Может он был бы проще, и не было в админка вагона одиннаковых страничек для каждой витрины.
Добавить эту логику не сложно, доработать модуль SEO, но если АДмин будет делать хаотично свои действия, то нужно будет делать защиту от дурака и это будет вечный Ад.
Мы все еще говорим о двух страницах с одним URL. Если пошарить одну страницу на разные витрины, то проблемы не будет. У нее будет адрес storefront1/seo_name на первой витрине и storefront2/seo_name на второй.
А вот если добавить на второй витрине еще одну страницу, с тем же SEO именем, то начнутся проблемы.
Предложение @Upmycart хорошее. Создам Featrue request для разработчиков, но не могу обещать что сразу возьмем в работу
5 лайков
Тогда нельзя контент править страницы для каждой витрины.
Пример страница Контакты, она не не нужная одинаковая.
Какой вариант кажется вам удобнее? Отдельные страницы с одинаковыми SEO именами или возможность задать свой контент для каждой витрины у одной пошареной страницы?
Не очень понятен смысл функционала расшаривания страниц. Чтобы сэкономить место в БД? Мне кажется, правильнее сделать функционал копирования страниц на витрины и там каждый с ними что хочет делает. Лишнюю проблему создали на ровном месте.
1 лайк