DEV: Задача — полностью переписать «админку» (+ настройки)

На самом деле, например, настройки не касаются только админки и внешнего вида. Необходимо сделать удобное управление настройками сайта и хранить их в базе.

Общий механизм по поводу настроек:

Храним настройки в сериализованом виде: как только сайт открывается, он проверяет наличие файла (например: settings.txt), если файл найден — читаем его и делаем unserialize — на выходе получаем массив настроек.

Если файла нет — делаете запрос в базу и затем полученный массив настроек сохраняем в файл (settings.txt) через serialize функцию + при каждом изменении настроек — удаляем файл settings.txt и он будет снова синхронизирован с БД.

Разделы

  • Брендинг / branding
  • Основное / basic
  • Учётные записи / accounts
  • Пользователи / users
  • Сообщения / messages
  • Эл. почта / email
  • Файлы / files
  • Уровни доверия / trust
  • Безопасность / security
  • Умная вставка / onebox
  • Спам / spam
  • Ограничения / rate_limits
  • Разработчикам / developer
  • Юридическое / legal
  • Резервные копии / backups
  • Поиск / search
  • РАЗНОЕ / uncategorized
  • Пользовательские настройки / user_preferences
  • API / api
  • Фасеты / facets
  • Модули / modules

Например, ограничения взять:


Пользователи могут создавать новый пост после создания предыдущей только по прошествии указанного здесь количества секунд.

Пользователи могут отвечать после создания предыдущего только по прошествии указанного здесь количества секунд.

Новички могут создавать новый пост после создания предыдущей только по прошествии указанного здесь количества секунд.

Новички могут отвечать после создания предыдущего только по прошествии указанного здесь количества секунд.

Максимальное количество постов, которое пользователь может создать за один день.

Максимальное количество новых личных сообщений, которые пользователь может создать за день.

Максимальное количество симпатий, которое пользователь может выразить за один день.

Максимальное количество закладок, которое пользователь может создать за один день.

Максимальное количество жалоб, которое пользователь может подать за один день.

Максимальное количество редактирований, которое пользователь может выполнить за один день.

Максимальное количество приглашений, которое пользователь может отправить за один день.

Максимальное количество приглашений в тему, которое может отправить пользователь за один день.

Максимальное количество тем, которое пользователь может создать в течение 24 часов с момента создания своего первого сообщения

Максимальное количество ответов, которое пользователь может сделать в течение 24 часов с момента создания своего первого сообщения

Увеличить лимит симпатий в день для уровня доверия 2 (участник), умножив его на указанное здесь число

Увеличить лимит симпатий в день для уровня доверия 3 (активный пользователь), умножив его на указанное здесь число


И т.д. тут много всего. А вообще, сегодня займусь изучением, как это сделать лучше. Выше предложен один из вариантов.

Такие планы…

Вариант:

Админка

В Discourse:

В Discourse

8 Ответов

  1. Такие планы,.. Это грандиозные планы! Если сделать это всё хорошо, то получится действительно серьезная система управления сообществом. А хотели проще. )

    1. Это максимально просто, т.к. у нас мало «целей» с чем предстоит работать (темы, ответы, комменты, каталог, рейтинг, профиль, pm, закладки — почти это всё). Базовый функционал, но он должен быть гибким и достаточно глубоким.

  1. С базой начинаем более плотно работать, это хорошо. Собственно база и предназначена что-то хранить. Миграции не хватает хорошей.

    1. Тут много чего не хватает, надо делать.

  1. Только сейчас заметил. Вы хотите чтобы была возможность менять и ключ? Работа с базой через пользовательский интерфейс (даже под администратором) возможно стоит ограничить? Смена ключа подразумевает замену его и в других местах.

    1. Наверное да, спасибо. Да так и проще будет. + Хотя, может быть не буду делать, это не совсем то, что надо. А почти всё сделал. ) Ну ничего, познакомился как в laravel идет работа, как используются все же файлы конфига хотя бы для отката и дефолтных настроек и т.д. Интересно. Но тут не думаю, что оправдано. А значит, надо убирать до лучших времен и формирование в админке меню. Таблицу и файлы. Однообразно должно быть. А то разницы много. Лучше время потрачу на организацию того, что уже есть. И делать надо ещё новое, необходимое.

  1. Мы должны идти по пути упрощение админ-панели. Показ, управления всеми видами контента должно быть убрано и перенесено во фронт. Админ-панель должна служить для настроек сайта. В свете этого, добавленные ранее конструктор меню был убран, отображение разделов упрощено. Таблица, контроллеры и методы связанные с навигацией удалены.

    Это было написал на GitHub.

    Действительно, черт дернул, но изучил хорошо (думаю) всё это дело, то, как делают сегодня. И еще, сколько раз убеждаюсь, что следовать за другими у многих (у меня) в крови. Стадные животные, тут нечего сказать. А следуя, можно повторить, можно улучшить, хорошо если и изучить.

    Мы не будем улучшать дизайн и общий подход к созданию админок и ковыряться в этом. Не надо делать «лучше», надо сделать это по другому.

    На данный момент есть 2 крайности, с одной стороны перегруженность админ-панели и попытка ещё сюда наложить дизайн с фронта (чтобы было красиво). А с другой стороны, аскетический дизайн в стили администрирования Dmoz, LinksSQL и подобных программ, так, как мы делали интерфейсы используя Perl и местами даже C++ (где html был прям в коде) 20 лет назад.

    На самом деле, простой дизайн не исключает «красоты» и он может быть чертовски функциональный, что и предстоит сделать.

    P.S. Вы можете удалить таблицу navigation из базы данных если, заменили файлы. Не забываем делать бэкап сайта (базы и файлов) перед любыми изменениями.

    1. Вот это интересно. Всё что связано с UX в навигации с удовольствием смотрю. Много пунктов для управления есть, сложно упростить их.