Если он есть, то да, по API

в этом должен быть какой-то смысл

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

добрый вечер подскажите, есть ли возможность, чтоб radical form слать ответное письмо оставившему заявку? Например "Ваша заявка получена получена, ожидайте звонок администратора"

Написать плагин, готового нет

Написать плагин, готового нет

Проще в почтовом ящике автоответ настроить, имхо

добрый вечер подскажите, есть ли возможность, чтоб radical form слать ответное письмо оставившему заявку? Например "Ваша заявка получена получена, ожидайте звонок администратора"

Есть. Есть плагин от Димы. Ща дам ссыль

https://github.com/fiction13/plg_radicalform_usermail

разве функция explode не должна возвращать нулевую строку если не находит разделитель что то практика с учебником не сходится

все понятно, если нет разделителя то влетает сама строка при положительном лимите

ребят есть SobiDisplayControllerPayment и метод pay есть SobiDisplayViewPayment как для метода pay правильно нужный шаблон? пока у меня открывается default.php

не пишите по кайфу никогда алиасы)

потом можно встрять)

добрый вечер подскажите, есть ли возможность, чтоб radical form слать ответное письмо оставившему заявку? Например "Ваша заявка получена получена, ожидайте звонок администратора"

Чтобы превратить свой сайт в рассылку бесплатного спама?

Я зайду, введу почту всех нелюбимых мною людей и буду нажимать кнопку «отправить»

😂

@Evgen_Web где-то выше писал про тормоза и меню. так это математика: каждый пункт меню умножить на кол-во меню и все это тянет параметры. итого просто не хватает оперативной памяти. тут дело не в CMS, а в архитектуре проекта. я знаю, что пишу,тк у нас был коммерческий и бесплатныц продукт JMB Tree. модуль меню, фишка которого - можно было из пунктов меню выбирать какие включать на отображение и, таким образом, конструировать кастомные менюхи внутри модуля без создания отдельных пунктов меню. вот это дело жутко тормозило при большом кол-ве меню. и все потому, что арифметика - просто не хватало памяти для обработки такого массива информации,. это проблема не джумлы, а а архитектуры сайта и самого расширения.

и тормоза были не не фронте, а в админке при открытии такого модуля

для фронта вообще по фигу, хоть миллион меню

Народ, у кого 10 минут есть - протестируйте у себя тоже. https://github.com/joomla/joomla-cms/issues/39360

Слетают параметры библиотеки из базы данных при обновлении библиотеки

@fictionlabs @drekun @tsymbalmitia @Septdir

@fictionlabs @drekun @tsymbalmitia @Septdir

я сегодня не смогу

Доброго времени суток! Подскажите, как решить задачку: Есть форма, а в ней: <input type="file" accept="image/*, .pdf" /> accept может быть и любым другим, но этот пример показателен. Как проверить расширение загружаемого файла на стороне сервера? Как получить файл, его расширение, его MIME - это все понятно. Но как написать функцию валидации? Ничего готового я не нашел. Может плохо искал? Предполагаю, что алгоритм такой: Найти все расширения для MIME image, далее собрать массив расширений и отдельно массив mime из accept, и потом проверять расширение и mime текущего файла по этим двум массивам. Но может можно как-то проще? Или есть готовый метод в Joomla?

Доброго времени суток! Подскажите, как решить задачку: Есть форма, а в ней: <input type="file" accept="image/*, .pdf" /> accept может быть и любым другим, но этот пример показателен. Как проверить расширение загружаемого файла на стороне сервера? Как получить файл, его расширение, его MIME - это все понятно. Но как написать функцию валидации? Ничего готового я не нашел. Может плохо искал? Предполагаю, что алгоритм такой: Найти все расширения для MIME image, далее собрать массив расширений и отдельно массив mime из accept, и потом проверять расширение и mime текущего файла по этим двум массивам. Но может можно как-то проще? Или есть готовый метод в Joomla?

есть в Input класс Files

там написаны валидаторы

по майм типу если честно бесполезно проверять

он формируется браузером или смотрится по контенту

по контенту тоже бесмысленно

потому что пару байтов добалвяешь нужных

и файл png превращается в php

Т.е. нет вообще смысла проверять файл на сервере?

https://github.com/joomla/joomla-cms/blob/4.2-dev/libraries/src/Filter/InputFilter.php#L185

Т.е. нет вообще смысла проверять файл на сервере?

нет

имеет смысл конечно

фронту доверять ничего нелзя

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

вот можешь увидеть что они майм тип не смотрят

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

