replicant +1081

Для начала стоило бы уточнить какая тема дизайна используется. Если тема default, то в шаблоне home.html можно прописать вот такой код, например, между секциями CONTACT INFO и BULLETS

        {$categories = $wa->shop->categories(0, 0, true)}
        {if count($categories)}
            <ul class="tree">
                {foreach $categories as $cat}
                    <li>
                        <a href="{$cat.url}">{$cat.name}</a>
                    </li>
                {/foreach}
            </ul>
        {/if}

Это как минимум выведет список основных категорий на главную страницу. Оформление вывода и сам вывод уже надо подстраивать по месту. Можно вывести с подкатегориями, картинками и/или в несколько колонок. Это все решаемо, но было бы неплохо ориентироваться на сайт или хотя бы на скриншоты. Можно использовать плагин "Изображения для категорий" и снабдить категории картинками и сделать их вывод примерно так

<a href="{$cat.url}">
<img src="{shopCategoryImagesPlugin::getCategoryImageUrl($cat.id)}">
    {$cat.name}
</a>

Для максимально точного ответа надо больше исходной информации.

Как вариант можно вообще не указывать регион. Только страну указать и зафиксировать значение в настройках оформления заказа, если страна одна используется. Дальше покупатель сам, исходя из названия способа доставки, выберет подходящий. Самые популярные способы ставьте выше в списке.

Дело в том, что, если привязываться ещё и к региону или к городу, то могут возникнуть лишние проблемы с оформлением у не самых догадливых. Они и в поле город "маскву" с маленькой буквы через А напишут или транслитом коряво, а потом будут удивляться тому, что им ПВЗ в Москве не предлагает. Не старайтесь додумывать лишний раз за покупателя. Допустим покупатель из Москвы (в профиле адрес уже указан) заказывает на ПВЗ в СПб доставку, а ему из-за привязки к региону СПб вообще не выдаст. Такое допускать нельзя. Поэтому считаю, что в большинстве случаев надо давать выбор клиенту из полного спектра вариантов доставки + ещё один способ добавить типа "способ и стоимость доставки согласуется с покупателем по телефону" для тех, кому как бы ничего не подходит, а такие тоже найдутся и немало.

Мы видимо о разных плагинах говорим. Я про вот этот https://www.webasyst.ru/store/plugin/shop/deleteor...
В его коде реализованы самые простые запросы, которые убирают только заказы. С диска никакие файлы этим плагином не удаляются.

А плагин "Очистка" действительно имеет опцию удаления не только статусов, но и много чего ещё, поэтому, не разобравшись, можно натворить дел. Я бы тоже считал его опасным, но не потому что он плохой, а потому что он имеет огромный функционал по удалению всего подряд и случайно может привести к печальным последствиям, поэтому держать такую "бомбу" по рукой надо осторожно. Для зачистки магазина после тестовых заказов можно обойтись и более простым плагином удаления заказов или рецептом для ручной очистки базы через, например, phpmyadmin.

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

Если мне не изменяется память, то статусы заказов и их настройки (опции) даже в базе не хранятся, а лежат в wa-config в workflow.php

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

Уточнить ID заказа перед зачисткой
DELETE FROM shop_order;
DELETE FROM shop_order_items;
DELETE FROM shop_order_log;
DELETE FROM shop_order_log_params;
DELETE FROM shop_order_params;
DELETE FROM shop_sales;

ИЛИ ОЧИСТКА ЦЕЛЫХ ТАБЛИЦ
TRUNCATE `shop_order`;
TRUNCATE `shop_order_items`;
TRUNCATE `shop_order_log`;
TRUNCATE `shop_order_log_params`;
TRUNCATE `shop_order_params`;
TRUNCATE `shop_sales`;
TRUNCATE `shop_customer`;

Установка продаж в ноль
UPDATE `shop_product` SET total_sales = 0;

Дополнительные опции при удалении заказа по ID (customernotes_notes и bnpcomments - таблицы плагинов)
shop_product_stocks_log -> order_id
shop_customernotes_notes -> order_id
shop_bnpcomments -> order_id
wa_log -> params при условии action LIKE 'order%'

shop_affiliate_transaction -> order_id - историю бонусов надо обновлять

Достаточно зачистить все, кроме доп.опций, но можно покопаться и в них тоже.

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

