replicant +1081

Первое с чем надо определиться в данной ситуации - это с тем как будете определять в какой категории был товар, которого уже нет?

В данной ситуации, на мой взгляд, решение зависит от типа URL страниц, который в вашем случае применяется.

В Магазине предлагаются три типа (не считая тех, что можно создать самостоятельно в routing.php):

Естественный
Страницы товаров: /category-name/subcategory-name/product-name/ Страницы категорий: /category-name/subcategory-name/

Смешанный
Страницы товаров: /product-name/ Страницы категорий: /category/category-name/subcategory-name/subcategory-name/...

Плоский (WebAsyst Shop-Script) Страницы товаров: /product/product-name/ Страницы категорий: /category/category-name/

Какой из них ваш?

Только в естественном случае можно хоть как-то отследить категорию товара. В остальных случаях по URL этого не сделать, а поскольку товар удален, то и в базе его уже нет и информации о категории тоже нет. Поэтому обратиться в базу тоже не получится.

Если только не хранить где-нибудь отдельную таблицу товарных передвижений (типа истории), связывающую для простоты product id, category id, category url, product url, но для этого такую таблицу надо создать, привязать к движку и автоматизировать её ведение.

Я думал у меня одного такой глюк случился. Внимание на это обратил, но забил, т.к. картинки загрузились и то хорошо. :)

Предлагаете уйти от MySQL в сторону, допустим, PostgreSQL или только хотя бы избавиться от MyISAM?

По поводу плагинов поддерживаю. Перед попаданием в магазин плагин надо очень тщательно "мучать" всеми способами, чтобы потом не было паники и ужаса.

В погоне за глобальным иногда забывается исправление мелких и средних багов, которых порой накапливается немало. В лучшем случае правятся только критические, потому что "народ уже бунтует". Фразы типа "качественные изменения" всегда необходимо тщательно расшифровывать, начиная с вопрошающей стороны.

Если упростить функционал, то в принципе зря тупил. Отказаться от JS крутилки картинок и подключить к миниатюрам или каким-нибудь эскизам 350х0 под основным фото напрямую swipebox, то и проблем нет, но тогда фото среднего размера 0x700 уже не посмотреть, кроме как главное (печалька). Однако теперь в swipebox можно задействовать вывод желанных title даже в режиме слайд-шоу для десктопного просмотра (ура).

{foreach $product.images as $img}
  {if $img@first}
<a href="{$wa->shop->imgUrl($img, '1280')}">
    {$wa->shop->imgHtml($img, '0x700', ['itemprop' => 'image', 'id' => 'product-image', 'title'=> $img.description|escape, 'alt'=>$img.description|escape, 'style' => 'max-height:400px;'])}
</a><br>
{else}
<a href="{$wa->shop->imgUrl($img, '1280')}">
    {$wa->shop->imgHtml($img, '350x0', ['title'=> $img.description|escape, 'alt'=>$img.description|escape, 'style' => 'max-width:150px;'])}
</a>
{/if}
{/foreach}

Хочется сохранить функционал в виде работающих квадратиков миниатюр 96х96 с просмотром среднего размера 0х700 в зоне увеличенного изображения, а 350х0 оставить для других задач.

Возможно придется задействовать другой JS скрипт для миниатюр и основного фото в карточке продукта или существующий переписать. В текущей версии alt и title будут такие, как у картинки выводимой при первой загрузке страницы продукта в качестве основного фото будь она какая угодно по порядку в массиве изображений. Впрочем, не исключаю, что не до конца разобрался с тем, что есть, но желание ковырять код на сегодня пропало.

Могу, но со временем совсем беда, т.к. своих несколько и два в неспешной разработке и ещё один в миграции с 309 версии. В режиме разовых консультаций мне было бы проще, чем подключаться на полный цикл. Конечно для начала хотелось бы оценить проект внешне. Мыло dm собака krasnоgorsk точка ru. Еще есть Телеграм постоянно онлайн.

На Фейсбук чего-то меняли в полях и какое-то время назад действительно поломалось. Они просто затерли URL в этом поле, поменяли название поля и просили ввести все заново, но в такой нелепой формулировке, что сразу не догадаться.

А каким образом у вас делается бекап? Это архив всего-всего дерева каталогов и файлов + архив с дампом БД или как-то иначе создан?

Есть 100500 причин, по которым сайт работает "медленно". Полная диагностика включает не только анализ состояния движка, кода шаблонов, состава плагинов, оптимизации графики, настроек кеширования контента и т.п., но и полную проверку веб-сервера, состояние баз данных, оценку производительности, разные нагрузочные тесты и многое другое. Есс-но оптимизация отдаваемого контента - очень важная часть работы. Над этим надо работать постоянно. Вроде бы уже все ок, но всегда где-то что-то можно сделать лучше и из этих мелочей складывается общая картина. Выбор хостинга крайне важен в данном вопросе. Между 6 и 7 версией на тестах нет никаких отличий в плане производительности. Основная засада, если отойти от вопроса проблем с сервером, как правило в плагинах, их количестве, качестве и способе применения, графике и безумной перегрузке шаблонов всякими скриптами по поводу и без и избыточными css. Оптимально исполненные страницы и браузером быстрее рендерятся вобщем-то. Браузеру ведь тоже не всё равно что ему прилетает от сервера. Иной контент его и в ступор вогнать может. Ну да это всё лирика. :)

