Новости Joomla

Свои типы полей в Joomla.Это большая тема, о которой можно говорить очень много

Свои типы полей в Joomla.Это большая тема, о которой можно говорить очень много

👩‍💻 Свои типы полей в Joomla.Это большая тема, о которой можно говорить очень много. Самое главное, что возможности применения ограничиваются только вашей больной фантазией. Вы строите интерфейс своего модуля или плагина и вам нужно подтянуть данные из сторонней системы (список чего-нибудь по какому-нибудь API), чтобы сохранить выбранный id в Joomla. Или сделать какую-то проверку и в зависимости от неё показать то или иное сообщение пользователю. Для этого подойдут свои пользовательские типы полей. Интерфейс Joomla по большей части описан в XML-файлах. У каждого из них свои параметры. Некоторые не описаны в документации (manual.joomla.org), поэтому самым любопытным будет полезно заглянуть в собственно файлы фреймворка по пути

libraries/src/Form/FormField.php, а так же в
libraries/src/Form/Fields. У каждого класса поля перечислены его специфические свойства, которые можно описывать в XML. А в своём типе поля вы можете устанавливать эти значения программно. В моём модуле WT Quick links под капотом происходят изменения. Теперь для работы (в админке) ему нужен вспомогательный плагин. А в самом модуле нам бы проверить, а не выключен ли он? В Joomla есть тип поля Note - заметка. Его можно использовать для вывода примечаний.

<field type="note"     name="your_note_for_user"     label="Заголовок примечания"     title="Альтернативный способ для заголовка"     description="Текст примечания"     class="col-12 alert alert-info"     heading="h1"     close="true"/>
heading - указывать уровень заголовка.
close - позволяет закрыть это примечание. В классе поля
libraries/src/Form/Field/NoteField.php описана логика вывода. И в принципе оно нам подходит для нашей задачи. Но оно будет выводить сообщение всегда, а нам нужно только тогда, когда плагин отключён.Поэтому берём и создаём свой класс поля, который мы унаследуем от
NoteField. Это значит, что у нас в руках будет весь инструментарий стандартного поля
Note + то, что мы сами добавим. В XML-манифест добавляем наше поле
<field type="systempluginstatus"      name="systempluginstatus"     addfieldprefix="Joomla\Module\Wtquicklinks\Site\Fields"/>
-
type - имя файла и класса,-
addfieldprefix - указываем namespace к нашему классу, может быть любой нам нужный-
name - нельзя полю без имени...Это означает, что Joomla будет использовать класс поля из файла
modules/mod_wt_quick_links/src/Fields/SystempluginstatusField.php.А в классе поля будет написано следующее:
<?php// namespace для атрибута addfieldprefixnamespace Joomla\Module\Wtquicklinks\Site\Fields;// нельзя напрямую обращаться к этому файлуdefined('_JEXEC') or die;// подключаем родительский класс для переопределенияuse Joomla\CMS\Form\Field\NoteField;use Joomla\CMS\Language\Text;use Joomla\CMS\Plugin\PluginHelper;// имя класса и имя файла точь-в-точьclass SystempluginstatusField extends NoteField{     protected $type = 'Systempluginstatus';     protected function getLabel()          {               // если плагин не включён               if(PluginHelper::isEnabled('system','wtquicklinks')) {                    // меняем свойства родительского класса                    $this->class = 'alert alert-danger w-100';                    $this->element['label'] = '⚠️ А-а-а-а!';                    $this->element['description'] = 'Плагин не включён!!';                    // и просто рендерим его с нашими свойствами                    return parent::getLabel();               }          // А иначе всё хорошо, скрываем поле из виду.          $this->parentclass = 'd-none';          return '';     }}
Просто и удобно. И людям приятно, что о них позаботились и рассказали почему что-то не работает.@webtolkru#joomla #php #webdev #разработка

Обновлена информация в Плане развития Joomla