Сама форма с кнопкой есть в product.cart.html. Cкрипт, отвечающий за "работу кнопки", в shop.js должен быть (он начинается с характерного комментария //add to cart). Часть скрипта добавления в корзину в случае выбора услуг на странице продукта описана в product.js. Ещё формы с кнопкой добавления в корзину прописаны в list-thumbs.html, list-thumbs-mini.html и т.п., смотря сколько у вас видов представления товаров на витрине.

Логичным видится вставка вашего события в shop.js.

Такой функционал реализован на сайте типографии https://50k.ru
Прекрасно работает и позволяет удалять и добавлять соц.профили через ЛК.
И да, это есс-но не Вебасист.

Привязки к соц.сетям удаляю вручную через таблицы в БД, удаляя или заменяя ключ соц.сети у юзера в wa_contact_data. Данные в поле field указывают на используемую соц.сеть.

Время от времени приходят запросы от покупателей сменить или убрать учетку соц.сети, но запросов таких очень мало. 1-2 в месяц максимум да и то не каждый месяц. Обычно аккаунт в соц.сети вещь более долгоживущая, чем аккаунт в магазине, а привязка эта внимания юзера не привлекает. Большинство юзеров вообще ничем не заморачиваются. Лупят заказ через купить в 1 клик и дело в шляпе.

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

А используют авторизацию через соц.сети намного больше. Примерно один из 50-55 покупателей применяет этот способ или хотя бы пробовал его. Ну и тут статистика у разных магазинов может отличаться.

Поэтому с одной стороны хотелось бы иметь функционал по удалению связи профиля и соц.сети, а с другой стороны глобально пофигу на это. Кому действительно надо, тот заведет себе постоянный аккаунт в магазине без привязки и будет им пользоваться, а одноразовые контакты того не стоят.

Список стран можно и почистить и оставить только регионы РФ. Это можно сделать руками в админке (регионы) или через БД напрямую (страны). Хотя, признаю, не очень удобно реализовано, когда часть можно сделать через админку, а часть нельзя. Было бы здорово иметь полноценный редактор стран, регионов и валют, включая символ рубля и т.п. Приходится иногда и в файлах править, если хочется заменить международный символ рубля на просто старый привычный руб или избавиться, например, от лишних валют.

В теме default 3.0 в шаблоне checkout.html строку
$('<span class="loading"> <i class="icon24 loading"></i></span>').insertAfter(f.find('input:submit:last').attr('disabled', 'disabled'));
надо перенести на 4 строки выше, а строку
$('<span class="loading"> <i class="icon24 loading"></i></span>').insertBefore(f.find('input:submit:last'));
которая получается на две строки ниже перенесенной у себя вообще удалил, т.к. два loading gif мне без надобности.

В качестве бонуса кнопку <input type="submit" class="large bold" value="[`Place order`]"> можно скриптом при клике заменять на какой-нибудь элемент div с текстом и анимацией, а саму кнопку переводить в display:none этим же способом. И кнопка глаза не мозолит и не скучно. Решение в три строки. Если надо, то могу сюда выложить.

Я себе тоже клонировал default тему и перебирал её на свой манер, но никаких сложных зависимостей от клонируемой там нет. Точнее даже не клонировал, а по сути переименовал и перестроил под себя, а тему default упаковал в tar.gz и бросил рядом.

Для магазина родительской темой parent_theme_id должна быть по идее site:oleg_default, а не site:default. Соответственно для site родительская тема должна быть не задана. Так будет проще и зависимостей не будет.

Думаю, что все ваши заморочки кроются в третьей строке themes.xml в /wa-data/public/shop/themes/oleg_default/ т.к. там содержатся зависимости темы магазина от темы сайта и т.п.

В theme.xml для сайта index.html должен быть прописан как custom="0", а уже для shop надо указывать как parent="1".

По большому счету в wa-apps/site/themes и /wa-apps/shop/themes вообще может быть пусто. Каталог может быть пустым. Это влияет лишь на обновления тем и возможные откаты к исходнику, но на работу никак. Просто на вкладке "Темы дизайна" в разделе "Установленные темы" будет пусто, а в инсталлере в разделе "Установлено" не будет значится ваша тема.

Куда именно в шаблон checkout.html это надо вставлять? В секции <script></script> не работает.

Лучше бы решение здесь в открытую опубликовали, чем выкатывать потом тихий теневой апдейт для темы default и откладывания проблемы в темный чулан. Подозреваю, что решение стандартное с переводом кнопки в disable при нажатии при условии отсутствия ошибок в заполнении полей.

Простой поиск вроде бы вполне корректно работает с такими ситуациями даже вне зависимости от порядка слов. А вот с умным намного сложнее. Там действительно беда. Слишком умный видать. :)))

Находишь в файле product.html примерно такие строки, где определяется кол-во изображений и начинается формирование блока галереи

 {if count($product.images) > 1}
    <div id="product-gallery">
....
        {foreach $product.images as $image}

и убери оттуда вот этот кусочек

 id="product-gallery"

У меня в бекенде магазина версии 6.3.0.44568 есть некоторые категории, которые тоже так себя ведут, а есть такие, которые редактируются нормально. Плагин Category Images версии 2.0.6.0 стоит и картинки у всех категорий есть.

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

Из кучи категорий примерно у 60% проблема есть, а у остальных нет.

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

Сам спросил. Сам себе и отвечаю. Т.к. в бекенде Шопа есть два вида вывода комментариев, то делаем вот так.

Таким образом изображения выводятся корректно в общей ленте всех комментариев всех продуктов (2-е условие) и всё работает на странице отдельно взятого продукта тоже так, как надо (1-е условие).

Попутно исправил "корявый" title для вышеупомянутого изображения в комментариях. Строка формирования title должна быть отформатирована как на скриншоте, а не разорвана пробелами, разрывами строк и табуляцией.

Немного повозился вчера в коде. Залез в нутро. И на коленке получилось простое решение в три строки, которое уже лучше, чем ничего.

В файле shopConfig.class.php в public function explainLogs($logs) надо прописать в конце ещё одно условие elseif (два там уже есть, одно про страницы, а второе про заказы) такого вида для событий category_edit и category_add

} elseif (in_array($l['action'], array('category_edit', 'category_add'))) {
 $url = $app_url.'?action=products#/products/category_id='.$l['params'];  
 $logs[$l_id]['params_html'] = '<div class="activity-target"><a href="'.$url.'">'.$l['params'].'</a></div>';

После этого в ленте событий появятся кликабельные ID категорий, которые редактировал пользователь в бекенде.

Если повозиться чуть дольше, то можно сделать как сделано с товарами, т.е. по ID's категории вытаскивать название этой самой категории и т.д. и т.п. (там в этой функции и пример по сути готовый есть), но меня конкретно ломало это делать. Для себя посчитал достаточным иметь просто кликабельный ID и на этом закончил.

А воз и ныне там. Тем не менее в базу данных в wa_log ложатся ID категорий, которые редактируются. Остается только эти ID взять и вывести в ленту.