sitecreator

А разве не релизнулся? Хоть и недавно, но доступен же. Перефразирую: доступно для использования везде. При желании. Если бы 9-ки не было в релизе, тогда был бы уместен подкол. Конечно, можно говорить про общий хостинг и его ограничения... Но ничто не мешает ставить и использовать 9-ку прямо сейчас везде на vds, а для опенкарт vds используется сплошь и рядом. По сути вопроса? На каком уровне находится совместимость с 8-й веткой, в частности, с 8.4? Бог с ней (с 9-кой), с 8-кой то как дела обстоят?

В требования не указано какие серверы БД поддерживает. В свое время mysql 8 не поддерживалась, только 5.7 максимум. Сейчас уже mysql 9 используется везде. Также есть mariaDB 11. Почему то нет никакой информации на этот счет? вот давно давно писалось о проблеме совместимости с mysql 8: https://github.com/opencart/opencart/issues/7709?ysclid=lzos8kxy8s497894261 посмотрел на гитхабе https://github.com/opencart/opencart/releases?page=1 только фиксы для работы с новыми версиями php (8.1, 8.2) Про БД ни слова... словно с ними нет никаких проблем? https://github.com/OpenCart-Club/opencart/releases тут лишь одно упоминание про mysql Так на каких версиях серверов БД работает без проблем? На всех новых mysql/maridb? И никакой известный модуль не привередлив к версии mysql? Возможно я отстал от жизни, и опенкарт без проблем работает с любой версией mysql/maridb? Хотя надо бы указывать минимальную, раз уж перешли utf8mb4? Впрочем, это любая mysql 5.7 - 9 (более раннюю не имеет смысла использовать, но на старом сервере заказчика с кучей софта может стоять и 5.5), любая mariadb.

актуально актуально. Почему то приходят на почту оповещения об ответах чат-бота на сообщения спамера, как ценная информация? Для чего оповещать о бесполезных, в данном случае вредных (автоматическая поддержка и продвижение спамера получается?) сообщениях бота, да еще на английском языке? Логично было бы запретить чат-боту писать на английском в ответ на спамерский текст на английском. На английском пишут только спам-боты. Вот и идет разговор двух ботов на отвлеченные темы...

В свое время advcash рекламировал "новый улучшенный advcash" - adv2 и предложили использовать его также и/или перейти в adv2. Спустя некоторое время пришло "письмо счастья" с информацией о том, что гражданам РФ пользоваться этим новым чудным кошельком нельзя. А начиналось то красиво. А юрисдикция adv2 - это Канада.

advcash скончался для вывода на карты РФ? пока можно пользоваться кошельками... Сменили юрисдикцию на "Канада" со всеми вытекающими... Раньше была "Белиз", т.е. оффшор, который к санкциям не присоединялся. Вывод на карты банков РФ исчез. Остается вариант через обменник, например, https://e-obmen.net полностью в автоматическом режиме. Проверил, работает. Есть некоторые опасения, что с новой юрисдикцией могут в принципе запретить использование кошельков.

На форуме есть свой спам-бот, который способствует продвижению стороннего спама? А зачем? Вот пришел обычный спамер с целью проспамить свой ресурс. А следом мгновенно появился местный бот и развил спамерскую идею почему-то на английском языке. И все это в теме, в которой обсуждались вполне конкретные вопросы. А нам нужна ли такая свалка из "полезных сообщений" бота на английском языке на отвлеченные темы? И нужно ли по этому поводу оповещать пользователей о "ценном ответе" на почту? Предлагаю бота настроить как-то более интеллектуально, чтобы он не реагировал на мусор. Хорошо бы, раз он и есть "искусственный интеллект", чтобы он сам противодействовал спаму, а не вступал с ним в союз. Он мог бы не отвечать на сообщения новорегов с одним единственным постом, т.к. нередко это спамеры. Да и писать на английском - это как-то не комильфо для интеллектуального бота русскоязычного форума. Может быть ему игнорировать сообщения целиком на английском, а лучше самому стучать на них куда надо как на подозрительные, особенно, если есть ссылка в них?

Вот вся информация по СДЭК. https://docs.apiship.ru/docs/delivery-services/list-delivery-services/cdek/ Там настроек то по СДЭК почти никаких нет. По отображению ПВЗ - точно нет. Загадка... и тупик пока

но этот ключ работает с самим СДЭК. и неверный ключ для СДЭК (Почты России и т.д. и т.п.) не позволит сохранить сам ApiShip. Вот пример если ввести неверный ключ: Вот мой пример для вполне правильного адреса в Москве. Пунктов ПВЗ через ApiShip нет. И это плохо. На "зеленом" форуме их тоже нет. А где они отвечают? Документация крайне скудная.