На мой взгляд, оптимальная отдача контента, должна выглядеть примерно так.

Если не ошибаюсь, то при наличии у одного товара ряда артикулов с разными ценами на витрину выводится цена того артикула, который отмечен в настройках товара в пункте "Цены и наличие" переключателем. Если отметить артикул с наименьшей ценой, то эта стоимость и будет выведена в шаблоне list-thumbs.html например.

А вам нужно, чтобы всегда выбиралась наименьшая стоимость из всех артикулов независимо от основного артикула?

На примере list-thumbs.html заменяем $p.price на $p.min_price, но при этом $p.compare_price будет от артикула по-умолчанию, если это вас устроит.

<div class="pricing">
{if $p.compare_price > 0}<span class="compare-at-price nowrap"> 
{shop_currency($p.compare_price)}</span> {/if}
<span class="price nowrap">{shop_currency($p.min_price)}</span>
<meta itemprop="price" content="{shop_currency($p.min_price, null, null, 0)}">
<meta itemprop="priceCurrency" content="{$wa->shop->currency()}">
</div>

В зависимости от шаблонов таких замен может быть несколько и в разных местах. В некоторых шаблонах выводится сразу вилка цен от и до, но это тоже легко правится отключением вывода max_price, если надо заменить вилку на минимальную стоимость.

Искомый код у вас на сайте есть. Начинается он с <aside class="currency-toggle"> ... код ... </aside>.
Но по ощущениям сидит он не в футере, а в main.html (главный шаблон контента Магазина - Main storefront layout and navigation) где-то после строки {$content}. То, что вы его видите в футере не значит, что он там. Поищите ещё. Он не так глубоко спрятан. Почти на поверхности.

Вкладки - это видимо элемент дизайна какой-то. Общие рекомендации таковы. При создании страницы, которую надо скрыть, прописываете ей дополнительный параметр menu=hide, а в коде шаблона, где формируется вывод страниц должно быть примерно так.

{$site_pages = $wa->site->pages()}
    {foreach $site_pages as $p}
        {if $p.menu != 'hide'}
          <a href="{$p.url}" title="{$p.name}">{$p.name}</a>
      {/if}
    {/foreach}

Если, как вы говорите, у вас выбор валюты в подвале сайта, то в шаблоне footer.html надо поискать примерно следующий код. В нем должны упоминаться слова currency.

<div class="currency-toggle">
{if count($currencies) > 1}
<select id="currency">
{$currency = $wa->shop->currency()}
..... много букв ....
location.href = url + 'currency=' + $(this).val();
});
</script>
{/if}</div>

И для проверки заключить этот код в такие скобки {* код *} или вообще убрать, если совсем не нужен.

Если совсем похожего кода нет, но слово currency в шаблоне встречается, то просто скопируйте код шаблона и вам подскажут, что именно в нём надо убрать.

Ну да. Можно и так. Условие по url'ам. Просто увидел в примере попытки !$a@last и подумал про него. У меня, например, приложение Сайт есть, но в массиве wa-apps его нет, т.к. меню настроено вручную на два элемента, когда / = магазин, а /blog/ = новости.

Понял. Короче смотри. На самом деле это задается в двух местах.
Сайт - Дизайн - Настройки - Название поселения и ещё Сайт - Настройки - wa-apps меню - Настроить. Так вот это wa-apps меню является массивом с возможно несколькими элементами, причем, что самое интересное, во второй настройке название может не совпадать с первой настройкой. Из этого массива наверное и надо тянуть нужный элемент.

Код ниже выдернет из массива меню первый элемент и выведет его где надо.

{$apps = $wa->apps()}
{foreach $apps as $a}
{if $a@first}
    {$a.name}
{/if}    
{/foreach}

Соответственно $a@last - последний, а !$a@last - все, кроме последнего.

Про блог и категории не уловил суть. Вроде речь о приложении Сайт и страницах его шла. Что с блогом не так? У блога свой head.html по идее есть. Туда всякое для него можно размещать. А в записях блога отдельно корректно настраиваются теги OG.

Потому что {if} {else} {/if} требует закрывающей части. Нельзя открыть {if} и оставить просто так. Поэтому и падало.

Небольшой пример с контентом, чтобы просто навести на мысль.

<meta property="og:type" content="{if $page.og_type}
{$page.og_type}{else}website
{/if}" />

