Быстро с 1с битрикс убрать кнопку
Добрый вечер, на летней конференции был задан вопрос партнерам, по поводу кнопки "Быстро с 1С-Битрикс", сложно ли им продавать сайты с этой кнопкой? Стоит ли убрать этот порог в 300 тысяч рублей?
Очень большая часть зала выразила единодушное мнение, что надо дать возможность убирать кнопку бесплатно, либо за цену куда более низкую. Я был в том числе кто тоже поддержал это единодушное мнение. Сергей Рыжиков сказал, что подумает еще на счет этого, ему явно не очень нравится такой настрой партнеров.
Я размышлял над этим после конференции, изменив в итоге точку зрения по этому вопросу. Технология "композитный сайт", которую сделал Битрикс, реально ускоряет сайт, это будет видеть пользователь, но это не главное.
Главное что это будут видеть владельцы бизнесов которые хотят себе сделать сайт, сейчас как они выбирают систему?
В основном потому что им ее предложил компания разработчик, либо друг посоветовал, либо где то слышал, но он не узнает о Битриксе когда просто серфит по интернету.
С данной кнопкой появится еще один хороший канал привлечения клиентов, "Битрикс будет на слуху", бренд "Битрикс" станет более популярным, люди переходят по ссылкам с подвала это факт.
Мы как партнеры, от кнопки "Быстро с 1С-Битрикс" только выиграем, у нас будет больше желающих работать с нами, так как мы партнеры "Битрикс", ведь сайты на нем летают.
Что же нам мешает? Мое мнение, что это СТРАХ.
На конференциях 1С-Битрикс я вижу яркую тенденцию обращений к партнерам "Повышайте свои цены", Сергей Рыжиков это лично продвигает.
Он не боится того что если мы будем "брать больше", люди просто перестанут использовать 1С-Битрикс. Он знает, что у клиентов просто нет выбора по сути, 1С-Битрикс это лидер в сегменте e-commerce, все остальные курят в сторонке.
Мы тут диктуем цены, если мы все будем "стоить дороже" у клиента не будет выбора, для этого надо забыть про "демпинг", что же мешает, опять СТРАХ.
Я лично призываю быть нормальными партнерами, кнопка "Быстро с 1С-Битрикс" нам нужна. Нужно только убрать сомнения и страхи, учится ее ставить клиентам, по итогу мы отхватим еще больший кусок с рынка веб-разработки.
Конечно надо еще повышать свои цены, но это уже отдельный разговор
Добрый день!
Подскажите пожалуйста как массово и достаточно быстро удалить все разделы в инфоблоке?
Всего разделов 55к
Через админку всё виснет, несмотря на больше max execution time.
Скрипт такой набросал, но как-то долговато работает.. Или это норма?
можно попробовать отключить пересчет дерева или прямо из базы грохнутьСкрипт уже закончил работу?
Я так понимаю, Вы запустили скрипт, а потом написали вопрос.
Оптимизировать можно следующим образом:
- в метод GetList добавить массив с полями выборки array("ID"), чтобы не тянуть из базы значения, которые не нужны
- выполнять метод Delete прямо в теле цикла while, чтобы не собирать без надобности массив
Если все еще не хватает времени на выполнение, написать простенькую клиентскую часть с AJAX-запросом. Будет работать медленно, но гарантировано выполнит задачу и не уйдет в таймаут.
При большом количестве разделов (30к+), Bitrix начинает вставлять палки в колеса как разработчику, так и пользователю, который будет работать с такими ИБ.
- Списки элементов ИБ будут безбожно тормозить в интерфейсе. На каждом хите будет добавляться фильтр по разделу.
- Редактировать их становится очень затруднительно, опять же из за долгой загрузки интерфейса и большого времени изменения.
Всё это из за того что разделы это NESTED SETS деревья. При добавлении/удалении раздела происходит вычисление LEFT_MARGIN и RIGHT_MARGIN для каждого раздела во всем инфоблоке.
Для добавления и обновления (CIBlockSection::Add, CIBlockSection::Update) есть параметр метода $bResort, который позволяет отключить этот перерасчёт в момент их выполнения.
Только после этого ОБЯЗАТЕЛЬНО надо выполнять CIBlockSection::Resort.
Это можно использовать при большом количестве операций Update и Add. Сначала выполняете все операции Update и Add с $bResort=false, а после них CIBlockSection::Resort
- пересчет границ NESTED SETS,
- CIblockElement::GetList (поиск вложенных элементов)
- CIblockElement::Delete (если в разделе были элементы),
- Запрос к таблице которая хранит множественные привязки элемента к разделам (поиск значений и их удаление)
- CIBlockSection::GetList (поиск вложенных разделов)
- CIBlockSection::Delete (удаление вложенных разделов)
- Переиндексирование поиска
- Запросы к UF_* полям раздела (поиск значений и их удаление)
- При заполненных SEO полях, запросы к таблицам которые их хранят (поиск значений и их удаление)
- При расширенном управлении правами это еще запросы к таблицам которые хранят эти настройки (поиск значений и их удаление)
и это скорее всего не полный список, а только то что могу назвать по памяти.
Нельзя быстро удалить разделы стандартным API без написания своих запросов к БД которые проделают всё что описано выше. В идеале надо взять код стандартного CIBlockSection::Delete, внимательно его изучить и написать свой метод который будет с помощью прямых запросов делать тоже самое, но оптимально.
Если же вопрос стоит в том чтобы удалить эти разделы за ЛЮБОЕ количество времени, тогда можно написать страничку с пошаговым удалением разделов, через ajax запросы. Причем надо учитывать, что вначале разделы будут удаляться ОЧЕНЬ медленно и ajax запрос может отвалиться по таймауту, поэтому надо будет за один шаг удалять пару разделов. А ближе к границе в 10к разделов, за один шаг можно будет удалять уже большее количество.
Читайте также: