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

Не путайте удаление товара и раздела. Они несколько  по разному хранятся. и я не просто сказал воспользоваться SQL. aтак что вариант рабочий, но требует квалификации.. На самом деле там не запредельно много надо учесть. Единственное - это действительно вариант "на крайний случай". Я его проверял (в результате работы горе программиста было нагенерировано намного больше разделов чем у ТС)... Пока пошаговый скрипт копошился, я подготовил и такой вариант... Правда в бою не пригодился

100K вложенных разделов (без товаров), вам вряд ли удастся за 20 сек грохнуть. Впрочем даже добавить 100001 - задача не для слабого хостинга

Правда, я уже не  помню, что за железо было у того клиента.

Эта проверка у вас внутри кешируемой области?
Если да- добавьте в параметры компонента дополнительный типа

Почему? Не по "феншую" да.... Но вполне рабочий вариант. И если мощности сервера не позволяют штатными средствами, возможно, единственный...

Удаление раздела это "тяжелая" операция. Для хранения используется метод Nested Sets. Т.е. надо иметь ввиду, что при удалении одной записи обновляются все остальные, т.е. если есть 2000 разделов, один общий корневой раздел и удаляется 1, то обновляются 1999 записей... И так у вас 2000+ раз. При этом срабатывает механизм событий (например, если включен теггированый кеш, дается команда на очистку, проверка нет ли элементов в этом разделе) и т.д и т.п.

Мне приходилось чистить подобный каталог: писал скрипт который удалял разделы порциями (чтобы распределить нагрузку).... Так же если есть возможность и понимание происходящего можно отключить некоторые обработчики событий (свои и некоторых модулей). Либо еще более суровый вариант: напрямую SQL запросами, но тут прежде надо очень четко разобраться в структуре и взаимосвязях.

Зайдите на страницу админки /bitrix/admin/checklist.php  нажать "тестировать". В последней группе тестов есть пункт "Измения ядра". Перезапустите его...

Но лучше делать обновление сначала на резервной копии. Возможно какие то скрипты вашего проекта "несовместимы" с PHP7,

Так может у вас много не оптимизированных больших запросов сжирающих буфер?

Букварь по PHP: count  

К тому же, обратите внимание, битрикс с нового года будет поддерживать PHP начиная с версии 5.6. Т.е., если ни чего не менять, он у вас после новго года не будет обновляться.

ну тогда, скорее всего, только смена хостинга.

А хостинг какой? Если виртуальный, может отключил это расширение или, точнее, изменил версию php (переключил на версию собранную без его поддержки). Оно необходимо  У вас в панели управления есть возможность выбора версии PHP? Какая сейчас и какие доступны?

Вообще я когда то занимался чисто версткой дизайнеры любили уже "потом" сделать "а вот теперь мы здесь добавим...." и тоже возникали такие ситуации как у вас. Я просто подробно комментировал и html и css - где и что менять. Если выползали косяки после интеграции - найти проблему и дать инструкцию по исправлению было моей задачей

Очень смелый поступок .  А если серьезно зависит от его способностей

Мне видится такие варианты:
1. Таки да. Научить и пускать на копию сайта для разработки. При этом использовать git для контроля и возможности откатов.
2. Если вы "разложили" его файл стилей по разным компонентам. Верните ему шаблон с разделенными и подключенными файлами, пусть работает с ними
3. Модификация второго: пусть работает с препроцессорами sass, less.... и так же с набором файлов а не с одним. А из них уже собирать нужные css

А зачем? в вопросе же " результаты его работы необходимо отдавать в JavaScript". Сразу отдать в JS и все. Иначе придется тащить в кеш дополнительные данные.

Впрочем, смысла сейчас обсуждать нет, полагаю Дмитрий решил свою задачу еще два года назад

Два года с последнего сообщения
Чтоб ваш совет работал надо отключать кеширование, а это плохо.Так делать нельзя на рабочем проекте.

По последнему сообщению от15 года. Там просто в шаблоне сформировать JS объект.

Ну так не работайте с Битрикс... В чем проблема то? Я большую часть карьеры (20 лет) проработал на Pascal и С++. Меня вообще от языков PHP  и JavaScript "колбасит". И что?

Не стоит следовать буквально распространеным стилям оформления кода. Это лишь рекомендации по приведению кода к некоему общепринятому стандарту. Чтобы в рамках одного проекта было меньше "кто в лес, кто по дрова". По большому счету нет особых проблем при восприятии detailText или DETAIL_TEXT.  Самое главное во всех этих стилях кода это что стиль был един в рамках проекта и/или проектов объединенных неким общим инструментом.
И рассуждение "моветон" это или нет это по сути пустой холивар. При обеих формах записи слова не сливаются, все четко и понятно. Просто лично вы привыкли к другому стилю. И все. Еси планируете долго работать с Битрикс привыкайте, если не долго - не парьтесь. Если хотите работать с разными инструментами и командами учитесь спокойно вливаться в стиль конкретного проекта.

