Новости Joomla

Вышли релизы безопасности Joomla 6.1.3 и Joomla 5.4.8

Релиз безопасности Joomla 6.1.3 и Joomla 5.4.8

Проект Joomla! рад сообщить о выходе Joomla 6.1.3 и Joomla 5.4.8. Это релизы безопасности и исправления ошибок для серий 5.x и 6.x.

👩‍💻 WT Otpravkapochtaru - библиотека сервиса Отправка Почты России для Joomla-разработчиков.

👩‍💻 WT Otpravkapochtaru - библиотека сервиса Отправка Почты России для Joomla-разработчиков.

Joomla 5+ пакет для интеграции с API Почты России: нормализация данных, расчёт доставки, создание отправлений, партии, документы, возвраты, поиск отделений, справочники и SOAP-отслеживание.

v.3.0.0. Что нового?
Это дальнейшее развитие ранее закрытой Joomla-библиотеки для работы с API сервиса Отправка (для бизнеса) Почты России. Поэтому версия не 1.0.0, а 3.0.0.

Сейчас эта библиотека ушла от собственных реализаций и стала Joomla-обёрткой известного PHP SDK от Lapay Group.

Возможности библиотеки.
- получение настроек аккаунта, точек сдачи и текущего остатка запросов к API;
- нормализация адресов, ФИО и телефонов перед созданием отправления;
- расчёт тарифа и срока доставки;
- создание, поиск, изменение, удаление и возврат заказов в состояние «Новые»;
- проверка надёжности получателя;
- создание партий, просмотр партий и заказов внутри партии;
- генерация пакета печатных документов и формы Ф103;
- создание, изменение и удаление возвратных отправлений;
- поиск отделений по индексу, адресу и координатам, получение сервисов отделения;
- локальный список стран;
- SOAP-отслеживание операций по РПО и работа с билетами пакетного трекинга.

👩‍💻 Joomla-возможности.
В пакете библиотеки WT Otpravkapochtaru есть поля Joomla Form для расширений. Они позволяют работать в интерфейсе Joomla с некоторыми типами данных, получаемых по API из вашего личного кабинета в ЛК Почты России для бизнеса.
На данный момент в библиотеке доступны 3 поля списков, которые отображают доступные в аккаунте ОПС, типы и категории отправлений.
Поддерживаются зависимые списки: значение одного поля обновляется при изменении другого.

Системные требования.
Системные требования в основном связаны с системными требованиями апстрима библиотеки - LapayGroup PHP SDK.
- Joomla 5+
- PHP 8.3+
- Расширения PHP:
-- ext-mbstring
-- ext-simplexml
-- ext-soap (опционально, для трекинга)
-- ext-zip

Ссылки:
- Страница расширения
- GitHub библиотеки и документация

@joomlafeed

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

smart

  • Администратор
  • 6478
  • 1318 / 15
  • Хочешь сделать хорошо — сделай!
Есть задача (всем строкам в таблице у которых родитель нулевой проставляем 0-й уровень, остальным - некое большое фиксированное число), которая решается 2-мя запросами:

Код: sql
update table1 set level = 0 where parent = 0;
Код: sql
update table1 set level = 999 where parent <> 0;

Какое именно число ставить - тут не принципиально, оно должно быть положительным и заведомо большим некоей величины, допустим 100 (в моей задаче это нереальная вложенность для комментариев).

Так вот появилась мысль, сократить это до одного запроса, но есть сомнение, что это корректно (в смысле не будет ли потом кто-то меня проклинать за такой запрос):

Устанавливаем полю level тип tinyint и обходимся одним запросом:
Код: sql
update table1 set level = parent * 999;

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

Вроде кратко, один запрос вместо двух... Но почему-то сомнения меня гложут, нужна ли такая оптимизация? Что-то последнее время мне в голову приходят странные решения, порой настолько странные, что уже пахнет серой ;)
« Последнее редактирование: 08.12.2009, 23:39:39 от smart »
*

beliyadm

  • Легенда
  • 9758
  • 1665 / 66
  • Севастополь, Россия
