Вы не вошли.
Страницы 1
На данный момент движок находится в состоянии alpha3 (даже pre-alpha4 - репозиторий pe-stable содержит некоторые изменения сделанные уже после alpha3).
Глобальные шаги, которые уже выполнены:
Добавлен реестр (автозагрузка классов, инициализация ресурсов и еще некоторые функции) (спасибо R2D2)
Внутренний функционал (functions.php, parser, email и т.п.) переведен на классы, где это имело смысл.
HTML-разметка выделена в шаблоны с целью разделения логики и представления (MVC).
Добавлен kind (вид контента) как признак доски (форумы, статьи, блоги, галереи и т.д.).
Категории и Вид контента можно поменять местами "одним щелчком мыши" в админке. По сути это влияет лишь на навигацию - навигационное меню в шапке, хлебные крошки, отображение досок в index.php, и т.д.
Загрузка файлов.
Неглобальные шаги:
Добавлены новые BB-коды ([ spoiler], [ search], [ anchor], [ thumb], [ preview], [ file], [ off] и [ sh])
Здесь будут еще пункты...
Редактировался yoorick (29.11.2011, 14:30:36)
Ближайшие планы:
Добить рассылки и RSS/Atom подписки
HTTPS-доступ на сайт (есть поддержка со стороны движка, но нет принудительного переключения пользователей на безопасный протокол)
Обновить до FluxBB 1.4.7. (Далеко не все обновления нам нужны, нужно проанализировать, а не слепо обновляться)
Обновить часовые пояса для России
Убрать индивидуальные настройки количества тем и постов, оставить только глобальные в админке
Вернуться к теме ссылок на единичные посты (см. тут)
Добавить такие опции создания досок (которые были в PunBB-PE), как клонирование доски и задание имени доски при создании (а не после создания, как сейчас)
Создание пользователей из админки
Инвайты в случае закрытой регистрации
Дополнить ограничения загрузки файлов режимами "без ограничения" (а то смешно просто ограничивать админа 9999 файлами и давать возможность самому себе задать бонус) и "N файлов за промежуток времени" с выбором этого самого промежутка (день, неделя, может быть еще месяц)
Адаптировать поиск под PE.
Дружественные URL для файлов
Friendly URL глобально для всего движка
Расширить возможности шаблонизатора
Пометка тем прочитанными с хранением пометок в базе данных
Черновики
--
Старое сообщение:
Ближайшие планы:
- разделить логику и разметку в скриптах: Регистрация, Поиск, Список пользователей, Профиль, Админка.
- ссылки на единичные посты
вместо viewtopic.php?pid=6502#p6502 иметь что-то вроде viewtopic.php?id=3041#p6502. или вообще абстрагироваться от id, т.к. сообщение может перекочевать из топика в топик. когда буду делать, создам по этому поводу топик с обсуждением.
- добавление пользователей вручную
- прикрепление файлов
- разный внешний вид у суперкатегорий.
- личные сообщенияЕсли что еще вспомню, допишу.
Редактировался yoorick (07.02.2012, 15:44:41)
для ручного добавления пользователей есть же мод-плагин на punRes "User Management"
Предлагаю определиться с терминологией: ты пишешь "форумы/посты", а у нас разные типы "досок" (так их Александр называет), потому что там не только форумы но и блоги и галереи и статьи и т.п. Отмечать/инвертировать же можно не только темы форума, но и статьи.
Затем - парадигма сперкатегорий должна иметь возможность представляться как "вертикально" (как сейчас) суперкатегории это "столбцы": Доски - форумы, статьи, блоги, галереи. Так и "горизонтально" (от темы) - это когда, к примеру есть тематические разделы Авто, Hi-tech и др. и каждый такой раздел имеет в себе Новости(Блоги), форумы, галерею, Статьи. (Возможно там уже не нужно такое конкретное разделение, и это будут просто типы сообщений (например при создании сообщения можно будет выбрать его тип, а поместится оно уже в нужный тематический раздел (Авто, ...) и возможно их надо представлять единой лентой (тему форума рядом с новой фоткой из галереи, и между ними новость, и там же по порядку - статью. Т.е. возможно четкого разделения не должно быть, либо должна быть возможность это разделение скрыть (оно ведь итак будет в плане логики представления сообщения/поста).
Наверно можно сделать "галку" которая меняет тип представления суперкатегорий с вертикального на горизонтальный, и вторую - которая производит "смешение" (но можно будет вернуть разделение если снять галочку - в любой момент). И в поиске конечно эе разделение должно быть (опять же - можно выдавать единой лентой, а можно выдачу фильтровать по типам, что для многих удобнее)
И ещё такая фишка пришла: Возможно стоит при создании ТЕМЫ на сайте автоматически спрашивать - какие суперкатегории создавать под неё (или, в случае, когда они "скрыты" - просто создавать их автоматом (все типы сразу). А дальше - по сути их создавать и не надо. Суперкатегории уже созданы - это то , что определяет возможности при составлении сообщения на сайт. Его внешний вид, сложения (или наоборот файл в центре, а вкруг него - описание), то, в каком виде оно будет доставлено пользователю (личные сообщения - тоже по сути суперкатегория), И у нас изначально ест набор этих суперкатегорий. И не важно горизонтальны они или вертикальны - это конечный набор строк/столбцов (именно поэтому Александр изначально сделал их вертикальными. И когда мы создаём новое измерение (Категорию - в нынешнем движке, и Тему же в том, "горизонтальном" который я предлагаю) - мы пока вынуждены создавать несколько "досок" - т.е. я делаю категорию "Авто" вручную, сперва в форумах, потом её же - в статьях, потом её же в блогах, и её же в галереях. Очевидно что новый раздел должен появиться сразу везде - ведь нам вполне может понадобиться любое из представлений сообщения в рамках раздела "Авто". и мне не нравится что у одной доски Авто(форумы) будет id=78, у второй(блоги) id=43 и т.д.
Зачем раздробленность здесь?
Еще мне не нравится "Вертикальное" представление вообще: когда у меня на одной странице, скажем в Форумах (как сейчас) есть категории, которые вообще друг к другу не относятся (ну какое отношение скажем Железные проблемы имеют к Программной помощи?)
Я хотел бы именно "горизонтальное" деление - когда одна "доска" на сайте содержит все виды информации по одному направлению. И всё.
Таким образом "вертикальное" деление все же надо оставить как возможность, потому что могут быть моно-направленные проекты. где обсуждаются узко-тематические вещи, и там выгодно иметь деление на типы представления информации, а если зотя бы 2-3 раздела не связаны друг с другом (1С, php, железо - как у нас) - то выгоднее сразу становится делать горизонтальное деление).
таким образом я бы вообще убрал понятие категорий, или "перевернул" бы - суперкатегории сейчашние сделал бы категориями, а категории - превратил бы в вертикальное деление по тематическим разделам сайта.
И еще про регистрацию - она должна быть "постепенной" - т.е. если человек зарегистрировался в Авто-разделе, он получает оттуда новые темы (мод изменения с последнего посещения) но не получает, скажем из раздела hi-tech - т.к. в последнем разделе он ещё не зарегистрирован, если он туда попадет - он уже может там читать, но постить не может - он должен пройти до-регистрацию ((тут какраз можно смешать инвайты - для первого попадания на сайт и авто-регистрацию для попадания в следущий раздел). После до-регистрации он получает возможность полноценно общаться и в hi-tech-разделе, постить там, получать информацию о новых темах/статьях/картинках/новостях и т.п.
+ Менять тип суперкатегории: надо иметь инструмент чтобы переносить из обсуждения (на форуме) в статьи (когда оно оформлено. Например я Пишу статью про S60 - и там не добавил ещё тему про настройку wi-fi, мне на форуме пока оно сырое - задают вопрос про вай-фай, я добавляю это в статью, а комментарий остаётся, его потом читает новенький и не понимает зачем задан вопрос... На хабре например деления на статью и форум нет - там в комментах люди делают замечания, человек им там пишет что поправил и правит статью, всё понятно. Вобщем проблема то не в новичке, а в том чтобы было понятно как исторически сложилось такое обсуждение. на хабре оно решается ответом автора на комментарий. А вообще идея такая что когда статья оформляется из обсуждения, то в момент когда она уже сформировалась, комментарии из стадии оформления возможно следует отчудждать/удалять... тогда появятся другие, но они уже нового уровня- ведь статья и "сырой" становится "зрелой", что сразу же отсекает множество ненужных вопросов (ответы на которые уже есть в статье)
+ сироты. Файлы иногда участвуют сразу в нескольких статьях (иллюстрациями), поэтому важно при удалении статьи/поста понять а стоит ли удалять файл (например отделить структуру хранения файлов от постов, или установить зависимость так, чтобы файл становился сиротой только после удаления всех постов, к котороым он прикреплён). Либо -либо. Надо выбрать или дополнить одно другим.
+ нужна тогда уже карта файлов (в профиле и при создании поста - чтобы удобно добавлять уже залитые файлы, и чтобы смотреть файлы пользователя отдельно/по пользователю, а не по темам на которые эти файлы разбиты + конечно не забыть чтобы пользователь давал права на эти файлы разными).
по сути для добавления пользователя в движке всего должны быть такие вещи:
1) вручную - когда потенциальный юзер присылает по почте(заполняет форму) заявку и админ его добавляет
2) автоматическая регистрация в старом стиле: - когда потенциальный пользователь заполняет форму (нужна капча и проверка емайла) и получает аккаунт
3) инвайт - аналогично хабру - когда ктото из юзеров получает "за заслуги" один инвайт и выдает его по его мнению самому достойному
Личные сообщения должны быть как тема, которую могут читать только двое. Это очень круто, когда история хранится в виде чата
Прикрепление файлов - сформулировано немного не верно - т.е. мы говорим что файл может быть центральным объектом а не только аттрибутом поста. В таком случае пост для файла - аттрибут, и формат такого поста должен быть особенным (т.е. например это просто малюсенькая подпись-комментарий к фотке (которая вставляется в статью вместе с фоткой если мы решили эту фотку к статье добавить (выглядеть будет как "врезка" с фоткой и + пара слов - как комментарий к этой фотке или название фотки).
По поводу горизонтального деления и перемешивания тем разных суперкатегорий. Я думаю, что лучше будет дать пользователю выбор как ему самому смотреть. Допустим, что в админке стоит галочка разбивать категорию по суперкатегориям (пусть в этом сообщении пока будет такая терминология). Пользователь заходит на нужную ему категорию (пусть это будет Авто), при этом где-то на странице, может быть прямо под меню, есть ссылка "Отображать лентой". Он на нее нажимает и видит какое-то количество последних тем перемешанными - фотографии, статьи, блоговые сообщения... Естественно, если ему больше нравится вариант противоположный выбору админов (лента при суперкатегориях, суперкатегории при ленте), то нужна возможность задать это в профиле. Или даже ссылку, появляющуюся рядом с вышеупомянотой после смены вида, говорящую "Задать по-умолчанию".
По поводу файлов, я считаю, что файлы должны прикрепляться к пользователю, а не к сообщению. Единственный случай возникновения файлов-сирот в этом раскладе - удаление пользователя.
Еще думаю, что стоит ввести два разных тега - thumb и preview. Preview будет как раз тем вариантом, что мы обсуждали - более-менее крупная картинка (возможно на всю ширину сообщения), выровненная по центру, имеющая подпись и ссылку на обсуждение файла. По щелчку по картинке получаем полноразмерную оригинальную версию. Thumb - маленькая картинка, примерно как сейчас, только не квадратная, а пропорциональная. Нет ни подписи, ни ссылки на обсуждение. По щелчку все также открывается полноразмерный оригинал. Отображаются в том числе и по несколько на одну строку, но желательно как-то отделить от текста. В качестве примера использования вижу что-то типа "Дополнительные фотографии на тему" в конце статьи/блогосообщения или наподобие "приложил скриншоты на случай, _если_ понадобятся".
Для файлов-некартинок, думаю, неплохо было бы все-равно отображать картинку, только какую-нибудь маленькую (допустим 30x30) заложенную в движок/дизайн сайта, по нажатию на картинку начинается закачка файла. Аналогично, в случае preview, можно добавить подпись к файлу и ссылку на обсуждение.
Редактировался yoorick (08.06.2011, 01:12:58)
Страницы 1
[ Сгенерировано за 0.016 сек, 8 запросов выполнено - Использовано памяти: 1.95 MiB (Пик: 2.01 MiB) ]