Вот читаю комменты и замечаю, что многие не понимают, в чем проблема. Проблема не в повышении тарифа, не в том что списание ежедневное. А в том что все это написано где-то там у нас на сайте / в договоре.
Честно это уже поднадоело. Пишите нормально. Прямо рядом с кнопкой оплатить, все четко и подробно. - Тарификация ежедневная столько-то в день - В случае изменения условий сумма может меняться - Для активации тарифа требуется чтобы на балансе была такая-то сумма. - Хотите пополнить баланса (вот вам несколько вариантов). И не красивых словах, а в днях, тарификация то ежедневная. -- Полонить на A (~30 дней) -- Пополнить на B (~90 дней) -- Пополнить на C (~365 дней)
В свое время когда РКН блокировал Amazon русскоговорящее сообщество Joomla сделали два решения. 1. Добавили зеркала в сервера обновлений, и надо выяснять почему сейчас они не работают хоть и указы. 2. Не официальный сервер обновлений, который автоматом тянет все необходимое с github https://joomla-update.org/
Интересное изыскание, однако по сути бессмысленное. Для того чтобы разобраться надо погрузиться в историю. Переход на namespaces начался еще в 2017.
Глобальные алисасы были добавлены тогда же в качестве legasy для упрощения обновления расширений для Joomla 4.
\Joomla\CMS\Language\Text был одним из первых доступных для использования. Так что уже лет 5 в основном используется именно он.
Сама же так же Joomla 4 является переходной версией, по заверению разработчиков в Joomla 5 Legasy, который тянется уже ни одну мажорную версию будет наконец убран.
Все довольно просто. Если тебе предлагают выбор на какой CMS что-то писать, то выбор падет либо на Joomla либо на October, писать что-то на WP — это как гнуть стальной прут голыми руками. Это не делает одну CMS лучше другой, просто для каждой задачи есть свой инструмент.
Что же до чистки от вирусов. Тут верно заметили дело в варезе и а не в дырах (чтобы это понять не надо быть семи пядей во лубу). Почему этого меньше на WP потому, что там гора бесплатных плагинов и тем. У Joomla же почти все платное, а любовь людей к халяве ни что не вылечит. Бывало только сайт приведут в порядок, через месяц уже опять ставят варез и по новой.
Что же до «дыр» то не уязвимых систем не бывает, но по их количеству и по кол-ву критический WP уже давно всех обогнал и в этом тоже нет ничего страшного. Дуры нашли, дыру закрыли и всех предупредили.
P.S ИМХО довольно глупо спорить о «крутости» чего ли либо в простой подборке новостей.
Ну он на самом все останется, просто не придется брать бубен и входить в транс, чтобы его выпилить. достаточно будет просто сделать свой шаблон. Или использовать готовый без лишнего.
На самом деле, про смену роадмапа версий немного не точно.
Из-за 3.9 релизы действительно сдвинусь. Но сдвиг планировался такой.
3.9 > 3.10
3.10 > 3.11
А тут снова семь пятниц на неделе.
3.11 убирали и слили с 3.10. Кроме того еще и стагнацию всей третей ветки сделали.
Кроме того ИМХО сомнительно что за оставшиеся время 4.0 приведут божеский вид.
Вы бы внимательней читали, что выше написано. Я два раза, вроде, упомянул, что не было никаких миграций, всё «с нуля». Это раз
В Joomla 3 префикс базы данных jos_ бывает 2-х случаях.
Миграция с Joomla 1.5 (уже в 2.5 были другие префиксы, а в Joomla 3 )
Прописывание его руками (мало вероятно, ибо если и пишут руками то префикс зачастую делают похожим на название сайта.) Совпадение? не думаю
конкретно вот по этому модулю популярных статей — с версии 3.6.5 до версии 3.8.7 кардинально изменились
Чтобы это понять достаточно просто перейти по ссылкам на PR и Commit которые я дал выше. Или вы код читать не умеете?
Теперь дальше, конечно у вас проблемы с таблицей com_content есть, причин может быть много, начиная от кривой миграции, настроек сервера, до просто неудачно созданной бд, Ну и сама таблица не особо удачная для больших объемов. Однако к описанной вами проблеме это отношение не имеет, в противном случае такой разницы быть не должно.
Если у вас такая разница при включение\отключении ACL то и причину нужно искать в нем. Если быть точнее в получении уровней доступа конкретного пользователя. А именно с получением вот этих значений a.access IN (1,1,2,3,6). Значения 1,1,2,3,6 берутся из таблицы '#__viewlevels' в данной функции Делается это единожды. Видно в отладке.
Есть конечно дубль запроса #_usergroup но это к данному посту тоже отношения не имеет.
Все это можно проверить посмотрев в отладку (возможно идут повторные запросы либо еще какие косяки с этим, хотя по сути это должно влиять на весь сайт) либо в ручную прописать access в запросе и посмотреть на разницу.
Да и вообще, стоит посмотреть на сам сайт что там понаставлено и выложено, может вы вообще поставили варезный quick_start какого нибудь шаблона, где чего только не понапихано.
Вот я для себя и исправляю.
А могли бы для других. Joomla это OpenSorce и там всегда рады энтузиастам помогающим с оптимизацией и развитием. Ссылка на репозиторий.
Другим ничего не впариваю.
Ну как же не впариваюете, впариваете про то что нашли панацею. Как решить проблему с "Производительность Joomla на больших объемах контента"
Хотя решается она совсем по другому. Да и по сути если проблема и есть, то в большинстве случаев, как собственно и любая оптимизация, она уникальна для каждого сайта.
Кстати запрос который делает данный модуль, да и com_conent сейчас другой, да и саму базу подправляли.
Не сказал бы что мне нравиться и этот запрос. Но это уже лучше было (сам com_contnet пользуюсь только в маленьком личном блоге в котором < 100 итемов)
Дискутировать дальше смысла не вижу, не по причине отношения к движку, а скорее по причине того, что обсуждать не актуальную версию ядра нет ни какого смысла.
Так что начать стоит с обновления ядра. А потом уже строчить пост на habr, а то писать и делать выводы, предлагать решения (возможно и правильные и интересные) вовлекая в дискуссию других людей, с версией ядра от 13 декабря 2016 года (~ 1,5 года назад) не очень то корректно учитывая количество обновлений и их объем.
Кроме того. Когда проводятся любые тестирования. Указываются все сведения. А то сейчас выясним что у вас 64mb рамы, php 5.2, msql 5.1 и древний apache. Это так от балды для примера.
P.S Я еще раз повторюсь разработчикам работающим с Joomla ничего доказывать не надо, они знают о всех проблемах не хуже вас. Да и ни кто их и не скрывает, не так много людей в данной сфере которые будут что-то защищать только из-за любви.
Причем корень всех проблем один, ну а какой это уже совсем другая тема.
Вот читаю комменты и замечаю, что многие не понимают, в чем проблема.
Проблема не в повышении тарифа, не в том что списание ежедневное. А в том что все это написано где-то там у нас на сайте / в договоре.
Честно это уже поднадоело. Пишите нормально. Прямо рядом с кнопкой оплатить, все четко и подробно.
- Тарификация ежедневная столько-то в день
- В случае изменения условий сумма может меняться
- Для активации тарифа требуется чтобы на балансе была такая-то сумма.
- Хотите пополнить баланса (вот вам несколько вариантов). И не красивых словах, а в днях, тарификация то ежедневная.
-- Полонить на A (~30 дней)
-- Пополнить на B (~90 дней)
-- Пополнить на C (~365 дней)
В свое время когда РКН блокировал Amazon русскоговорящее сообщество Joomla сделали два решения.
1. Добавили зеркала в сервера обновлений, и надо выяснять почему сейчас они не работают хоть и указы.
2. Не официальный сервер обновлений, который автоматом тянет все необходимое с github
https://joomla-update.org/
Надо вскрывать обновление и смотреть почему не работают зеркала, которые делали именно из-за блокировки Amazon пару лет назад.
Время пишется там в том случае если письмо недавнее.
В противном случае там пишется год.
Во всяком случае у меня так gmail это выводит.
Да и к чему было замазывать название организации тоже не понятно.
Ну да ладно просто поинтересовался.
Прошу прощения, ни то чтобы я не верил, но зачем на письме год замазан?
Интересное изыскание, однако по сути бессмысленное. Для того чтобы разобраться надо погрузиться в историю. Переход на namespaces начался еще в 2017.
Глобальные алисасы были добавлены тогда же в качестве legasy для упрощения обновления расширений для Joomla 4.
\Joomla\CMS\Language\Textбыл одним из первых доступных для использования. Так что уже лет 5 в основном используется именно он.Сама же так же Joomla 4 является переходной версией, по заверению разработчиков в Joomla 5 Legasy, который тянется уже ни одну мажорную версию будет наконец убран.
Мне друпал перестал нравиться версии с 5.
Что же до чистки от вирусов. Тут верно заметили дело в варезе и а не в дырах (чтобы это понять не надо быть семи пядей во лубу). Почему этого меньше на WP потому, что там гора бесплатных плагинов и тем. У Joomla же почти все платное, а любовь людей к халяве ни что не вылечит. Бывало только сайт приведут в порядок, через месяц уже опять ставят варез и по новой.
Что же до «дыр» то не уязвимых систем не бывает, но по их количеству и по кол-ву критический WP уже давно всех обогнал и в этом тоже нет ничего страшного. Дуры нашли, дыру закрыли и всех предупредили.
P.S ИМХО довольно глупо спорить о «крутости» чего ли либо в простой подборке новостей.
Тут от Joomla ничего зависит. Такая болезнь у любого «кода» он либо написан нормально, либо будет неделю проклинать себя за то что вообще взялся.
Из-за 3.9 релизы действительно сдвинусь. Но сдвиг планировался такой.
3.9 > 3.10
3.10 > 3.11
А тут снова семь пятниц на неделе.
3.11 убирали и слили с 3.10. Кроме того еще и стагнацию всей третей ветки сделали.
Кроме того ИМХО сомнительно что за оставшиеся время 4.0 приведут божеский вид.
Его еще год назад убрали.
Да и вообще много чего за 1,5 года изменилось в ядре
В Joomla 3 префикс базы данных
jos_бывает 2-х случаях.Совпадение? не думаю
Чтобы это понять достаточно просто перейти по ссылкам на PR и Commit которые я дал выше. Или вы код читать не умеете?
Теперь дальше, конечно у вас проблемы с таблицей com_content есть, причин может быть много, начиная от кривой миграции, настроек сервера, до просто неудачно созданной бд, Ну и сама таблица не особо удачная для больших объемов. Однако к описанной вами проблеме это отношение не имеет, в противном случае такой разницы быть не должно.
Если у вас такая разница при включение\отключении ACL то и причину нужно искать в нем. Если быть точнее в получении уровней доступа конкретного пользователя. А именно с получением вот этих значений
a.access IN (1,1,2,3,6). Значения1,1,2,3,6берутся из таблицы '#__viewlevels' в данной функции Делается это единожды. Видно в отладке.Есть конечно дубль запроса
#_usergroupно это к данному посту тоже отношения не имеет.Все это можно проверить посмотрев в отладку (возможно идут повторные запросы либо еще какие косяки с этим, хотя по сути это должно влиять на весь сайт) либо в ручную прописать access в запросе и посмотреть на разницу.
Да и вообще, стоит посмотреть на сам сайт что там понаставлено и выложено, может вы вообще поставили варезный quick_start какого нибудь шаблона, где чего только не понапихано.
А могли бы для других. Joomla это OpenSorce и там всегда рады энтузиастам помогающим с оптимизацией и развитием. Ссылка на репозиторий.
Ну как же не впариваюете, впариваете про то что нашли панацею. Как решить проблему с "Производительность Joomla на больших объемах контента"
Хотя решается она совсем по другому. Да и по сути если проблема и есть, то в большинстве случаев, как собственно и любая оптимизация, она уникальна для каждого сайта.
Кстати запрос который делает данный модуль, да и com_conent сейчас другой, да и саму базу подправляли.
Не сказал бы что мне нравиться и этот запрос. Но это уже лучше было (сам com_contnet пользуюсь только в маленьком личном блоге в котором < 100 итемов)
Дискутировать дальше смысла не вижу, не по причине отношения к движку, а скорее по причине того, что обсуждать не актуальную версию ядра нет ни какого смысла.
Так что начать стоит с обновления ядра. А потом уже строчить пост на habr, а то писать и делать выводы, предлагать решения (возможно и правильные и интересные) вовлекая в дискуссию других людей, с версией ядра от 13 декабря 2016 года (~ 1,5 года назад) не очень то корректно учитывая количество обновлений и их объем.
Кроме того. Когда проводятся любые тестирования. Указываются все сведения. А то сейчас выясним что у вас 64mb рамы, php 5.2, msql 5.1 и древний apache. Это так от балды для примера.
P.S Я еще раз повторюсь разработчикам работающим с Joomla ничего доказывать не надо, они знают о всех проблемах не хуже вас. Да и ни кто их и не скрывает, не так много людей в данной сфере которые будут что-то защищать только из-за любви.
Причем корень всех проблем один, ну а какой это уже совсем другая тема.
Кстати будете обновляться не забудьте воспользоваться функцие исправление БД ибо в структуре тоже были исправления