WebMan

В InstantCMS2 2..4.0 нет уникальных логинов и проверки уникальности никнеймов. Поэтому стандартными средствами задачу не решить.

У меня уже готов вариант добавления логинов в Двойку. Постараюсь завтра выложить его в свой блог для тестирования. Если вы его потестируете, он вам понравится и будут выявлены и исправлены ошибки, разработчики CMS подумают, как включить его в "коробку".

MariaDB — это ответвление от MySQL. Фактически это уже два разных сервера баз данных. Видимо, их синтаксисы теперь не полностью совпадают. Кроме того, в MariaDB не поддерживается тип БД InnoDB.

Самое правильное решение: поставить MySQL или попросить это сделать Ваших админов. Если сервер MySQL уже установлен, то при инсталляции InstantCMS 2 Вам нужно указать параметры подключения к нему (адрес или имя хоста, может быть порт).

Как вариант, если нет возможности поставить MySQL или очень хочется поэкспериментировать, можно создать пустую базу в MariaDB в формате MyISAM и при установке InstantCMS 2 указать её. Но даже если заработает, всё равно правильней и надёжней будет решение с MySQL.
(Я с MariaDB не работал и всё вышесказанное про эксперимент с ней — это мои предположения)

Man, почитайте отличную статью r2 Тайна “белого экрана”. Выполните всё, что там сказано. Если нужны будут ответы от сообщества, выложите сюда тексты сообщений об ошибке.

Посмотрите ошибки в логах Апача. Если сами не поймёте о чём они, выложите их сюда, кто-нибудь поможет.

а он то и не работает. Кто подскажет, что не так?

На данный момент "не так" — Ваше описание ситуации. Его не хватит для ответа.

Полностью по шагам опишите Ваши действия при установке. Какие сообщения об ошибках при этом пишет установщик? Что происходит после удаления папки Install и обновлении страницы, что на ней написано? Какие ошибки в логах Апача?
На более конкретный вопрос Вам смогут дать более точный конкретный ответ.

Сразу скажу, что Вы, Akziaplus, правы в том, что разработчики должны выполнять те условия поддержки, которые сами заявили. Я, например, перед покупкой компонента сразу задаю разработчику вопрос о поддержке. И сохраняю их ответы себе на комп, чтобы я точно помнил условия сделки. Если мне нужны нестандартные условия, я их оговариваю тоже сразу. Как минимум, задаю основные вопросы. У кого покупал — те это знают. И, естественно, я ожидаю о людей выполнения этих оговоренных обязательств. Но никаких других. Хотя люди бывают разными и форсмажоры тоже заранее предвидеть невозможно.

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

О качестве — ответ требовательному пользователю InstantCMS 😊

mysql strict mode отключите и все заработает.

Это полезный режим, зачем его отключать. 😊
Насколько я помню, в одном из предыдущих обновлений эта проблема была решена на тот момент для всех таблиц/компонентов. Я ещё тогда благодарил r2 за эти исправления. Видимо сейчас забыли что-то учесть в новых функциях или изменениях 2.4.0.

Неужели никому это не нужно?

Мне это приложение интересно и, возможно, нужно. На будущее. А для начала нужно вывести сайт на достаточную посещаемость, чтобы приложением заинтересовались пользователи. Так что присоединяюсь к ТС: кто уже пробовал, отзовитесь!

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

Согласен. Причём это вполне можно сделать в "Менеджере картинок", если выбирать картинки из БД по id пользователя. Оттуда же можно брать их "нормальные" названия.

Как вы это представляете? В icms2 все льется без разбора в папку пользователя (а там еще куча папок).

Может тогда разработчикам движка или сторонним разработчикам такого компонента есть смысл пересмотреть эту "кучу без разбора" в сторону бОльшего упорядочивания? Например по id пользователей. Или с группировкой в корневые папки по первым цифрам. Никто же не говорит, что "куча" — это единственный возможный вариант.

В конце-концов, можно ничего не менять в способе хранении картинок, а в менеджере выводить лишь картинки данного пользователя, выбирая их по id пользователя из базы данных.

Вариантов хватает. Было бы желание и возможность у кого-то это сделать...

Мне, например, идея управления картинками нравится. Она может быть использована на сайтах разного типа. Например, на корпоративных сайтах или сайтах фирм совсем не нужно давать админские права девочке-оператору. Заложить такой девочке-админу в голову понимание, куда не следует лазить и что нельзя делать — сложно и всё равно проблемно. А вот объяснить ей, что "у тебя уже вот тут есть лого и фирменные картинки" и использовать их нужно оттуда, а не заливать каждый раз — легко и не проблема.
Или на обычных сайтах пользователи смогут использовать одни и те же картинки для одинакового оформления своих материалов.

Аналогичную проблему с загрузкой изображений обнаружил в другом месте.
Оригинальная 2.4.0 с демо-данными без каких-либо изменений. Захожу под админом в фотоальбомы, открываю "Красота окружающей природы" и нажимаю "Загрузить фотографии". Далее нажимаю "Выбрать и загрузить". После выбора файла картинки секунду крутится анимация загрузки, пропадает и больше ничего не происходит, картинка не добавляется.

Запрос icms240orig/photos/upload?qqfile=book.png возвращает 503-й код и описание ошибки:

В логах Апача такая ошибка:

'users/1' => 'admininistrator',

И не получится. Нужно менять обработку id на обработку логина внутри ядра. Плюс ещё много сопутствующих изменений.

Не Вы первый поднимаете эту тему, многим тоже нужны логины в адресах и для авторизации. У меня сейчас аналогичная задача для моего сайта, запустить я его могу только при наличии логинов. В принципе, рабочий способ мы с Fuze уже нашли. Я его реализовал, потестировал на локалке — работает. Но всё делается хаками системных файлов, компонетом тут не сделаешь. Поэтому выкладывать готовые изменённые файлы я пока не хочу. Жду ответ от r2.

Если он согласится добавить опциональные логины в ближайшее обновление Двойки, тогда получим универсальную систему, с возможностью работать или по id, или по логинам (в зависимости от настроек в Админке). Также опционально будет выполняться запрос логина при регистрации, проверка логинов на уникальность, управление ими в Админке, опциональный вход по логину вместо почты и подстановка логинов не только в адресах компонента "Пользователи" (адреса вида site.ru/users/vasya), а и в шаблонах адресов в типах материалов (site.ru/blogs/vasya, site.ru/ваш_тип_материала/vasya/statia.html или site.ru/albums/vasya-fotos-20160201.html). Плюс к этому появится возможность добавления многих вкусных плюшек с использованием логинов в дальнейшем. Например, персональное обращение по логину в комментариях с уведомлением, вывод логинов вместо никнеймов для уникализации пользователей и др. В этом случае будем ждать ближайшее обновление.

Если добро не получу, то с разрешения разработчиков выложу в блог технологию добавления логинов на страх и риск вебмастеров — где, что и как менять в ядре с пояснениями. Это будет не универсальный вариант. Вы сами сможете менять только те части системных файлов, которые вам будут нужны в ваших проектах. Но это лучше, чем ничего.

Всё-таки надеюсь на включение логинов в стандартный функционал. 😊

Предустановленные значения:
0 | Пол не указан
1 | Мужской
2 | Женский

Есть и обратная сторона — взгляд покупателя. Я, например, стараюсь покупать разработки только с открытым кодом. Взял всего одну с защитой, потому, что пока не захотел тратить время на свою такую же разработку. И больше закрытые покупать не планирую в ближайшее время. Логика тут проста:
1. Открытый код чаще всего разрешает использовать купленный компонент на любом количестве своих сайтов. Или на нескольких, но не одном.
2. Разработчик может по разным причинам исчезнуть. На время или насовсем. В закрытом компоненте исправить ошибки или сделать доработки будет труднее.
3. Иногда нужно оперативно что-то подправить. Не всегда разработчик на связи и не всегда захочет реализовывать твои хотелки.
4. Безопасность. При всём моём уважении и достаточном доверии к некоторым разработчикам на этом сайте, я не могу быть на 100% уверен в том, что заложено в закодированной части скрипта.
5. Установка дополнительного модуля ioncube на веб-сервер — это тоже не плюс ни по каким критериям.

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

Как вариант, рекомендую подумать не столько о защите, которую действительно можно сломать, а о том, чтобы некоторым покупателям с высоким доверием с вашей стороны, продавать (по их желанию) компонент в исходниках. Может быть за небольшую доплату, если "жаба давит". 😊