Александр Цымбал

написать свой delete, с блэкджеком и куртизанками

если посмотреть исходники в плане удаления свойств, то там что-то странное происходит, select, update зачем-то
bxapi.ru/src/?module_id=iblock&name=CIBlockElement...

по сути это просто записи в куче разных таблиц, судя по исходникам, удаляется не только элемент, но и его вариации, если используется документооборот

ну и ручками
DELETE FROM и куча таких таблиц

проблема только в том, что не сработают события, и останутся файлы в /upload

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

Скрипт уже закончил работу?
Я так понимаю, Вы запустили скрипт, а потом написали вопрос.

Оптимизировать можно следующим образом:
- в метод GetList добавить массив с полями выборки array("ID"), чтобы не тянуть из базы значения, которые не нужны
- выполнять метод Delete прямо в теле цикла while, чтобы не собирать без надобности массив

Если все еще не хватает времени на выполнение, написать простенькую клиентскую часть с AJAX-запросом. Будет работать медленно, но гарантировано выполнит задачу и не уйдет в таймаут.

Но судЯ по коду, вы собрали массив разделов и потом удаляете элементы с этими id.

Один из вариантов - выключить индексирование инфоблока модулем поиска

При большом количестве разделов (30к+), Bitrix начинает вставлять палки в колеса как разработчику, так и пользователю, который будет работать с такими ИБ.
- Списки элементов ИБ будут безбожно тормозить в интерфейсе. На каждом хите будет добавляться фильтр по разделу.
- Редактировать их становится очень затруднительно, опять же из за долгой загрузки интерфейса и большого времени изменения.

Всё это из за того что разделы это NESTED SETS деревья. При добавлении/удалении раздела происходит вычисление LEFT_MARGIN и RIGHT_MARGIN для каждого раздела во всем инфоблоке.

Для добавления и обновления (CIBlockSection::Add, CIBlockSection::Update) есть параметр метода $bResort, который позволяет отключить этот перерасчёт в момент их выполнения.
Только после этого ОБЯЗАТЕЛЬНО надо выполнять CIBlockSection::Resort.

Это можно использовать при большом количестве операций Update и Add. Сначала выполняете все операции Update и Add с $bResort=false, а после них CIBlockSection::Resort

НО!! К сожалению, такой параметр для CIBlockSection::Delete не доступен. И вот тут начинается жесть.
Каждый вызов CIBlockSection::Delete, это:

• пересчет границ NESTED SETS,
  
• CIblockElement::GetList (поиск вложенных элементов)
  
• CIblockElement::Delete (если в разделе были элементы),
  
• Запрос к таблице которая хранит множественные привязки элемента к разделам (поиск значений и их удаление)
  
• CIBlockSection::GetList (поиск вложенных разделов)
  
• CIBlockSection::Delete (удаление вложенных разделов)
  
• Переиндексирование поиска
  
• Запросы к UF_* полям раздела (поиск значений и их удаление)
  
• При заполненных SEO полях, запросы к таблицам которые их хранят (поиск значений и их удаление)
  
• При расширенном управлении правами это еще запросы к таблицам которые хранят эти настройки (поиск значений и их удаление)
  

и это скорее всего не полный список, а только то что могу назвать по памяти....

Нельзя быстро удалить разделы стандартным API без написания своих запросов к БД которые проделают всё что описано выше. В идеале надо взять код стандартного CIBlockSection::Delete, внимательно его изучить и написать свой метод который будет с помощью прямых запросов делать тоже самое, но оптимально.

Если же вопрос стоит в том чтобы удалить эти разделы за ЛЮБОЕ количество времени, тогда можно написать страничку с пошаговым удалением разделов, через ajax запросы. Причем надо учитывать, что вначале разделы будут удаляться ОЧЕНЬ медленно и ajax запрос может отвалиться по таймауту, поэтому надо будет за один шаг удалять пару разделов. А ближе к границе в 10к разделов, за один шаг можно будет удалять уже большее количество.

https://accounts.google.com/SignUp

страница регистрации Google (последнее поле)
и доступно во большинстве языков)))

Я создал новый поддомен, изначально сделал его без HTTPS.
На следующий день в меню ISP Manager Настройка -> Адреса панели добавил дополнительный адрес, там же создал для него новый сертификат с помощью Let's Encrypt.
Прикол состоит в том, что данный сертификат потом не отображается в списке сертификатов в панели.
Руками нечего не делаю, все само обновляется.

Нету у него названия, есть слайдеры и есть опции у них для кастомизации
https://swiperjs.com/demos/ - Fraction Pagination

Прям с такой кастомизацией вряд ли найдете, slick или owl - хорошие слайдеры, можно их наворачивать как хотите

1 - сверить url, если там хоть на один символ отличие, поведение браузера вполне логично
2 - если вы абсолютно уверенны что нашли баг, вам сюда https://www.chromium.org/for-testers/bug-reporting...

Можно считать по гугль картам

$from = "Санкт-Петергубг Ленина 5";
$to = "Выборг Ленина 20";

$from = urlencode($from);
$to = urlencode($to);

$data = file_get_contents("http://maps.googleapis.com/maps/api/distancematrix/json?origins=$from&destinations=$to&language=ru-RU&sensor=false");

$data = json_decode($data);
echo "Откуда: ".$data->destination_addresses[0] . "<br/>" .
     "Куда: ". $data->origin_addresses[0] . "<br/>" .
     "Время: ". $data->rows[0]->elements[0]->distance->text . "<br/>" .
     "Путь: ".$data->rows[0]->elements[0]->duration->text;

перенаправь домен на эту папку и не надо ничего вытаскивать)

Не уверен, но попробуйте так:

#Блокируем ботов через .htaccess
RewriteEngine On
RewriteCond %{QUERY_STRING} register= [NC]
RewriteRule ^.*$ - [R=404,L]