Я говорю о PHP функции sleep, которая останавливает работу скрипта на указанное время, и, насколько я понимаю (я могу ошибаться), предотвращает наступление max_execution_time.
По крайней мере я пользовался примером Николая-философа и это помогало делать пошаговую разбивку чтения больших данных.
Как по мне — я вижу на экране не наследование, а большой объект с копией всех свойств.
Я кстати и не спорю — а скорее сам разобраться пытаюсь.
К примеру в свойства узла добавлены всяческие onclick, onmouseover и десятки других возможных событий. И не важно используешь ты их или нет.
Распечатать обычный JS узел кстати не удастся, потому что отдельный его экземпляр не создается в принципе. Тебе будет выдана ссылка на DOM-element, без хранения его в памяти.
А чтобы добавить событие в JS узел — нужно писать addEventListener.
Буквально на днях установил человеку скрипт на чистом JS. А он мне жалуется что не работает.
Я ему говорю может кэш браузера, попробуй другой, попробуй почисти, а он мне начинает рассказывать что на трех компьютерах попробовал и везде не работает. И через час мы все таки выяснили, что у него на всех трех компах XP стоит, на который даже хром давно не обновляется. Ну и классика жанра — IE.
Давайте немного структурируем информацию и разберемся, почему и зачем сейчас все отказывются от jQuery.
Что это? Дань моде? Да здравствует Ванильный JS?
Да вот нет. Причин на самом деле две. Одну из них выше упомянули. Использование в компоненте jQuery — это лишняя зависимость для проекта в целом.. Да скорее всего он и так подключен. Тот же miniShop2 до сих пор требует jQuery. Кстати совсем немного. Скрипты минишопа написаны на чистом стареньком JS пятой версии. Но в нескольких местах пока еще используется jQuery. При желании можно переписать и отказаться от зависимости.
Вторая причина, которой я здесь в обсуждении не увидел это дополнительная нагрузка на память. Дело в том, что jQuery сильно нагружает используемые DOM-элементы собственными свойствами и методами. Грубо говоря, добавляя под сотню (не считал) свойств в каждый используемый элемент. И это все висит в памяти, чтобы браузер в любой момент мог использовать все дополнительные методы каждого элемента.
Современный веб — он же про оптимизацию и быстродействие верно? Так что приходится избавляться.
Давайте также до кучи разберем почему вообще jQuery получил такую популярность исторически.
Причин собственно так же две. Начну с конца.
Во-первых, jQuery дал возможность использовать короткие вызовы для различных популярных действий. И это частично по прежнему актуально. Те же методы show(), hide(), classToggle() и тому подобное все еще короче, чем то же самое на чистом JS. Но напоминаю эти методы и еще куча других нагружают узлы DOM дерева, независимо от того пользуетесь ли вы ими.
Во-вторых кроссбраузерность. Раньше у каждого браузера были свои собственные движки JS, которые по разному реализовали те или иные возможности. Либо вообще не реализовали. Jquery давал возможность не задумываться для какого из браузеров пишется код. Магия внутри преобразовывала все как надо. все изменилось с приходом на рынок Chrome и его движка для рендера JS V8. Он получился насколько качественным, что его стали использовать и другие браузеры, и даже портировали в NODE JS. и даже те браузеры которые не стали его использовать — все равно волей неволей стали подстраиваться под лидера рынка. Таким образом от проблем кроссбраузерности мы практически избавились и для решения этой проблемы jQuery стал не нужен.
Ну и не нужно забывать что движок JS и сам упрощается. Все ранее недоступные или сложные возможности становятся все проще и доступнее.
Надеюсь такой мини-ликбез будет кому то полезен. Спасибо.
Пиши условие, проверяй у него content_type или как там, не помню сейчас на лету.
Посмотрим — может получится реализовать вариант OpenAPI. Но вообще вряд ли.
Проще подготовить собственную надстройку к MODX, по-моему.
Фильтр по родителю вот такой
Во вторых в параметрах вызова pdoMenu нужно указывать права для проверки доступа. Например &checkPermissions=`list`.
По крайней мере я пользовался примером Николая-философа и это помогало делать пошаговую разбивку чтения больших данных.
Я где то видел сторонние сервисы для получения данных от Яндекс API, которые работают как прослойка, промежуточный сервер. Что то вроде покупки вскладчину. Я бы в эту сторону смотрел и приспосабливался.
Как то странно, что вы перешли на MODX не изучив для себя вопрос — а выйдет ли задумка. Уж тем более странно покупать дополнение, в котором нет нужных вам возможностей. Что мешало предварительно спросить?
Могу написать для вас нужный функционал отдельно, за деньги. Все мои контакты в профиле.
Для разрешения спорных вопросов Вы можете обратиться к администрации магазина, я к ней не отношусь.
У LiqPay (самого банка) нет настроек для возврата в случае ошибки. Поэтому всегда срабатывает редирект только на один единый адрес. По крайней мере я таких настроек не видел. Если я ошибаюсь — можете ткнуть пальцем.
Что касается языков и контекстов — что вы имеете ввиду? Сам платежный модуль с языком вообще не работает. Только с валютой. Пользователю модуль ничего не выводит, все что видит пользователь, и то что можно переводить — это уже miniShop2.
Ваша задача наверняка решаема, но не в формате вопроса-ответа.