👩‍💻 Обновлена информация в Плане развития Joomla.Здесь собрана информация о датах релизов, описаны принципы версионирования, указаны ответственные за релизы, а так же даты окончания поддержки релизов. Опираясь на эту информацию вы можете планировать развитие ваших интернет-проектов.👩‍💻 Что нового?⛔️ Joomla 4.Дата окончания исправления ошибок безопасности в версии 4.x - 14 октября 2025г. ⚠️ После этой даты Joomla 4 прекратит получать какие-либо обновления, в том числе безопасности - вообще. Рекомендуем обновить ваши сайты до актуальной Joomla 5.✅ Joomla 5.- Дата окончания исправления ошибок в версии 5.x - 13 октября 2026г.- Дата окончания исправления ошибок безопасности в версии 5.x - 12 октября 2027 года.- Текущая актуальная (на момент написания заметки) версия - 5.3.1.- Опубликовано расписание выхода релизов Joomla 5.4. Стабильный релиз ожидается 14 октября 2025 года.✅ Joomla 6.- Дата окончания исправления ошибок в версии 6.x - 17 октября 2028г.- Дата окончания исправления ошибок безопасности в версии 6.x - 16 октября 2029г.- Опубликовано расписание выхода релизов Joomla 6.0. Стабильный релиз ожидается 14 октября 2025 года.- Для разработчиков уже доступна Joomla 6.0.0-alpha1.✅ Joomla! Framework.Обновлена информация о Joomla! Framework - полноценном PHP-фреймворке для разработки. Он в версиях 1.х и 2.х был самостоятельным параллельным проектом, однако начиная с версии Joomla 4.0 стал её основой. Добавлена информация о Joomla! Framework 3.x, который вышел 6 октября 2023 года. Его можно использовать в тех случаях, когда вам в проекте не нужна CMS Joomla целиком.Подробнее на сайте Joomla-сообщества Joomlaportal.ru#joomla #community

Компания JetBrains рассказала о своей поддержке Joomla

Компания JetBrains рассказала о своей поддержке Joomla

JetBrains - один из мировых лидеров в разработке программного обеспечения для разработчиков. Её программные продукты - это IDE - профессиональные среды разработки, которые отличаются от простого блокнота/редактора с плагинами набором всевозможных инструментов для разработчиков, глубоким анализом кодовой базы, подсказками по ней и по языку программирования, отладкой ошибок и многим-многим другим. Одним из самых известных продуктов компании является IDE PHP Storm, который можно назвать отраслевым стандартом PHP-разработчика.

В статье How PhpStorm Helps Maintain PHP Open-Source Projects: Interviews and Real-World Examples в блоге компании описываются Open Source проекты, которым JetBrains оказывает поддержку (это могут быть бесплатные лицензии для разработчиков для некоммерческих проектов).

В список попали:

  • PHPUnit - фреймворк для unit-тестирования в PHP
  • Doctrine DBAL - библиотека для PHP, которая предоставляет лёгкий и гибкий слой для коммуникации с базой данных. Она поддерживает различные базы данных через единый и согласованный API.
  • CodeIgniter — популярный MVC-фреймворк для разработки на PHP
  • Joomla! - наша любимая CMS.

Эти названия (кроме "Joomla") чаще всего не слышат вебмастера и разработчики обычных сайтов и интернет-магазинов. Но эти названия хорошо знакомы PHP-разработчикам, которые создают сложные и высоконагруженные проекты и микросервисы. То, что Joomla оказалась в одном ряду с такими программными инструментами - делает ей честь.

🙏 За ссылку спасибо участнику нашего сообщества Ринату Кажетову (@rkazhet).

Подпишитесь на @joomlafeed

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

Столкнулся с проблемой - перенагрузка на сервер по вине скриптов Джумлы

то есть - скрипт загружается и по несколько часов выполняется по циклу, не завершаясь.
Хостинг - Hostpro




Цитировать
Добрый день, за последние пару дней ко мне как веб-програмисту
обращалось более десяти людей с идентичными проблемами.
Все они использовали движок Joomla. Всем им ихние хостеры
заблокировали акаунты.
На форуме движка Joomla есть топик где десятки людей рапортуют о такой
проблеме.

Локализовать проблемный участок мне удалось лишь частично. Это
практически любой компонент который в цикле делает выборки из СУБД. Но
"криворукие" програмисты Joomla используют подавление ошибок через @ и
не делают обработки ошибок/исключений если mysql_query или
mysql_result возвращают не тот результат или вобще утрачен конект.
Практически если во время работы скрипта утрачивается конект к БД,
скрипт завершить работу может только по таймауту (php.ini:
max_execution_time)

Предполагаю что на вашем хостинге кроме моих есть ещё много сайтов
которые используеют этот популярный движок, но "оптимизировать"
владельцам вряд ли удастся пока Joomla не выпустит обновление.

Так же, я был удивлен что max_execution_time у вас по умолчанию 7200
секунд (это 2 часа).
Кардинальным решением проблемы до выхода обновлений Joomla я считаю
выставить всем или каждому лично max_execution_time=5-15 секунд, т.е.
если проблема зацикливания проявится, скрипт не будет 2 часа грузить
CPU, а через 5 секунд (достаточно для нормальной работы любого
веб-сайта) будет принудеительн озавершен интерпретатором PHP.

В этом сайте я уже установил в скриптах
set_time_limit(5);
и ходатайствую об открытии доступа к этой папке.
Возможно такая просьба недавно приходила по e-mail от другого человека
который курирет этот сайт.


ahcu> Здравствуйте, .

ahcu>     Ваш сайт создаёт нагрузку на нашем сервере. Это негативно
ahcu>     сказывается на всей работе сервера. Оптимизируйте пожалуйста
ahcu>     данный скрипты. Это не нормально когда php скрипт работает такое
ahcu>     количество времени.

если такое происходит - мне порекомендовали прописать в
configuration.php
строчку
set_time_limit(5);

это должно предотвратить цикличное выполнение завснувшего скрипта и перенагрузку на сервер из-за етого.

Вот здесь человек запостил свое мнение:
http://php.com.ua/forum/viewtopic.php?t=6628


Далее  нашел вот такую инфу о возможности зависа самой MySQL

"I suppose it's some kind of stack overflow in the IF() function."
http://bugs.mysql.com/bug.php?id=21476
« Последнее редактирование: 26.09.2006, 22:42:47 от ukrmedshpora »
*

smart

  • Администратор
  • 6478
  • 1318 / 15
  • Хочешь сделать хорошо — сделай!
Цитировать
Локализовать проблемный участок мне удалось лишь частично. Это практически любой компонент который в цикле делает выборки из СУБД. Но "криворукие" програмисты Joomla используют подавление ошибок через @ и не делают обработки ошибок/исключений если mysql_query или mysql_result возвращают не тот результат или вобще утрачен конект.
мдя, интересно, а автор этих строк вообще смотрел как в самой Joomla происходит работа с БД? то, что он нашел проблему в галерее DatsoGallery, где за многовековую историю компонента (сначала AkoGallery, затем PonyGallery) набралось куча мусора, отнюдь не означает, что виновата Joomla...

В Joomla и ее расширениях, вся работа с базой данных осуществляется через 2 класса database и mosDBTable. И поверьте, единственное место, где в них происходит подавление вывода ошибки, это при подключении к БД, и то, сама ошибка прекрасно обрабатывается... В этом вы можете сами убедиться внимательно изучив код внутри файла /includes/database.php. Поэтому все расширения, которые используюьт предложенный ядром системы интерфейс работы с базой данных описанных проблем создавать не могут...

Так что приведенные заявления, к самой Joomla никакого отношения не имеют... А что касается качества сторонних расширений, то это уже собственно на совести их разработчиков.

но человек ведь не спец в джумле - он посмотрел только кусок кода - увидел ошибку - и сообщил, ведь хочет помочь человек
http://forge.joomla.org/sf/tracker/do/viewArtifact/projects.joomla/tracker.bugs/artf6121?_message=1159293810550
*

saschaAG

  • Новичок
  • 5
  • 5 / 1
Странные люди

 :o :o :o

Такие и машин то себе не покупают потому что те об стены бетонные мнутся, ломаются если заднию на полной скорости врубить.
Криворукое автомобилестроение!!!!!!!!

ответ по аське от автора приведенных выше строк:
"Ядро системы Joomla никак не обрабатывает ошибку утраты конекта к БД которая появляется в т.ч. из-за бага http://bugs.mysql.com/bug.php?id=21476
Когда $this->_resource уже ни на что не указывает, @subpackage Database будет продолжать пытаться выполнить запрос и/или рапортовать о ошибке выполнения запроса (если включен дебаг) но mysql_error() тоже не сможет выполниться т.к. переданный ей  $this->_resource не существует
"
@
 /**
 * Execute the query
 * @return mixed A database resource if successful, FALSE if not.
 */
 function query() {
  global $mosConfig_debug;
  if ($this->_debug) {
   $this->_ticker++;
     $this->_log[] = $this->_sql;
  }
  if ($this->_limit > 0 || $this->_offset > 0) {
   $this->_sql .= "\nLIMIT $this->_offset, $this->_limit";
  }
  $this->_errorNum = 0;
  $this->_errorMsg = '';
  $this->_cursor = mysql_query( $this->_sql, $this->_resource );
  if (!$this->_cursor) {
   $this->_errorNum = mysql_errno( $this->_resource );
   $this->_errorMsg = mysql_error( $this->_resource )." SQL=$this->_sql";
   if ($this->_debug) {
    trigger_error( mysql_error( $this->_resource ), E_USER_NOTICE );
    //echo "<pre>" . $this->_sql . "</pre>\n";
    if (function_exists( 'debug_backtrace' )) {
     foreach( debug_backtrace() as $back) {
      if (@$back['file']) {
       echo '<br />'.$back['file'].':'.$back['line'];
      }
     }
    }
   }
   return false;
  }
  return $this->_cursor;
 }


что будет с этим скриптом если $this->_resource не будет указывать на валидный конект?
@

http://phpclub.ru/paste/index.php?show=1462
« Последнее редактирование: 27.09.2006, 00:07:19 от ukrmedshpora »
*

smart

  • Администратор
  • 6478
  • 1318 / 15
  • Хочешь сделать хорошо — сделай!
но человек ведь не спец в джумле - он посмотрел только кусок кода - увидел ошибку - и сообщил, ведь хочет помочь человек
я понимаю что хочет, но я очень сомневаюсь, что у него есть право безапелляционно называть разработчиков Joomla "криворукими"...

Когда $this->_resource уже ни на что не указывает, @subpackage Database будет продолжать пытаться выполнить запрос и/или рапортовать о ошибке выполнения запроса
когда $this->_resource не валиден, то после строки:


$this
->_cursor mysql_query$this->_sql$this->_resource ); 


переменная $this->_cursor будет иметь значени FALSE, затем мы попадем в блок обработки ошибок (да, ошибки не отработаются, бо $this->_resource не валиден, но беды не произойдет) и затем функция query вернет значение FALSE. И где тут возможно зацикливание?

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

P.S. кстати, приведенная ошибка, по которой MySQL может терять коннект, подтверждена пока вроде только для версии 5.0.22, а Joomla официально вообще-то MySQL 5.x не поддерживает. Совместимость с пятеркой обещали в версии 1.5:

Цитировать
To achieve cross database support, a database abstraction library will be implemented. Core scripting will also be improved to prepare for compatibility with other platforms.  The first step towards this goal will be compatability with MySQL 5.0 which is tentatively slated for Joomla! 1.5
« Последнее редактирование: 27.09.2006, 00:37:44 от smart »

> я понимаю что хочет, но я очень сомневаюсь, что у него есть право
> безапелляционно называть разработчиков Joomla "криворукими"...
я был не в курсе чем разработчик com_joomfish или com_dartsogallery отличается от разработчика Joomla, т.к. джумлу в глаза не видел, но надо было в кратчайшие сроки добиться разблокировки акаунта хостером. Извините что выразился не по адресу

> Если кто-то из сторонних разработчиков игнорирует возвращаемый результат, то
> разработчики Joomla тут не виноваты, хотя все-таки стоило бы сделать более полную
> обработку ошибок...
если кто-то из разработчиков софта вешает Windows 98 и она от этого падает то винить будут Билли. Почему централизовано не сделать full-stop скрипта при первом неотработанном SQL запросе? Или неотработка SQL запроса это не "Fatal error" а всего лишь "Notice"?

> P.S. кстати, приведенная ошибка, по которой MySQL может терять коннект, подтверждена
> пока вроде только для версии 5.0.22, а Joomla официально вообще-то MySQL 5.x не
 > поддерживает. Совместимость с пятеркой обещали в версии 1.5:
Баг проверен на трех разных серверах MySQL 4.1
*

smart

  • Администратор
  • 6478
  • 1318 / 15
  • Хочешь сделать хорошо — сделай!
если кто-то из разработчиков софта вешает Windows 98 и она от этого падает то винить будут Билли.
если ставить задачей кого-то обвинить, то обвинить можно кого угодно...

Почему централизовано не сделать full-stop скрипта при первом неотработанном SQL запросе? Или неотработка SQL запроса это не "Fatal error" а всего лишь "Notice"?
Можно и останавливать, а можно возложить это на разработчиков расширений и предоставить им решать, является ли это критической ошибкой, или нет... Хотя конечно, проблему потери коннекта с базой, должно решать ядро...

Баг проверен на трех разных серверах MySQL 4.1
ни разу не сталкивались, хотя у нас на сервере стоит 4.1...

Кстати, мне кажется, стоит задуматься вот еще о чем: если такая ошибка повторяется, значит коннект постоянно падает? Может быть предложить хостеру вместо отключения аккаунтов решить проблему с сервером?

Интересно так быть посредником в перепалке двух спецов ))

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

> ни разу не сталкивались, хотя у нас на сервере стоит 4.1...
так это зависит от размера злосчастного thread_stack
увеличивать его хостер категорично отказался

Вот ответ от сотрудника MySQL который подтвердил http://bugs.mysql.com/bug.php?id=21476
[19:48] <sveta> в общем от меня далее мало зависит, как этот баг фиксить будут, но спросить могу
[20:01] <sveta> вообще раз баг verified, то его фиксить будут
[20:01] <sveta> и странно, что ещё не фиксят: я узнаю почему
[20:43] <sveta> .msg Yurik послала письмо человеку, ответственному за то, чтобы верифицированные баги фиксились
*

smart

  • Администратор
  • 6478
  • 1318 / 15
  • Хочешь сделать хорошо — сделай!
Интересно так быть посредником в перепалке двух спецов ))
бывает...

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

так это зависит от размера злосчастного thread_stack
увеличивать его хостер категорично отказался
Интересненько, а какое значение там установлено? Судя по конфигурации сервера, у нас thread_stack:  196608

Вот ответ от сотрудника MySQL который подтвердил
да верю, верю... просто на странице с багом, где написано verified, указана была версия 5.0.22, и вроде не было указаний на линейку 4.1...

Мне лично сапорт ответил (после указания им ссылки на баг):

У нас из соображений стабильности сервера:
thread_cache_size=128
К сожалению, изменению это не подлежит.
=

Я сам посмотрел в настройки Мускуеля:
 table cache     1,024
table type    MyISAM
thread cache size    128
thread stack    196,608

*

smart

  • Администратор
  • 6478
  • 1318 / 15
  • Хочешь сделать хорошо — сделай!
table cache     1,024
table type    MyISAM
thread cache size    128
thread stack    196,608
а у нас:

table cache     500
table type    MyISAM
thread cache size    12
thread stack    196,608

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

Проблемы запуска сайта на локальном сервере

Автор uragan87

Ответов: 0
Просмотров: 2567
Последний ответ 04.06.2013, 23:26:17
от uragan87
проблемы при установке

Автор saymonik

Ответов: 4
Просмотров: 6085
Последний ответ 01.12.2011, 22:08:52
от DPavlov
Установка Joomla в поддиректорию...Есть проблемы

Автор Keno

Ответов: 13
Просмотров: 11985
Последний ответ 25.05.2010, 13:46:30
от garnir
Проблемы при переносе в другую директорию

Автор esistema

Ответов: 3
Просмотров: 3965
Последний ответ 12.10.2009, 16:39:01
от Jekos
проблемы с переносом на хост

Автор robotwerder

Ответов: 8
Просмотров: 3665
Последний ответ 18.06.2009, 15:58:12
от robotwerder