Новости Joomla

Загадочный параметр $live_site в configuration.php Joomla

Загадочный параметр $live_site в configuration.php Joomla

👩‍💻 Загадочный параметр $live_site в configuration.php Joomla. Зачем он нужен?Давным-давно, когда Joomla ещё была маленькой, в неё внедрили параметр $live_site. В ней хранился домен текущего сайта на случай, если Joomla не могла его определить из-за неверной настройки сервера. Нужно это было для разных SEO-компонентов, для использования редиректов и т.д.Со временем для работы собственно сайта этот параметр перестал быть нужным. Уже в начале 2010-х стали встречаться рекомендации оставлять этот параметр пустым, дабы оный не привёл к лишним проблемам и путанице. Тем более, в web-админке нет места, где его можно указать или посмотреть его значение. Только в configuration.php, а туда смотрят не часто.Однако, параметр всё же остался в ядре Joomla. Зачем он нужен? А нужен он в 2-х случаях:- для работы класса Joomla\CMS\Uri\Uri, который часто используется в коде Joomla для работы методов

Uri::root() и
Uri::base(), а значит может влиять и на работу в том числе ajax-скриптов.- для работы Joomla в CLI - командной строке сервера. В случае если вы используете в вашем CLI-плагине методы опять-таки класса Uri, то CLI ничего не знает о текущем домене, так как запускается вне web-сервера. Поэтому домен нужно указывать принудительно. Либо с помощью параметра командной строки
--live-site, например,
—live-site=https://site.ru/. Со слешем на конце, иначе в CLI адрес сайта станет
https://site.rujoomla.php.Либо в параметре
$live_site в файле configuration.php, так как
CliApplication берёт настройку оттуда, если параметр команды не указан или пуст.⚠️ Иначе в качестве хоста и url класса Uri будет установлено
https://joomla.invalid/set/by/console/application. В самом же коде команды получить параметр
$live_site можно из объекта приложения

protected function doExecute(InputInterface $input, OutputInterface $output): int    {         //...              $live_site = $this->getApplication()->get('live_site');         //...    }
и исходя из этого строить дальнейшую логику.@joomlafeed#joomla #разработка #php #cli

Вышел плагин AllVideos v.7.0 от JoomlaWorks

Вышел плагин AllVideos v.7.0 от JoomlaWorks

Вышел плагин AllVideos v.7.0 от JoomlaWorks.Этот контент-плагин - одно из старейших расширений для Joomla. Его задача - преобразовывать шорт-коды вида

{YOUTUBE}...{/YOUTUBE},
{MP3}parth/to/file.mp3{/MP3} и подобные во встроенные видео или аудио.👩‍💻 v.7.0.0. Что нового?- Добавлена поддержка Youtube Shorts. Просто скопируйте полный url видео и вставьте его внутри тегов
{YOUTUBE}...{/YOUTUBE}.- Поддержка Joomla 5.x без плагина обратной совместимости. PHP 5, PHP 7, PHP 8. - Индексация умным поиском в CLI. В Joomla 5 плагин перестал вызывать ошибку при индексации контента умным поиском через CLI,Заметьте, что этот один и тот же пакет для всех версий Joomla, начиная с 1.5.x и заканчивая 5.x. Технически "под капотом" код плагина по сути не менялся, а для поддержки следующих версий Joomla авторы вставляют "заплатки". Плагин всё ещё использует старую архитектуру файлов и классов Joomla, что, к сожалению, заставляет прибавлять к его описанию слова "пока ещё" - "пока ещё работает".
Страница расширенияGitHub расширенияJoomla Extensions Directory👩‍💻 За ссылку спасибо самому внимательному участнику нашего сообщества - Ринату Кажетову (@rkazhet).@joomlafeed#joomla #расширения

0 Пользователей и 1 Гость просматривают эту тему.
  • 5 Ответов
  • 1222 Просмотров
*

master-smeta

  • Захожу иногда
  • 298
  • 10 / 0
Здравствуйте. Возник такой банальный вопрос: при создании своего модуля/компонента стили и скрипты подключать отдельными файлами для каждого модуля/компонента, или же дописывать в общие стили/скрипты шаблона? На примере Joomla 3 - в шаблонах уже есть стили и скрипты бутстрапа и JQuery... И вроде как не нужно изобретать велосипеды, а можно использовать встроенные (выпадающие менюшки, всплывающие окошки...).

1. Отдельные файлы
Плюсы:
  • Удобно искать и изменять эти самые стили и скрипты.
  • Такой модуль можно легко установить на любой сайт
  • Стили и скрипты подгружаются только на тех страницах, на которых опубликован модуль
Минусы:
  • Если модулей много, то и файлов подключается много, что создает дополнительную нагрузку
  • Нужно контролировать имена переменных, чтобы избежать конфликтов и перекрытия стилей

2. Общие файлы шаблона
Плюсы:
  • Удобно искать и изменять эти самые стили и скрипты. Все хранится в одном файле
  • Можно сэкономить на некоторых стилях/скриптах, используя встроенные в шаблон
  • Можно использовать сжатие, спрайты и т.п.
Минусы:
  • Все стили/скрипты загружаются независимо от того, будут ли они использоваться на странице
  • Нельзя так просто взять и поставить модуль на другой сайт. Нужно прописывать стили/скрипты в шаблон.

У каждого способа свои плюсы, но что же все таки лучше?
*

b2z

  • Глобальный модератор
  • 7284
  • 778 / 0
  • Разраблю понемногу
*

master-smeta

  • Захожу иногда
  • 298
  • 10 / 0
Причем тут шаблон? Если пользователь его поменяет, что будете делать?
Ок, уточню: пользователи не могут менять шаблоны. Т.е. внешний вид сайта контролируется только администратором.
*

zomby6888

  • Завсегдатай
  • 1473
  • 171 / 3
Лучше такой способ который больше подходит Вам в конкретной ситуации. Если вы разрабатываете модуль/компонент для его использования на многих сайтах или для его распостранения то вам больше подходит первый вариант, если для конкретного сайта то второй.
Цитировать
Если модулей много, то и файлов подключается много, что создает дополнительную нагрузку

Не совсем очевидный минус. В конце концов все стили и скрипты для модуля вы можете хранить в одном файле и если вы их правильно подключаете в вашем модуле то система не даст вам подключить их дважды. К тому же если у вас настроено сжатие и объеденение эта проблема перестает существовать так как это будет работать для всех скриптов и стилей а не только на уровне шаблона
интернет-блог: http://websiteprog.ru
*

fbr

  • Завсегдатай
  • 1662
  • 206 / 7
Вариант
В модуле/компоненте предусмотреть настройки, позволяющие переключать режимы
  • стили из модуля/шаблона
  • Bootstrap из модуля/шаблона (необходимые для функционирования стили и скрипты должны быть в модуле)
В зависимости от выбранного режима будут подключаться те или иные файлы.

да, это утяжелит модуль, но добавить гибкость
*

master-smeta

  • Захожу иногда
  • 298
  • 10 / 0
Вариант
В модуле/компоненте предусмотреть настройки, позволяющие переключать режимы
  • стили из модуля/шаблона
  • Bootstrap из модуля/шаблона (необходимые для функционирования стили и скрипты должны быть в модуле)
В зависимости от выбранного режима будут подключаться те или иные файлы.

да, это утяжелит модуль, но добавить гибкость

вот до этого я не догадался :) действительно, лучше добавить лишних пару строчек кода и получить универсальный результат.
Спасибо, тему можно закрывать.
Чтобы оставить сообщение,
Вам необходимо Войти или Зарегистрироваться
 

Вопрос на засыпку

Автор Aleks.Denezh

Ответов: 5
Просмотров: 951
Последний ответ 10.03.2019, 23:15:22
от Aleks.Denezh
Появились ошибки модулей при переносе сайта с локалки на боевой серв

Автор nest

Ответов: 3
Просмотров: 1844
Последний ответ 25.11.2015, 11:52:30
от nest
Вопрос по JFormField

Автор Hol1killer

Ответов: 11
Просмотров: 2366
Последний ответ 26.01.2015, 14:39:41
от robert
Вопрос по PROFILER и JFactory

Автор Haybul

Ответов: 2
Просмотров: 1833
Последний ответ 02.08.2014, 04:33:57
от Haybul
Вопрос об использовании AJAX в модуле

Автор maxakagaret

Ответов: 13
Просмотров: 1816
Последний ответ 26.02.2014, 18:16:17
от maxakagaret