| |||||||||
| |||||||||
Добрейшего денька!
При создании нового товара не создаются разделы и, соответственно, не создаются и товары. Индексацию, после создания товара провел. Пытался проблему понять, но неудачно, а потому обращаюсь за помощью.
Вот сообщение при завершении добавления нового товара:
MySQL DB UPDATE OK
Правка DB - Успешно!
Admin speedup - Да
Список изменений: Раздел (Подраздел) - Нет
Изменения приняты!
Подскажите, будьте любезны, что не так?
При создании нового товара не создаются разделы и, соответственно, не создаются и товары. Индексацию, после создания товара провел. Пытался проблему понять, но неудачно, а потому обращаюсь за помощью.
Вот сообщение при завершении добавления нового товара:
MySQL DB UPDATE OK
Правка DB - Успешно!
Admin speedup - Да
Список изменений: Раздел (Подраздел) - Нет
Изменения приняты!
Подскажите, будьте любезны, что не так?
После последней индексации не могу перейти в меню вообще. По новой запускается индексация.
Добавление товара снова:
MySQL DB UPDATE OK
ERROR! File ../admin/db_rus/db_index.txt.fb5d949c0b0e2c1ac37befe1d5240171 is empty!Правка DB - Успешно!
Admin speedup - Да
Список изменений: Раздел (Подраздел) - Нет
Изменения приняты!
MySQL DB UPDATE OK
ERROR! File ../admin/db_rus/db_index.txt.fb5d949c0b0e2c1ac37befe1d5240171 is empty!Правка DB - Успешно!
Admin speedup - Да
Список изменений: Раздел (Подраздел) - Нет
Изменения приняты!
В общем продолжая тыкать по кнопкам я откатил последние действия и в итоге у меня получилось создать товары и категории. При этом после индексации я подождал минуты 2, прежде чем их увидел.
Однако, я не могу их ни отредактировать, ни удалить. Получаю сообщение: Товар с этим ID не найден!.
Однако, я не могу их ни отредактировать, ни удалить. Получаю сообщение: Товар с этим ID не найден!.
Ситуация следующая... Возникло у меня подозрение, что база у меня файловая почему-то, хотя установка изначально была с прицелом на использование MySql, параметры подключения к которой я и указал. Проследовав по пути ADM--Дополнительно--Миграция файловой базы в MySql у меня началась та самая миграция. После этой операции сайт стал работать значительно стабильнее, даже появилась функция удаления товара, но при попытке удалить позицию я получил то же сообщение: Товар с этим ID не найден!
В общем, пока понятно то, что ничего не понятно
В общем, пока понятно то, что ничего не понятно
Мы наблюдаем 5 таблиц и они пустые. При этом кодировка ШВЕДСКАЯ!
Пофиксено в 7.73 + Поправлены многие СП модули, включая просмотр СП заказа, после отправки.
Спасибо, коллега! Сегодня протестим, ну и за мной не заржавеет, конечно!
octogen: ну и за мной не заржавеет, конечно!
указано красной стрелочкой на скриншоте сверху
щютка
Ну чем черт не шутит, глядишь и попрет финансирование на такие суммы
СП доработана
-добавлена возможность заказа без регистрации
-улучшен админ СП и версия для печати
-доработан механизм отображения инфы и самого заказа
-доработан механизм СП-корзины
-добавлена возможность заказа без регистрации
-улучшен админ СП и версия для печати
-доработан механизм отображения инфы и самого заказа
-доработан механизм СП-корзины
Приветствую!
Необходимо снова обновиться? Я обновлялся вчера... Операцию необходимо повторить?
Из замеченных багов:
Вчера под админом вручную создал пару товаров. Удалением всех товаров в панели ADM вычистить их не удалось, записи в таблице остались (естественно провел индексацию). Пользователь АДМИН их удалил по отдельности - таблица в MySql пуста. Однако браузер мне их кажет по-прежнему. Вопрос: всем пользователям придется чистить кеш браузера или каким будет решение? Простое обновление страницы нужного результата не дает. Такие дела...
Вот оно че! Товары мои опять лежать в файловой базе... И прибить я их не могу чего-то пока...
Необходимо снова обновиться? Я обновлялся вчера... Операцию необходимо повторить?
Из замеченных багов:
Вчера под админом вручную создал пару товаров. Удалением всех товаров в панели ADM вычистить их не удалось, записи в таблице остались (естественно провел индексацию). Пользователь АДМИН их удалил по отдельности - таблица в MySql пуста. Однако браузер мне их кажет по-прежнему. Вопрос: всем пользователям придется чистить кеш браузера или каким будет решение? Простое обновление страницы нужного результата не дает. Такие дела...
Вот оно че! Товары мои опять лежать в файловой базе... И прибить я их не могу чего-то пока...
Вы не понимаете как работоает EWC в СП режиме
Индексатор собирает товары из файловых минибаз, приканчивая (дропая) общую таблицу и при индексации ее заполняя. а потом индесатор раскидывает товары по индексным базам, фасетам и кешу - они файловые.
Админ такой же юзер - убить может в личном кабинете - "Ваши товары", а не в интерфейсе магаза (он не для СП)
Убивание товаров в уже индексной базе не убивает их в MySQL базе, так что убивайте где сказал.
Убиение товаров в индексной базе работает только НЕ В РЕЖИМЕ СП
А вообще читайте про то как EWC хранит БД товаров и не путайте Основную БД с фасетами, индексами и кешем.
Тут сложная структура для работы с огромным кол-вом товара, а не жалкими несколькими тысячами, поэтому пришлось делать аналог СУБД и Сфинкса.
в MySQL хранятся сами товары а не их индексы и не индексные базы и это правильно с точки зрения безопасности (при всех преимуществах обмена с другими движкам и и модулями)
Но в режиме СП как я сказал MySQL база дропается каждый раз при индексации и заново заполняется. тем самым удаляются удаленные товары и отвергаются неизбежные дубли.
Индексатор собирает товары из файловых минибаз, приканчивая (дропая) общую таблицу и при индексации ее заполняя. а потом индесатор раскидывает товары по индексным базам, фасетам и кешу - они файловые.
Админ такой же юзер - убить может в личном кабинете - "Ваши товары", а не в интерфейсе магаза (он не для СП)
Убивание товаров в уже индексной базе не убивает их в MySQL базе, так что убивайте где сказал.
Убиение товаров в индексной базе работает только НЕ В РЕЖИМЕ СП
А вообще читайте про то как EWC хранит БД товаров и не путайте Основную БД с фасетами, индексами и кешем.
Тут сложная структура для работы с огромным кол-вом товара, а не жалкими несколькими тысячами, поэтому пришлось делать аналог СУБД и Сфинкса.
в MySQL хранятся сами товары а не их индексы и не индексные базы и это правильно с точки зрения безопасности (при всех преимуществах обмена с другими движкам и и модулями)
Но в режиме СП как я сказал MySQL база дропается каждый раз при индексации и заново заполняется. тем самым удаляются удаленные товары и отвергаются неизбежные дубли.
Доброго времени суток.
Проблема. Не создается категория товаров. Все так же как у octogen. Прочитав все Ваши сообщения по этому поводу, так и не поняла как решается проблема. Все сделала как в Вашей инструкции. (После 33 попытки занести товар, в какой-то момент товар все же появился, я решила его отредактировать и после этого он опять пропал)
Проблема. Не создается категория товаров. Все так же как у octogen. Прочитав все Ваши сообщения по этому поводу, так и не поняла как решается проблема. Все сделала как в Вашей инструкции. (После 33 попытки занести товар, в какой-то момент товар все же появился, я решила его отредактировать и после этого он опять пропал)
Категории товара создаются если в этой категории есть хотя бы один товар
если нет - то уничтожаются.
все это происходит после индексации товаров полной.
но если вы используете режим СП то тут совсем не так - заводить товары следует в личном кабинете, даже админам
и после индексации товар попадает в общую базу
при заведении товара непосредственно в общуюю базу он будет удален при индексации.
если нет - то уничтожаются.
все это происходит после индексации товаров полной.
но если вы используете режим СП то тут совсем не так - заводить товары следует в личном кабинете, даже админам
и после индексации товар попадает в общую базу
при заведении товара непосредственно в общуюю базу он будет удален при индексации.
Спасибо. Я использую СП, вчера методом тыка уже сама поняла, что через личный кабинет. Теперь не могу привязать товар к созданию закупки. Пока кнопка "создать закупку" не активна. При создании закупки дается только название и описание закупки нет привязки к товару.