Анатолий Кирсанов (Все сообщения пользователя)

Будем 9 месяцев ждать?

Искать пути для создания номеров сайтов, зависящих от сайта. Такая возможность со стороны Битрикс есть. Посмотрите в настройках модуля Интернет-магазин. Не уверен потребуется ли программирование, но сделать это точно можно.

Большое человеческое спасибо. Я знаю какие круги ада для этого нужно пройти.

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

Есть вероятность, что обсуждаемый продукт помрет.

Обращался в поддержку с вопросом какое решение сейчас принято по поводу северной ОС на замену CentOS (2712486 "Выбор серверной ОС на замену CentOS"). А ответа то и нет ("К сожалению, планы отдел разработки нам никогда не сообщают, поэтому о решении о замене ОС информация отсутствует.").

В таких условиях мог бы подойти любой российский дистрибутив (например, "Альт Сервер" или, если хочется халявы, то серверный Starter Kit на той же пакетной базе). Вопросы по происхождению ПО все равно, рано или поздно, будут. Самое время переключиться. Вот только для полной картины не хватает поддержки PostgresQL со стороны БУС.

Ну а если нужна панель управления (Plesk, ISPManager), то вариантов два - Debian, Ubuntu. Rocky Linux наверняка не станет полноценной заменой в обозримом будущем.

Признаться, начал сомневаться в пригодности CentOS Stream для рабочих проектов.

"Однако в этом случае разработчики не могут (и не станут) гарантировать полную стабильность работы ОС, поскольку апдейты не проходят многочисленные фазы тестирования."
Из статьи "Red Hat пустила под откос Linux-дистрибутив CentOS. Пользователи в ярости".

По-хорошему, конторе стоит определиться и довести до разработчиков по выбору дистрибутива на замену.

Это другая история. Происходит отказ от CentOS 8 в пользу CentOS Stream.

Есть здесь нехороший нюанс - "После прекращения поддержки CentOS в конце 2021 и переход к поддержке только CentOS Stream, все неплатящие пользователи автоматически перейдут в категорию «вечных бета-тестеров», на которых компания будет обкатывать обновления для своего коммерческого продукта RHEL.". Но там же сказано, что CentOS являлась по отношению к RHEL тестовой платформой. Так что мало что изменится. Будет кому-то надо номерная стабильная версия - будет какой-то еще дистрибутив (вроде как есть Oracle). Фактически, народ интересует не CentOS, а RHEL бесплатно. И это все равно будет.

Для абсолютного большинства достаточно ее новизны. А это влияет на срок поддержки. 30 ноября, к примеру, приказала долго жить CentOS 6. Можно перейти на семерку, но только на 3,5 года. И потом снова непростой апгрейд. Лучше оттянуть этот прекрасный момент. Еще лет на 5.

Эта тема именно об этом. А Вы занимаетесь троллингом и оффтопом.

Особенно здесь. Вопрос здесь к конторе. Это не обсуждение возможностей партнеров.

Впрочем, контора может телиться еще 4 года (год уже прошел). Судя по What is the support ''end of life'' for each CentOS release?

Да это был тролль.

Вероятно. По сообщениям ТП готового решения для перехода нет, в Марокетплейс - тоже. Изобретать свое - не понятен заказчик. Делать за свой счет - никакого желания.

Оказалось, что есть статья от начальника службы поддержки.

Всегда интересовало зачем вы старые версии удаляете. Они что, так много места занимают, что нужно вынуждать делать изменения под них?

Вы, наверное, хотели спросить Дмитрия Шпака, а спросили меня.

Для себя решил, что не выйдет из этой затеи ничего и вернулся на CentOS 7 и панель управления. Сама панель не имеет значения (мне нравится другая, но остался на той, что поддерживает хостер). Нет сейчас и не будет до весны (наверняка) нормальной поддержки восьмерки нигде. Т.е. если время не терпит и проект рабочий, а не учебный, то сильно не советую ставить эксперименты. Для этого есть другие люди.

BitrixEnv я рассматривал как альтернативу штатным инструментам администрирования RHEL/CentOS. Для односерверной (не кластерной) конфигурации окружение Битрикс проигрывает любой панели управления. Правда, я по памяти версии 5.0.38 (которая съела у меня все мозги и я остался крайне недоволен).

Получилось?

Как это ни странно, заявки в разработку не было. Она создана только вчера, по моему обращению в поддержку (119509 "реализовать поддержку centos8").

С тем что документы реализации выгружать надо (иначе сайт считает, что их нет вовсе), с тем, что соответствия настраивать тоже надо никто не спорит. Видимо, некорректно сформулировал текст.

