Возможно стоит заняться документацией (какие вопросы стоит включить)?

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

Какие вопросы возникают при установке LibArea или позже?

7 Ответов

  1. Я только за! Базовые (основные вопросы) просто необходимы. По поводу установки и папки public это уже есть, что надо ещё?

    Сейчас установлю версию с GitHub и посмотрю ещё раз на начальную установку и содержание всего.

    P.S. Этот вопрос поднят.

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

      1. Полное описание всех config файлов. Трудно сразу найти нужный файл и строку.
      2. Описание изменений и обновление для каждых новых релизов.
      3. Как вносить изменения в код, чтобы не было проблем с обновлениями.
      4. Информацию об авторе.
      5. Как добавлять разные блоки на сайт, чтобы размещать рекламные блоки, текстовую информацию и т.д. Всем этим не трудно и самому разобраться, но при обновлении настройки будут слетать.
      6. Все известные ошибки.
      7. Планы по разработке.
      8. Как добавлять новые кнопки в текстовый редактор? Если все добавлять по документации EasyMDE в файле buttons.php, то кнопки будут без символа-иконки.
  1. Большой список, скину вам лучше в чате.

    1. Мне кажется смысл сообщества как раз таки в другом.

  1. В состоянии на данный момент любой, имеющий базовые понятия о клонировании проекта с github, настройке конфигов и импорте дампа базы данных в свою базу — без проблем установит движок. Установить нужные права для файлов и папок и 777 для папок storage и uploads и все. Мне вот интересно когда изменяется база данных… миграций пока нет… Конечно можно отследить изменения в базе и выполнить какие-то запросы и обновиться, но хочется вообще обновлять проект нажатием одной кнопки из админки. Ну это мои хотелки, а в целом дело движется хорошо, главное чтобы Evg не сгорел в этих бесконечных обновлениях и улучшениях:) Документация нужна… я например впервые узнал что-то про политику безопасности, которая реализована в HLEB, которой не видел в других проектах… да и много чего еще. Главное чтобы на написание этой документации не уходило масса времени… Написать один раз и потом изредка добавлять что-то.

  1. Для меня это основные вопросы — по шаблонам. Как безболезненно вносить свои изменения и делать свой дизайн? Вопросы про Frontend.

  1. За эти дни получил много вопросов. Основное, работа с «пользовательской стороной», с Frontend, чтобы можно было максимально вольно делать что-то своё. Хорошо. Делаю релиз, раз ошибок нет и в следующей версии давайте именно поработаем над этим.

    • Упростим шаблоны
    • Введем вспомогательные функции (простые), чтобы можно было легко, например, добавлять свой конфиг и вызывать это дело в шаблоне приблизительно так:
    <?= config('facets.page); ?>

    Где, до первой точки — имя файла в папке config, а далее ключ (название) массива.

    • Создадим страницу в документации, где опишем эти функции:
    config('конфиг')
    url('url')
    __('перевод')

    и некоторые другие.

    Далее. Создам ещё один шаблон чтобы проверить переопределение основного шаблона. И посмотрим разные задачи. Например:

    • Хочу добавить совсем другую шапку
    • Или, хочу добавить или полностью заменить sidebar
    • И т.д.

    Чтобы вообще не трогать и таскать основные файлы шаблона из папки default.

    В самих шаблонах упростить конструкции, где возможно убрать передаваемые переменные в массиве, как сейчас:

    <?= Tpl::insert('/footer', ['user' => $user]); ?>

    Если нам не нужны добавлять туда свои переменные, то конструкции могут быть предельно простыми:

    <?= Tpl::insert('/footer'); ?>

    И всё это задокументировать. С Front-end разобраться, от этого зависит максимальная гибкость во многом. А сделав это, можно идти и на backend, более глубже.