Для страниц, где тип контента указан, будет выводиться то, что указано. В остальных случаях website.

Я, прочитав вашу тему, заморочился для себя тоже такое сделать. У меня на сайте обычно страницы не используются, т.к. юзаю страницы магазина, где это работает из коробки, но ради морального удовлетворения запилил себе таки одну страницу. Всё вроде красивенько получилось.

В index.html head должен быть подключен так {include file="`$wa_active_theme_path`/head.html" inline}.

Еще совсем забыл среди ночи.
Для $page доступны следующие вещи.

    $page.title - заголовок
    $page.description - тут все понятно
    $page.keywords - тоже без комментариев
    $page.og_description - если делать отдельный description для соц.сетей
    $page.og_image - картинка
    $page.og_title - заголовок для социалок
    $page.og_type - тип контента
    $page.og_video - видос

    $page.test - дополнительный параметр с названием test

Все эти вещи обрамляем красиво тегами в head.html Сайта

Для примера строка title с проверкой на отдельный og_title

<meta property="og:title" content="{if $page.og_title}
{$page.og_title|escape}{else}{$page.title|escape}
{/if}" />

Для видео будет так

{if $page.og_video}<meta property="og:video" content="{$page.og_video}" />{/if}

Есть ещё небольшой лайфхак. Заходишь в редактор страницы и в дополнительных параметрах пишешь следующее:
descr=твой текст
ttl=твой тайтл

Затем в шаблоне head.html Сайта вытаскиваешь это через

<meta property="og:title" content="{$page.ttl}" />
<meta property="og:description" content="{$page.descr}" />
<meta property="og:url" content="{$wa->domainUrl()}{$wa->currentUrl()}" />
и далее любые поля по смыслу

Или, если не критично использовать те же значения, что и в основных мета, то см. совет выше.
Только не забудь проверку на {if $page.ttl} ну и т.д., чтобы теги с пустым content не выводить.

Там стоит установка "Использовать те же заголовки для соцсетей". Даже, если поменяем заголовки на произвольные. Разметка от этого разве появится на странице, созданной в приложении Сайт? Шаблон Дефолт 3.0.

Я бы в head.html приложения Сайт вставил вот такие строки

<meta property="og:title" content="{$wa->title()|escape}">
<meta property="og:description" content="{$wa->meta('description')|escape}" />
ну и т.д. по смыслу

Уже хоть что-то будет вместо ничего.

Ясно. Короче говоря от нечего делать изучил код этого repair'a в 7-ке, сравнил со старой версией, перенес и обкатал на 6.3.0 метод emptyPath от 7-ки. Все прекрасно зачистилось. Вручную сравнил результаты по логу очистки. Прогнал несколько тестов на очистку специально созданных папок-ловушек. Все получилось. Спасибо за наводку! :)))

На 7-й версии работает (проверил на тестовом магазине). А на 6.3.0.44568 выдает ошибку #500 и как следствие структуру не исправляет. Некоторые экшены в module=repair всё же работают, но далеко не все. Те, которые не работают, приводят к ошибке 500.

Совсем-совсем старую можно посмотреть вот так "ваш домен/published/wbsadmin/html/scripts/wbsadmin.php"

Есть простое решение совсем на коленке.

Допустим, если мы хотим блокировать кнопку Купить или процесс оформления заказа. Определяем точку блокировки и накидываем на неё условие такого типа.

{if (date('G') >= 20) || date('G') < 10 || in_array(date('N'), [6, 7])}
блокированный кусок кода шаблона
{/if}

Подобная конструкция может быть размещена в нескольких точках для блокировки возможности заказа (да и вообще для чего угодно) и не даст вывести нужный код после 20-00, до 10-00 и по субботам и воскресеньям.

При наличии прямых рук, светлой головы и полного доступа к шаблонам часы и дни работы можно даже вынести в настройки темы в файл theme.xml и включать по требованию эту систему.

Админу бы по ластам настучать для начала не помешало бы, если он есть конечно.

Вот тут есть краткая инструкция о том как это сделать https://www.webasyst.ru/store/plugin/shop/opt/help...

Ну и поддержка плагина тоже есть https://itfrogs.ru/feedback/#shop/plugins/opt

По-моему лишние страны удаляются через запрос к базе данных напрямую в таблице wa_country. У меня такой же вопрос давным-давно возникал и я даже искать эти способы не стал, когда понял, что через админку страны не удалить. Зашел в базу и убрал всё лишнее. С тех пор так и работает.

При беглом осмотре выяснилось, что если не в облаке сидите, то можно подправить в /wa-apps/shop/widgets/sales/lib/shopSales.widget.php в функции getGraphData переменную $start_date и настанет счастье.

Есс-но это не то, что переписать целиком виджет с новыми настройками, но уже хоть что-то.

Да вроде бы теперь всё видно. Кеш браузера очистите на всякий случай.