но сам то СДЭК видит кучу ПВЗ по тому же самому адресу/индексу. На скриншоте это видно. Я пробовал Москву, города Подмосковья. Без разницы.

Как заставить появиться список ПВЗ для самовывоза? Как видите, у меня его нет. В настройках возможности выбирать/настраивать ПВЗ не вижу. Где эти настройки могут быть?

Возьмем для примера СДЭК. Как получить список возможных ПВЗ и постаматов? Это возможно? Можно выбрать "самовывоз". Но откуда именно? Можно показать на примере СДЭК как включить отображение ПВЗ? Если использовать отдельный модуль СДЭК, то в нем есть возможность выбора ПВЗ и постаматов с несколькими вариантами.

ни на что не намекаю, но забавен выбор языков на головном сайте разработчика. Китайский и эстонский есть, но где же русский? Только мова, однако... Да еще лицензия привязывается к зарубежному серверу. Тут несколько раз стоит подумать если вы собрались получить такую лицензию (а без нее не работает панель) для своего сервера в РФ. В целом все минимально необходимое в этой панели есть, и она казалась вполне достаточной и достойной. Но первое, что меня немного напрягло в свое время - это лицензия с привязкой, хоть и было это давно в относительно спокойные времена. На мой взгляд, любая подобная привязка снижает надежность. А в последнее время часть серверов блокируют доступ с российским IP.

да и не нужна эта связка по большому счету. Это очень архаичная связка, идущая из древних и сложных времен. чистый Nginx работает отлично, если речь про опенкарт. Там всего лишь несколько правил прописать нужно. И даже если вам не хочется и этого делать, то для такого случая есть веб-сервер Litespeed, который хорошо дружит с aapanel. А для не очень нагруженных проектов обычный Апачи тоже годится весьма неплохо. Не забывайте, что в независимости от того, какой веб-сервер вы выбрали в aapanel, у вас php работает в самом быстром режиме: php-fpm. Это существенно шустрее, чем php в режиме модуля Апачи (а именно это чаще всего используют в связке Nginx+Апачи).

а зачем каждый раз растягивать? и какая в этом сложность? т.е. штатный лучше? в нем ничего растягивать не нужно и, насколько помню, нельзя. В принципе можно даже сделать запоминание размера открытого окна менеджера. Но никогда не думал, что это настолько принципиально. Открою секрет, что в настройках можно задать сразу ваш любимый размер. В общем, это такие несущественные мелочи. Кстати, я делал добавление изображений (основного, дополнительных) для товара пакетным способом. Не только загрузка изображений пакетным способом, а именно добавление картинок к товару одним нажатием "enter" (предварительно пометив нужные картинки как это принято для файлов, например, в windows). Для 3-ки это у меня есть. Правда, в дистрибутив так и не добавил, ибо совпало мое новшество с закрытием типа "международного" форума. Кстати, в отличие от алогичных разработок я сделал работу модуля в изолированной среде JavScript/jQuery, чтобы владелец сайта мог использовать какие угодно версии jQuery, например, и они бы не пересекались. Не замечал нигде в других разработках уделения внимания подобному аспекту. Рекомендую разработчикам по возможности минимизировать возможные конфликты таким способом (путем изоляции), хоть сама разработка при этом будет несколько сложнее. работает пакетная вставка так:

я в этом не разбирался. Я twig использую по навязанной необходимости, но для меня он - это как костыль для здорового человека. Ходить мешает, бегать не дает, а отказаться нельзя. Просто говоря, открываю документацию по twig, и если в ней указана какая-то стандартная возможность, то она должна работать по моему мнению, раз это заявлено стандартом twig. Все прочие нестыковки вызывают недоумение. пусть это будет так. Опять же непонятно почему не передали все, что нужно для полноценной работы? Зачем тогда нужен этот хромой и убогий недо-twig? Получается, что по мнению родителя опенкарт создание тысячи и одного одинакового кода - это то, к чему должен стремиться программист? Привет, миллион исправлений и миллион, соответственно, ошибок, т.е. в одном месте исправил, в другом - забыл, в третьем допустил ошибку при исправлении. Собственно, сам опенкарт и построен по принципу миллиона дублей кода, что жутко раздражает, ибо это генератор бестолковой работы и генератор ошибок. Поражает, что родитель опенкарта не умеет пользоваться как программист include? Бог с ним, делает как умеет, но зачем же так над программистами издеваться то? Вроде бы создали (пытались изначально) правильную идеологию модель-контроллер-вид, но лишили программиста основополагающей возможности повторного использования кода (нет include)? Как с этим дела в клубной сборке? Все в порядке, насколько я понял?