100napb

есть два варианта настройки: а) использовать постфикс для отправки с собственного сервера. Тогда Вам нужен еще opendkim и spf типа v=spf1 ip4:ваш.ай.пи.адрес include:_spf.yandex.net ~all. Работает быстрее. Фризов нет. б) настроить постфикс для отправки почты через сервера яндекса (постфикс тут будет как relay): с аутентификацией на relayhost = smtp.yandex.ru. Работает медленнее.

никаких \ дефолтные : выбрать почтовый протокол "mail" постфикс в данном случае будет использоваться как relay для отправки через сервисы яндекса. Простейший пример\манул легко гуглится. Хотя этот, например. OpenDKIM не забудьте прикрутить, а так же корректно прописать spf и PTR записи upd: ах да. Вам здорово поможет https://www.mail-tester.com/ для отладки

смотрим шапку форума. не так давно там была реф-ссылка на админвпс. да

вставлю свои 5 копеек. в декабре работал с 2мя проектами, которые размещались у этого хостера. Жалобы на беспричинные лаги и периодические тормоза. У обоих проектов был диагностирован перегруз дисковой подсистемы ноды. Один проект перешел на мощный тариф с более интересными процессорами и, ессно, поменял сервер. Второй проект просто мотивированно настоял на смене ноды в рамках действующего тарифа. По итогу все ожило и там и там. Ранее не припомню за админвпс подобного. Выводы делать конечно рановато, но звоночки чет уж больно громкие.

загляните сюда: private function productContent в файле /catalog/controller/journal3/product_tabs.php а так же не проходите мимо настроек: J -> modules -> blocks. там можно неплохо кастомизировать и настроить внешний вид информации о товаре (привычные вкладки, которые)

этот блок насколько я помню отвечает за вывод какого-то дополнительного модуля (блоков?) жорнала. Ну те, которые можно привязать к разным лэйаутам. И контроллер $this->load->controller('journal3/product_blocks' как бы намекает на то же самое. Уточните вопрос, пожалуйста: где именно Вы хотите изменить описание товара? в карточке, в категории, в каком-то блоке\модуле. Потому что в модифицированном контроллере продукта все прозрачно

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

как по мне, так БД как раз-таки излишне нормализована. и это, иной раз, является причиной тормозов по мере роста размеров таблиц. взять к примеру хоть тот же getProducts... кто-то агрегаты создает, кто-то иные хранилища использует (sphinx), что бы обойти это на крупных проектах. в каком-то смысле, это во многом зависит от комьюнити: пока будет расти количество специалистов, способных решать задачи бизнеса и рынка, используя ОС - все будет хорошо и популярность будет только расти. Ко всему прочему, как ни крути, а стоимость разработки и старта проекта на ОС относительно других решений довольно низкая + есть необходимые модули для того что бы закрыть большинство типовых вопросов, есть шаблоны на любой вкус... ОС чем-то напоминает эксель, который вполне может побыть и простенькой товароучетной системой, и бухгалтерией, и отчетами - бери да пили под себя\под задачу, так как все относительно просто и понятно. в плане технологий, за 5 лет революции в вебе, которая уйдет в массы и задаст новые тренды, не случится - слишком велика инерция, слишком велика конкуренция.

верно, все в порядке. несколько раз просто подобное видел уже, но.. не в этот раз. возможно, кто-нибудь сможет угадать точнее :) я бы начал с проверки настроек сервера БД. если времени ожидать нет, то можете написать в ЛС - по факту разобраться будет куда проще. тем более, когда на vps параметры окружения могут быть настроены как угодно и гадания сильно осложняются...

давайте попробую ткнуть пальцем в небо ради спортивного интереса. у Вас хостинг \ vps сервер с панелью vesta ? если так, то, вероятно, у Вас не место на диске закончилось, а inod'ы. если угадал, то попробуйте почистить папку с сессиями и включите gc_divisor.

вряд ли. это же шаред. едва ли OOM killer там грохнет демона субд - все пользователи ноды бы заметили

нет. у gone away другие причины: как правило, это истечение одного из таймаутов или ограничение по размеру пакета. судя по запросу, тут какая-то попытка посчитать количество заказов с тем или иным статусом. и у Вас просто отсутствуют индексы в БД, из-за чего запрос выполняется слишком долго. в пхпмайадмине убедитесь что присутствует индекс в таблице oc_order для поля order_status_id вот тут можно посмотреть и создать, по необходимости ЗЫ: запрос к базе непутевый. множественные OR работают и оптимизируются плохо. заменить их на union - было бы намного быстрее... впрочем, и без этого, добавление индекса должно решить проблему

гуглите "Автоматически рекомендуемые товары chick"