Поймите это не "моветон". Это дело вкуса. Точно так же можно было  поспорить про отступы: пробелы vs табуляция. PSR рекомендует пробелы, я их "терпеть ненавижу". И во многих командах требование "PSR, но табуляция".

Жесть какая......

А работа через АПИ не в моде?
Тыц
Переменная DB
ORM
Ну и
Не давно попался такой проект в работу: подключение к БД в 100500 местах и везде прописаны логины/пароли."По убивал бы".

Не решал. Но.
Для работы с этими значениями есть
Bitrix\Iblock\InheritedProperty\ElementTemplates::set();
Bitrix\Iblock\InheritedProperty\SectionTemplates::set();
Bitrix\Iblock\InheritedProperty\IblockTemplates::set();

Сколько товаров?
Какая посещаемость?
Агенты на хитах или кроне?
Кеширование включено?
Кеширование мемкеш, файлы или ...?

А PHP какой?

что показывает на этой же странице на вкладке Битрикс?
На  странице /bitrix/admin/perfmon_db_server.php?lang=ru  есть красные показатели?
скриншоты /bitrix/admin/perfmon_php.php?lang=ru  покажите
попробуйте там же развернуть второй сайт на демо установке Битрикс с  демомагазином и посмотреть там показатели.

Основные страницы посмотрите с включеной отладкой (кнопка на верхней панели админа). И сравните количество запросов с кешем и сразу после сброса кеша.

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

вы не правильно расцениваете мои слова. Поймите ЛЮБОЕ программное обеспечение может содержать баги, иные проявляются только при стечении 100500 факторов. Все проверили, выпустили обновления, у одного из миллиона пользователей они сложились.  Такое бывает. Даже у Микрософт (если не ошибаюсь в прошлом году одно обновление вызвало у многих серьезные проблемы - деталей не помню, т.к. сам виндус не пользуюсь, но в новости и шумиху помню.).   Т.е. при обновлении при самом идеальном поставщике нужно иметь резервную копию. Т.е. обновились нашли баг, откатились, пишите в службу поддержки.
Вот реально бывает даже: офис два десятка компьютеров купленных на заводе из одной партии. ОБновляешь. Один уходит в аут. Т.е. надейтесь на других, но и сами не плошайте.

Клиент сам виноват в потере работоспособности инструмента своего бизнеса.

От ситуации. Возможно у вас стоит какой-то самописный обработчик, который эксплуатировал "недоработку" в обмене.

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

Но и вы написали тут пост "крик души". Вместо поиска решения своей проблемы.

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

Вы экономите на специалисте обновляя сайт самостоятельно, следовательно должны иметь в своем багаже необходимые знания. Либо читайте/изучайте как поступать правильно, либо учитесь на собственных ошибках. Увы иначе ни как. Битрикс (как и любая другая CMS) это не система, в которой может все функции выполнять бездумно любая домохохзяйка. Вы ж не контент правили и у вас, что то отвалилось. Вы выполняли функции системного администратора.

Есть фраза "Если Вы считаете, что компетентность стоит дорого, то попробуйте некомпетентность — она обойдётся вам гораздо дороже". Она реальна и отражает действительность. Нет возможности/желания оплачивать услуги специалиста: изучайте "как правильно делать" самостоятельно.

Нет. Навязывания тут нет абсолютно. У вас же есть выбор:
1. Не обновляйте Битрикс
2. Дорабатывайте модуль 1с своими силами
3. Скопируйте компоненты обмена в Битрикс (той версии что подходит к вашей 1с) в свое пространство имен и используйте их. При необходимости дорабатывайте
4. Продлевайте и обновляйте и то и другое

Сами посудите. Кто то имеет 1С 7.7, кто то не обновляет Битрикс, кто-то не обновляет 1с... В итоге сочетаний версий может быть море. Предлагаете вечно поддерживать все и вся? Или тащить ворох атавизмов в текущих версиях. Что бы у всех кто постоянно обновляет оба продукта, были  лишние тормоза, ради одного клиента битрикс, который не хочет прощаться с бородатой 1с?

Увы. Такое не делают даже такие монстры как Микрософт.

Это  предсказуемо.  А вот для решения важны ответы и на остальные вопросы.

Цитата
Екатерина Медведева написал: cms-estate

Мой вам совет не учитесь на его коде. Общался с ним у него вообще подход "оригинальный" к разработке на Битрикс. Это путь к неоправданно тормозному сайту.