Претензия к тому, что требуется использовать два поля в дополнительных сведениях вместо данных, уже имеющихся в стандартном модуле "Склад/.Управление доставкой".

Были в конфигурации уже документы. И их море. И теперь возникла надобность в обмене заказами в обе стороны. А привязка то к службе доставки сайта не сохраняется. Поля в дополнительных сведениях не заполнены. А зачем их заполнять, если они уже есть в базе в стандартном месте?!

Почему вообще используются соответствия доставки в современной УТ (11-ой) если в ней есть подсистема "Управление доставкой" в подсистеме "Склад"?
Программист 1С крайне недоволен из-за того, что решение для 10-й УТ притянуто за уши в 11-ю. Приходится использовать не штатный функционал 1С, а нечто сбоку, работающее с дополнительными сведениями документа ("Способ доставки" и "Метод доставки ИД").


Программиста 1С я прекрасно понимаю. Сам также недоволен, когда, используя Битрикс, приходится писать что-то сбоку. Почему вообще это нужно делать в 1С то?

Это приведет к тому, что пользователь будет видеть структуру файлов и папок в админке. Этого можно избежать?

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

Если ранее к странице (не области) давался доступ на запись ради кнопки SEO, то после включения доступа к управлению структурой пользователь получает неоправданно большие права (может и тело страницы менять).

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

Нет, все в порядке. Я собирал данные для программиста 1С. Поскольку на мне Битрикс, данные собирал в коде Битрикс.

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

Судя по коду Битрикс, эти теги в заказе имеют смысл при отсутствии в контейнере документа отгрузки. Тогда срабатывает поиск значения по-умолчанию.

Вот так должно быть в документе отгрузки?

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

Спасибо. У меня это решение сработало.

Для ясности, сервер управляется ISPManager, использую 7.1.3 (Apache FastCGI). main версии 17.0.6.
CentOS 7 (systemd). Лимиты для httpd установлены в /etc/systemd/system/httpd.service.d/limits.conf :На PHP 5.6.30 (тоже "альтернативная", установлена панелью) достаточно было настроить  лимиты для сервиса systemd и все. А теперь требуется магия с отключением pcre.jit. Почему приходится отключать "PCRE just-in-time компиляцию"?

JIT отключал в глобальном конфиге PHP (php.ini для этой версии PHP). В ISPManager это делается легко.

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

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

Файлы картинок при потере и "восстановлении" не выгружаются. Только теги Картинка.

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

Со стороны если наблюдать, то после завершения обмена картинка анонса и детальная картинка теряются. Потом, через некоторое время восстанавливаются. Я привязываю факт восстановления к обмену, но не уверен в этом. От обмена акт восстановления может не зависеть (просто протоколов навешал именно на обмен).

При отладке выясняется следующее.

Если файла картинки нет, то Битрикс ищет картинку среди уже привязанных к элементу по EXTERNAL_ID. Эти внешние коды вычисляются элементарно (md5 по содержимому тега Картинка). Факт поиск картинки по внешнему коду и список привязанных к элементу картинок я вижу. Я также вижу, что картинка находится (да, для отладки я влез в CheckFileByName).

Это значит, что она должна быть пересоздана (с получением нового ИД в таблице b_file).

И да, она пересоздается. Но с задержкой в несколько секунд от момента поиска. А привязка файла картинки к элементу инфоблока происходит с чудовищной задержкой в 50 минут. Естественно, со стороны кажется, что картинка пропала, а потом появилась ниоткуда.

Что я уже проверил

Битрикс виновен только в том, что в коде обмена (проверил исходники вплоть до версии iblock 16.5.2 не используют транзакции). Судя по логу (описал выше) картинки находятся, пересоздаются, привязываются.

Задержку пытаюсь объяснить поведением MySQL 5.1.73 на CentOS 6.8 (не MariaDB).
Таблицы InnoDB (файлы и элементы инфоблока).

Ошибок в логе MySQL нет. В логе медленных запросов update на привязку файла к элементу не найден (искать легко - по ИД файла).
Тестирование конфигурации Битрикс пройдено без единой ошибки (предупреждений тоже нет).
Монитор производительности СУБД жалуется только на кеш открытых таблиц (12.81% при table_open_cache = 8192; статистика за 22 дня).
Статуса 500 на скрипте обмена в момент «потери» и «самовосстановления» картинок не было (да и вообще они крайне редки - это Premature end of script header; в описанной ситуации между потерей и восстановлением этой болячки не было).

Что это может быть и что делать?

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

Может конечно такое быть, что после получения товаров и до анализа картинок время проходит, не приходилось такое наблюдать.

Кто так решил? Да я уже написал. Любой разработчик и он прав.

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