вместо тыщи слов. тут вероятно, у Вас какой-то vqmod-модификатор, или напрямую кто-то очумелыми ручками в startup.php какой-то запрос к бд через озвученную выше устаревшую и небезопасную функцию замостырил. Это не решается установкой модуля пхп -это надо искать и переписывать \ удалять, ибо это грех рукожопие неправильно.

Спасибо.

График, безусловно, выглядит очень вкусно. Позвольте спросить, на какую дату(ы) приходились Ваши работы - что брать за точку отсчета? Ни в коем случае не хочу чего-то там доказывать, спорить, бросать тень и подобное. Однако, слабо верится, что причина подобного роста - это заслуга лишь оптимизаций сайта\сервера\увеличения скорости работы сайта в конечном счете. Вы с нами честны на 100% и все договариваете? Например, тактично умолчали о бюджете на маркетинговые мероприятия и рекламу, которая стала в разы эффективнее, когда сайт шустрее забегал, и которые владельцы площадки уже проводили сильно после работ? Я потому так думаю, что у меня есть немало примеров и наблюдений, так сказать, "до ускорения \ после ускорения". В том числе на достаточно крупных проектах. Определенно, почти сразу улучшаются поведенческие факторы, количество ботов \ генераций страниц и прочее (особенно визиты ботов - если ранее им не хватало "бюджета" ходить по медленному сайту, то после того как сайт начинает отвечать быстро, они прям яростно индексируют). Но что бы такой рост чистого трафика... может я недостаточный интервал времени брал для наблюдений, конечно. Но впечатляет, да.

Только ради Вас. Собственно, а куда ему вдруг пропадать из лога, если он входит в uri ? совершенно согласен. Тем не менее, это лучше чем ничего. Попытка ведь не пытка, тем более когда других вариантов неть =\ Для ТС: все-таки стоит проверить. Вдруг какая-то полезная информация да найдется. Можно чуть облегчить поиск, если искать подстроку order_id=%номер_нужного_заказа% И да. Модуль для логирования изменений, предложенный выше - отличное решение. на будущее) P.S.: если подозреваемый менеджер в прямом доступе, то можно даже хистори в браузере проверить.... это же менеджер, а не шпиён

Опенкарт из коробки не хранит данной информации - все верно. Однако, если сильно прижмёт, можно попробовать посмотреть в access логах веб-сервера: информация об айпиадресе, токене и времени там должна быть. Возможно, это поможет идентифицировать менеджера

встроенный в жорнал фильтр не имеет горизонтальной "темы". Изменить, конечно, можно: но это довольно хлопотное и недешевое мероприятие, да и игра с большой долей вероятности не будет стоить свеч, в том числе потому что а) фильтр этот, в целом, так себе б) вы не сможете в дальнейшем легко и просто накатывать обновления темы (а они довольно регулярные) Насколько я помню, фильтр Vier имеет неплохой горизонтальный внешний вид. Вдруг.

DevOps курсы онлайн [клик] Знающий не говорит, говорящий не знает (с). +1 Дело в том, что а) подобные работы требуют довольно комплексных знаний из разных областей б) что бы не "плыть" при малейшем изменении условий задачи, Вам необходимо понимание и знание самой методологии - без нее ценность прикладного опыта стремится к нулю. Причин может быть десятки. И еще больше - если реально "иногда". Если нужна помощь в оптимизации\ускорении - пишите в ЛС. нет ничего проще

если mysql более-менее свежий, то гляньте в сторону SELECT JSON_EXTRACT(custom_field, '$.5'), JSON_EXTRACT(custom_field, '$.7'), FROM .... где '$.5' или '$.7' - это ключи json-объекта

например в тех случаях, когда оптимизатор mysql решает, что фулскан таблицы ему будет быстрее сделать, чем выбрать даже используя индекс какое-то довольно большое (например, больше половины всех товаров) количество товаров из какой-то жирной категории. индекс по path_id - мастхэв для мелких категорий, все верно 👍

начните с консоли браузера. обращать внимание на наличие каких-либо редиректов после нажатия ентера + напишите нам итоговый url, по которому собственно "не найдено". вероятно, проблема связана с чпу\сео_про\.htaccess или банальным кэшем.

при этом, товар у которого остаток больше - будет идти первым. Чукча Выше дал более корректный совет: order by quantity > 0 где сортировка по сути будет по булевому значению: если остаток есть, то истина (1), если остатка нет, то ложь (0).

должна быть уникальность в таблице по тем полям, которые используются для определения партиций. подробнее тут Что бы на корню убрать дубли, проще всего сделать primary key (keyword, url_alias_id) присоединяюсь в вопросу. в данном случае, секционирование таблиц потенциально не принесет никакого профита по сравнению с обычным индексом.