Ладно, как @CB9TOIIIA говорит - всюду творчество ))

Сейчас задача загрузить файл, сделать всяких проверок к нему, положить куда надо по логике. Но сейчас получается так, что контроллер даже не цепляется, хотя должен ))))

Путь джедая

Я когда файл грузил - курил инсталлятор

Вот я его же и курю.

Кури вдумчиво :-)

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

Тоже смотрел

@sergeytolkachyov давай в чате голосом ?)

@sergeytolkachyov меня слышно?)

Идите к нам в зум

сек

Иди тоже в деве РМ в зум

В общем по логике наверное так. В контроллере: - проверяем CSRF-токен - получаем файл - проверяем файл на право загрузки, размер файла, расширение файла, MIME-тип файла - проверяем юзера на гостя Дальше, наверное, нужно передать работу $model->save(). Она уже будет перемещать файл в зависимости от юзера в нужную папку, писать в бд данные о файле и возвращать в контроллер конечный путь к файлу. А тот уже будет делать JsonResponse. Можно также вынести проверки на размер, расширение и MIME-тип в $model->validate() Верно, мастера джедаи? )))

https://www.akeeba.com/news/1761-self-hosted-monitoring-panopticon.html 🤔

https://www.akeeba.com/news/1761-self-hosted-monitoring-panopticon.html 🤔

https://www.akeeba.com/news/1761-self-hosted-monitoring-panopticon.html 🤔

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

libraries/src/Helper/MediaHelper.php, метод canUpload() - хороший метод, делает в принципе всю работу по проверке расширений загружаемого файла, MIME (картинок и не картинок), имени файла. Но есть 2 но: - !Factory::getUser()->authorise('core.manage', $component) - в конце одного из разветвлений метода. На фронте не всегда получится использовать. - на скриншоте - на вход передаем свой компонент. Но в его настройках должны быть указаны параметры с такими же именами, как у com_media. Тогда получится воспользоваться готовым методом и не писать свой.

на фронте сработает?

Работает, но нужно названия параметров чтоб были как в com_media

С фронта оно вроде и не надо. Но мало ли кто будет прикреплять документы или архивы с фронта. Тогда именно этот метод не прокатит, как я понимаю.

ну некоторые прикрепляют pdf

я в итоге свое писал

я в итоге свое писал

$userfile = $input->files->get('upload_file', null); - возвращает массив с данными файла $canUpload = (new MediaHelper)->canUpload($userfile,'com_wtproductbuilder'); - кидать туда надо прям этот массив с файлом. А в конфиге своего компонента обеспечить наличие параметров как у com_media - с теми же именами. - restrict_uploads_extensions - ignore_extensions - upload_maxsize - restrict_uploads 3-м параметром можно добавить массив со своими расширениями файлов для "белого списка". Вроде норм работает.

Кинул PHP файл - он даже не дошёл до проверки медиа хелпером.

Проверь .txt

Там где-то в Input есть фильтр

Проверь .txt

Тоже null

Что значит null

$userfile = $input->files->get('upload_file', null); вот тут null пришёл вместо массива с файлом

Пробовал svg поменять расширение на jpg?

Пробовал svg поменять расширение на jpg?

Типа отфильтровал ?

Привет. Может оффтоп, кто нибудь настравиал чтобы файлы были н аодном сервере а бд на другом? НА сколько это увеличить скорость загрузки сайтов? стоит ли оно того? з

Привет. Может оффтоп, кто нибудь настравиал чтобы файлы были н аодном сервере а бд на другом? НА сколько это увеличить скорость загрузки сайтов? стоит ли оно того? з

Привет. Может оффтоп, кто нибудь настравиал чтобы файлы были н аодном сервере а бд на другом? НА сколько это увеличить скорость загрузки сайтов? стоит ли оно того? з

Привет. Может оффтоп, кто нибудь настравиал чтобы файлы были н аодном сервере а бд на другом? НА сколько это увеличить скорость загрузки сайтов? стоит ли оно того? з

)))

Всё зависит от того, какую задачу вы решаете и какие инструменты у вас для этого есть В большинстве случаев это только навредит работае сайта, т.к. соединение с сервером баз данных будет замедляться из-за ограничений сети. Грубо говоря, у вас есть 2 VDS-ки и вы хотите на одной держать приложение, а на другой базу. Они будут лежать, скорее всего, не только в на разных физических серверах, но и в разных стойках серверных. А это значит, что соединение с базой должно пройти через виртуальный маршрутизатор гипервизора, птом через физический маршрутизатор стойки, потом через маршрутизатор в где подсеть нужной стойки получится разрулить, потом маршрутизатор конечной стойки, маршрутизатор гипервизора. Это всё - сетевые задержки. Плюс локальный ip вам наврядли сообщат и стучаться вы будете по внешнему ip, который где-то на шлюзе только разрулится. А ещё хуже, если по доменному имени стучать будете. Там фризы на DNS'ах добавятся. Ну и сама пропускная способность сети вас тоже замедлит. Сеть-то там быстрая, но ваше подключение будет выглядить, как "выйти в интернет", поэтому канал вам задушат программно на шлюзе Решение - VLAN между серверами. Но "душить" канал вам не перестанут. Так что профит минимальный Ещё и большенство провайдеров блокируют возможность поднимать vlan'ы на своих серверах, т.к. это им потом много неясностей в мониторинге внесёт Другой вариант, если вы в облаке работаете, где, по умолчанию, всё на vlan'ах построено и только потом в глобальную сеть через шлюзы идёт. Там и сеть оптимизирована и задержки минимальные и "душить" канал никто не будет. Облака, имею в виду, это что-то типа selectel/yandex cloud/vk cloud/sber cloud/mts cloud Но там цена выше намного! И самое главное, - быстрее локальной базы ничего не может быть. Такие телодвижения, в основном, предпринимаются, если приложение должно масштабироваться. Или, например, вы упёрлись в производительность дисковой системы и приложение не может работать, потому что база диск задрочила. Ну или бездонный запас ОЗУ иссякает. Тогда это целесообразно. В остальных случаях вы получете жуткие просалдки на соединение с базой и приложение станет работать ещё медленее. Короче, сначала смотрите на задачуи на то, что конкретно "тормозит" и как это можно ускорить Из личного опыта могу сказать, что база может вешаться из-за отсутсвия кэша на приложении, из-за некорректных настроек сервера СУБД (частая проблема - под кэш в ОЗУ выдано слишком много места и оно резервируется сразу, при запуске сервера), база слишком сильно дрочит диск, база или приложение начинают лезть в swap из-за отсутсвия ограничений на потребление памяти, база слишком часто дампит данные на диск, приложение хранит в базе то, что можно было бы хранить в другом месте (сессии, например)