блин, там ещё pgsql же база 🤦‍♂️

Я забыл про неё

Уважаемое сообщество, как вы думаете, стоит ли блок metada переименовывать в SEO?

+ и обеденить все что касается seo в одном месте,😊

Вот такой блок получается

для категорий, статей, контактов, новостных лент и тегов

И назвать раздел SEO, чтобы было понятно всему

Остаются моменты пока: - сконвертировать article_page_title в новое поле, т.к. он хранится в серелиазованой строке - добавить счётчик символов для title - убрать строгое ограничение для вводимого кол-ва символов, т.к. это не ограничения а всего лишь рекомендация

Умные дядьки @drekun @Septdir Если я делаю pr, который вносит изменения в структуру БД. Я же должен ещё и updatescript какой-то делать?

В папке installation

Ты же это для четверки делаешь?

Остаются моменты пока: - сконвертировать article_page_title в новое поле, т.к. он хранится в серелиазованой строке - добавить счётчик символов для title - убрать строгое ограничение для вводимого кол-ва символов, т.к. это не ограничения а всего лишь рекомендация

title если не ошибаюсь varchar 155 или 255 символов имеет

Точнее лимит стоит в базе

Ты же это для четверки делаешь?

да

И назвать раздел SEO, чтобы было понятно всему

Метаданные вполне нормально название. Можно дальше расширять и ни как не быть связанным с сэо

нету в instalation апдейтов никаких 🤷‍♂️

нету в instalation апдейтов никаких 🤷‍♂️

Пока нету

Точнее лимит стоит в базе

сейчас title вообще хранится внутри сериализованного массива в attribs

сейчас title вообще хранится внутри сериализованного массива в attribs

Для заголовка?

В блаузере

А metadescription в одних компонентах хранится как text, в других - varchar(1024)

Для заголовка?

да

Так норм.

Зачем колонку под это дело

А зачем под description?

Зачем под keywords?

Ну кейвордс ещё может быть. Ну а под описание ХЗ

Ну впринципе можно и под браузерный тайтл

Я тебе объясню, зачем удобно иметь title в отдельном поле базы! Я делаю большой сайт. Править всю сео-хню крайне неудобно в админке. Проще выгрузить всё это в файл, в excel'е построить title и description из словарей, собранных кейколлектором, по формулам и потом впулить это в базу

И вот с сериализованной строкой это делать - только через пых!

Ну это да

Что за кейколектор?

http://www.key-collector.ru/

И вот с сериализованной строкой это делать - только через пых!

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

Собирает ключевики из гугла и яндекса. Киллер-фича - парсер поисковых подсказок

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

Ну так вот для удобства работы с данными их, хорошо бы, писать в удобном виде

JSON тоже хороший вид хранения

Но то такое.

JSON тоже хороший вид хранения

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

Эм

))

В папке installation

Нашёл поиском!

Было круто если бы контент оптимизировали бы

Если нужно JSON, ну ок, если поля - прекрасно

А стопэ! json с 5.7 подвезли! А я чёт уверен был что с 8

А портануть CSV/JSON это дело десятое.

А стопэ! json с 5.7 подвезли! А я чёт уверен был что с 8

С 5.5, или 5.6

с 5.7.8

в 5.6 его точно нет

Не помню

Блин, может в этом и есть логика, но я её не понимаю! Почему таблица __tags - в base.sql __content, __contact_detail и __newsfeed - в components а __categories - в supports ???

Блин, объясните, в чём профит?

почему у одних varchar, у других text?

почему у одних varchar, у других text?

а есть разница?

почему у одних varchar, у других text?

Varchar можно добавить в индекс, text нет

Блин, может в этом и есть логика, но я её не понимаю! Почему таблица __tags - в base.sql __content, __contact_detail и __newsfeed - в components а __categories - в supports ???

Может быть потому, что есть ещё базы с демками?

В текущем варианте джумла 4 демок пока нету. Но они скорее всего будут, как в предыдущих версиях

Varchar можно добавить в индекс, text нет

вон оно как

@drekun @Septdir подскажите, куда в джумле нужно вносить sql-код, для конвертации поля при обновлнеии ядра? Мне для обеспечения перехода с 3х на 4х нужно сконвертировать поле в базе

Но я что-то не догоняю - куда это лучше написать

есть вот такое

Но я не догоняю, как эти sql исполнятся будут. В каком месте их вызвать нужно?

или достаточно в updates пхнуть?

наверное в updates, всё же...

Я посмотрел в других файлах - они использовали там insert into. Так что, думаю, перегон полей в базе будет уместен тут

блин. А j4 минимально mysql 5.6 поддерживает?

блин. А j4 минимально mysql 5.6 поддерживает?

Нет же, 7.2 мин

Нет же, 7.2 мин

MYSQL!

не PHP

наверное в updates, всё же...

Засунь куда нибудь, если будет не там то поправят

As per a Production Department decision, we would like to inform our users that we increased the minimum technical requirements for Joomla 4: PHP 7.2. MySQL 5.6 (Note: The minimum MySQL version can be subject to change during the lifetime of Joomla 4 if necessary) PostgreSQL 11.0. Minimum browser version set to n-2.

Засунь куда нибудь, если будет не там то поправят

Точнее попросят поправить

Я смотрю, что в базе j4 много где используется JSON encoded data Но поддержка json в mysql появилась только с 5.7.8 версии! + к этому 5.6 END OF LIFE объявлен февраль 2021 года. Какой смысл тогда min required держать mysql 5.6

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

Как бы их всех на шабаш вызвать?

@drekun подскажи, пожалуйста, как правильнее Update MySQL requirements for Joomla 4 или Upgrade MySQL requirements for Joomla 4

Кому хочется нативной поддержки mysql json в j!4, го раскачивать дедов https://github.com/joomla/joomla-cms/issues/29019

А что за таблица #__content_types в джумле? Я не совсем понимаю, для чего она используется

@drekun подскажи, пожалуйста, как правильнее Update MySQL requirements for Joomla 4 или Upgrade MySQL requirements for Joomla 4

Тебя поймут

А что за таблица #__content_types в джумле? Я не совсем понимаю, для чего она используется

В тегах точно, но я в неё никогда не лез