Re: [SQL] Допустимо или неприлично?
« Ответ #1 : 08.12.2009, 23:18:34 »
Ну если брать первый вариант - то достаточно условия parent > 0 (ведь у тебя же родитель не может быть отрицательным)
А второй вариант - гениальность ленивой оптимизации, действительно зачем 2 запроса когда достаточно одного. Единственно что учитывай скорость выполнения математических операций на уровне запросов - они всяко медленней, нежели установка заданного значения.
Что выбрать - в зависимости от места выполнения запроса, нужна ли такая оптимизация и что она даст в приросте производительности
Все истины, которые я хочу вам изложить, — бесстыдная ложь. Сделать всё хорошо
TLG: @Beliyadm
*

era

  • Администратор
  • 1588
  • 392 / 5
  • В туалете лучше быть пользователем, чем админом.
*

smart

  • Администратор
  • 6478
  • 1318 / 15
  • Хочешь сделать хорошо — сделай!
Re: [SQL] Допустимо или неприлично?
« Ответ #3 : 08.12.2009, 23:23:47 »
Задача в принципе простая - мне нужно для существующих уже комментариев корректно расставить значение поля level. Чтобы в будущем я мог подгружать не весь список, а допустим только 2 первых уровня, а остальное - по запросу пользователя.

В случае с MySQL, без использования высокой магии, это решается сначала путем простановки корневым нулевого уровня, всем остальным 255, и дальше итеративно, мы увеличиваем уровень для всех, у кого уровень на единицу меньше текущего. В конечном счете, вроде бы не очень сложная задача, и не очень трудоемкая. Единственная проблема, я знаю сайты, где в JComments крутится несколько десятков тысяч комментариев... И вот меня очень пугает, процесс обновления на таких сайтах... Поэтому и задумался о максимальной оптимизации этого процесса.

а оператор CASE в UPDATE низя использовать?
Вот скажу честно Саш, я никогда в MySQL его не использовал, ибо не знаю, есть он там или нет, и с какой версии... В Informixб, DB2 и MS SQL, конечно бы я им воспользовался, ибо там он с незапамятных времен, а вот тут, меня честно говоря взяло сомнение, а природная лень не позволила пойти почитать. Но есть у меня опасения, что в 4.1 его не было (хоть может я и неправ, и зря клевещу на MySQL).
*

beliyadm

  • Легенда
  • 9758
  • 1665 / 66
  • Севастополь, Россия
Re: [SQL] Допустимо или неприлично?
« Ответ #4 : 08.12.2009, 23:26:50 »
В Informixб, DB2 и MS SQL, конечно бы я им воспользовался, ибо там он с незапамятных времен, а вот тут, меня честно говоря взяло сомнение, а природная лень не позволила пойти почитать.
Усе там на месте :)
4.x - http://dev.mysql.com/doc/refman/4.1/en/control-flow-functions.html
5.x - http://dev.mysql.com/doc/refman/5.0/en/control-flow-functions.html
Все истины, которые я хочу вам изложить, — бесстыдная ложь. Сделать всё хорошо
TLG: @Beliyadm
*

smart

  • Администратор
  • 6478
  • 1318 / 15
  • Хочешь сделать хорошо — сделай!
Re: [SQL] Допустимо или неприлично?
« Ответ #5 : 08.12.2009, 23:39:23 »
Ну вот и славно. Значит я сегодня изобрел еще один ма-а-а-аленький велосипед. Зато сам... Вопрос снят... Ответ: неприлично.
*

Darkick

  • Завсегдатай
  • 1142
  • 239 / 1
А я как то не сторонник экономии на спичках, по мне лучше немного больше и медленнее, но логичней и понятней. А оптимизацию возлагаю на сервер БД.
*

shprota

  • Давно я тут
  • 770
  • 53 / 1
  • Тружусь, не покладая рук
Для древовидных структур очень рекомендую использовать модель вложенных наборов (The Nested Set Model).
Немного сложно добавлять и перемещать элементы в дереве, но зато основные задачи вывода и форматирования делаются одним запросом.
Чтобы оставить сообщение,
Вам необходимо Войти или Зарегистрироваться