Как бы да. Но ты же сам говоришь, что и Mime и расширение легко подделать. Как тогда?

то етсь по сути реально надо проверять расширение

что в имени файлов

Как бы да. Но ты же сам говоришь, что и Mime и расширение легко подделать. Как тогда?

ну вот я скинул

проверять внутри пхп теги

и расширения

то есть реально содержимое надо смотреть

Ну вот смотри. Я так понимаю, что этот метод isSafeFile - уже будет вызываться при получении файла через $app->input->files->get. Если даже и нет, можно вызвать отдельно. Не суть. Но вот мне нужно останавливать выполнение кода, если загруженный файл не соотвествует accept из HTML. А там не просто список расширений, а вот image/*, .pdf указаны. И как?

Ну вот смотри. Я так понимаю, что этот метод isSafeFile - уже будет вызываться при получении файла через $app->input->files->get. Если даже и нет, можно вызвать отдельно. Не суть. Но вот мне нужно останавливать выполнение кода, если загруженный файл не соотвествует accept из HTML. А там не просто список расширений, а вот image/*, .pdf указаны. И как?

ну после safe проверяешь файл пришел или нет и дальше свою логику

уде смотришь на майм тип и нужнцыфй файл или нет

уде смотришь на майм тип и нужнцыфй файл или нет

Ага. Только майм будет image/jpg, а у меня image/*. Здесь только руками писать код проверки? Отрывать звездочку, проверять, jpg. Я был удивлен, что в PHP нет готовой функции для проверки в соответствии с accept из html.

Ну вот смотри. Я так понимаю, что этот метод isSafeFile - уже будет вызываться при получении файла через $app->input->files->get. Если даже и нет, можно вызвать отдельно. Не суть. Но вот мне нужно останавливать выполнение кода, если загруженный файл не соотвествует accept из HTML. А там не просто список расширений, а вот image/*, .pdf указаны. И как?

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

Ага. Только майм будет image/jpg, а у меня image/*. Здесь только руками писать код проверки? Отрывать звездочку, проверять, jpg. Я был удивлен, что в PHP нет готовой функции для проверки в соответствии с accept из html.

и?

И... решил спросить - может она все-таки есть)

accept насколько я помню только на фронте сеет

он в заголовки запроса что-то пишет разве?

Да с ним не проблема. Он у меня доступен в PHP. Значение. Я про то, что парсить его и делать логики проверки нужно вручную, получается. Нет готовой функции типа check_file_acceept($accept)

Да с ним не проблема. Он у меня доступен в PHP. Значение. Я про то, что парсить его и делать логики проверки нужно вручную, получается. Нет готовой функции типа check_file_acceept($accept)

откуда ты возбмешь значеине accept?

оно передается где-то?

в заголовках запроса? или где?

я что-то не помню

а если заголовков нет? что тогда?

ну вот браузер какой-то который не шлет

по инпуту не формирует

Устанавливает фильтр на типы файлов, которые вы можете отправить через поле загрузки файлов. Тип файла указывается как MIME-тип, при нескольких значениях они перечисляются через запятую. Если файл не подходит под установленный фильтр, он не показывается в окне выбора файлов.

это фильтр для окна выбора для операционной системы

я не знаю чтобы он что-то формировал в запросе, даже в заголовках

Да с ним не проблема. Он у меня доступен в PHP. Значение. Я про то, что парсить его и делать логики проверки нужно вручную, получается. Нет готовой функции типа check_file_acceept($accept)

потому что нет такого

этот accpet в запросах нигде не фигурирет, откуда программа на беке узнает? если в запросе ничего нет про этот accept, а елси даже и есть, то браущеры по разному могут формировать или вообще не быть

поэтому и нет, просто потому что это не надежно, если и было бы , то этого физически нет

этот accpet в запросах нигде не фигурирет, откуда программа на беке узнает? если в запросе ничего нет про этот accept, а елси даже и есть, то браущеры по разному могут формировать или вообще не быть

Этот accept и формируется с бэкенда. Как когда ты сам задаешь допустимые форматы для загрузки.

Речь о том, что джумла перед обновлением библиотеки сначала её сносит из системы. В моём случае это заметно по удалению параметров из #__extensions ======================== Законный вопрос у разработчиков, читающих этот файл, может заключаться в том, почему мы используем тип расширения "файлы" вместо типа "библиотека", который, на первый взгляд, кажется более подходящим. Мы не сошли с ума. Мы работаем над устранением негативных последствий совершенно иного отношения Joomla к "библиотеке". пакеты, чем любой другой тип упаковки. При применении обновления к библиотечному пакету Joomla! удалит его ДО того, как он выполнит предполетное событие сценария установки. Это означает, что любые проверки, сделанные там, чтобы предотвратить установку библиотеки в несовместимом среда (например, неправильный PHP или Joomla! версии или даже предотвращение случайного понижения версии) приводит к удалению файлов библиотеки . Это действительно плохо для любого, кто пытается установить пакет библиотеки в неподдерживаемой среде. Если пакет библиотеки не выполняет никаких проверок, установленная версия библиотеки приводит к сбою зависящих от нее расширений, что приводит к закрытию сайта. Если пакет библиотеки выполняет проверки в самый ранний доступный момент времени (предполетный), вы в конечном итоге получаете старый файлы библиотеки были удалены, что снова приводит к сбою зависящих от него расширений, приводя к закрытию сайта. Независимо от того, что вы делаете, само действие по попытке установить неподдерживаемую версию библиотеки УБИВАЕТ САЙТ. Это безумие. Хуже того, это известная проблема в Joomla с ~ 2017 года, но никто не исправит ее до выхода новой основной версии. Поскольку в Joomla 4.0 это маловероятно, мы говорим о Joomla 5, срок действия которой может составлять от двух до десяти лет в будущее. Очевидно, что нам это не подходит: мы не хотим, чтобы попытки установить наше программное обеспечение приводили к тому, что сайты переставали работать! Единственное, что мы можем сделать, чтобы предотвратить сбой ваших сайтов, если вы попытаетесь установить версию нашего программного обеспечения, которая не поддерживает ваш PHP и / или Joomla! версии предназначены для доставки нашей библиотеки в виде пакета *files*. Это бессмысленно, это на 100% архитектурно неправильно, но это также единственный способ, которым мы можем применить проверки перед установкой, которые завершаются корректно, вместо того, чтобы привести к сбою вашего сайта и его сжиганию. <!-- A legitimate question among developers reading this file may be why we are using a "files" extension type instead of the "library" type which, on the face of it, seems more appropriate. We have not lost our mind. We are working around the adverse effects of the very different way Joomla treats "library" packages than any other package type. When applying an update to a library package Joomla! will uninstall it BEFORE it executes the installation script's preflight event. This means that any checks made there to prevent the installation of the library in an incompatible environment (e.g. wrong PHP or Joomla! version, or even preventing an accidental downgrade) results in the library files being UNINSTALLED.

This is really bad for anyone who tries to install a library package on an unsupported environment. If the library package runs no checks the installed library version causes the extensions that depend on it to crash, taking down the site. If the library package runs checks in the earliest available point in time (preflight) you end up with the old library files having been uninstalled which again causes the extensions that depend on it to crash, taking down the site. No matter what you do, the very action of TRYING to install an unsupported library version KILLS THE SITE. This is madness. Worse than that, this is a known issue in Joomla since ~2017 but nobody will fix it until a new major version. Since this doesn't look likely in Joomla 4.0 we are talking about Joomla 5 which could be anywhere from two to ten years into the future. Clearly this doesn't cut it for us: we don't want trying to install our software causing sites to stop working! The only thing we can do to prevent your sites from crashing to the ground if you try to install a version of our software which does not support your PHP and/or Joomla! versions is to deliver our library as a *files* package. This is nonsensical, it is 100% architecturally wrong BUT it is also the only way we can apply pre-installation checks which fail gracefully instead of causing your site to crash and burn. --> Любопытная вещь, однако https://github.com/joomla/joomla-cms/issues/35083

ищу на чистом js ленивую загрузку яндекс карты)

ищу на чистом js ленивую загрузку яндекс карты)

Таймаут загугли

ищу на чистом js ленивую загрузку яндекс карты)

https://formexpert.ru/blog/lazy-load-ili-otlozhennaya-zagruzka-dlya-yandeks-kart.html

https://formexpert.ru/blog/lazy-load-ili-otlozhennaya-zagruzka-dlya-yandeks-kart.html

Человеку хочется готовое на чистом js, без jquery, адаптировать нехочется/нет времени. Либо хорошо гуглить, либо обращаться к кому-либо за доработкой.

Человеку хочется готовое на чистом js, без jquery, адаптировать нехочется/нет времени. Либо хорошо гуглить, либо обращаться к кому-либо за доработкой.

Да не увидел

Сорчн

Чет все сложно в поиске :))

<iframe id="myIframe" src="http://.." /> <script type="text/javascript"> var iframe = document.getElementById('myIframe').src = iframe.src; iframe.src = ''; document.onload = function(){iframe.src = src;} </script>

Типо такого