id: Гость   вход   регистрация
текущее время 00:27 29/03/2024
Владелец: SATtva (создано 14/09/2006 22:50), редакция от 27/08/2014 10:40 (автор: SATtva) Печать
Категории: софт, сайт проекта, ошибки и баги, разное, сообщество
создать
просмотр
редакции
ссылки

Движок openSpace: разработка и доработка


Пожелания и предложения по развитию программной платформы openSpace следует публиковать в параграф Идеи (если она будет принята в план разработки, то её перенесут в параграф Сделать).
Убедительная просьба вносить сообщения обо всех обнаруженных ошибках в работе сайта, багах и недоработках непосредственно в текст страницы (параграф Исправить), но не в комментарии документа!
Основой платформы сайта служит движок openSpace, представляющий собой сильно модифицированную wiki-систему WackoWiki. Выбор пал на нее из-за простоты устройства, модульности, позволяющей легко изменять систему и подгонять под специфические нужды, наконец, субъективная характеристика — код написан на PHP, и для хранения данных используется БД, а не файловая система.


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

Сделать


  • Элементы страницы для работы с сетью доверия
  • Компонент динамического управления рабочими группами
  • Компонент администрирования пользовательских профилей
  • Дополнительный флаг для прав доступа: изменение свойств и правка документа должны быть подтверждены подписью PGP
  • Усиление защиты аккаунтов:
    • привязка (salt) в пользовательских паролях (защиты от тривиальных и идентичных паролей, rainbow-атак)
    • хранить в базе данных H(H(pwd)), в cookie — H(pwd) (защита при компрометации БД), снимаю шляпу перед Стивом Мёрдоком

Переход к бета-стадии (v0.9b)

  • Инсталлятор
  • Права доступа на участие в опросах (и просмотр определённых опросов?). Также указывать ID опросов для упрощения ссылок на них. Возможность комментирования опросов. (Перенести опросы в адресное поле документов, но использовать специфический хэндлер?)
  • Соответствие XHTML 1.0 Transitional
  • Универсальная (многоязычная) адресация страниц. Требуется: 1) заглавная страница для каждого языка, 2) уникальный ключ на поля { lang, tag(?), supertag }.
  • Вывод страниц в кодировке UTF-8
  • Полный рефакторинг кода:
    • хэндлеры, действия и административные модули переписать в классы вместо inline-php
    • вынести lang-strings действий и хэндлеров в самостоятельные динамически подгружаемые lang-файлы

Исправить


    • Поправка: более детальное тестирование показало, что в определённых случаях проблема сохранилась. Однако, стало возможным отключение части функций типографики (в частности, обработки кавычек) без ущерба для остальной функциональности. Окончательное решение пока не найдено.
  • Несколько подряд вызываемых редакций одного и того же комментария имеют один и тот же урл, что приводит к невозможности редактировать несколько раз подряд один и тот же комментарий в браузерах с активным использованием хэша (links, elinks и другие).
    • Примечание: в связи с технической сложностью и нехваткой времени решение этой проблемы отложено на будущее.
  • При использовании BBCode-разметки если использовать цитирование в списке, сообщение выводится некорректно (большая часть не выводится вообще), не говоря уже о корректном форматировании.
    • Обход: использовать только wiki-разметку в указанном случае.
  • Нет связи с главным ключём при подписывании материалов, т.е. при смене подключа для подписи выдаёт: "неопределенная ЭЦП ключом 0x12345678, не зарегистрированным на сайте". Чтобы избежать такой ошибки, нужно либо вручную обновить ключ на сайте (удалить и загрузить по-новой), либо отправить на сервер ключей и дождаться, пока сайт в плановом порядке обновит его сам.
  • В броузере Opera не отображается панель Wiki разметки, что делает неудобным оформление постов. Прошу обязательно исправить.
    • Код панели разметки несовместим с Оперой. Он целиком заимствован из WackoWiki. Если разработчики решат его исправить, исправление будет принято и в oS. Либо исправьте сами и пришлите патч.
  • Поиск: если в поле "Автор" указать "Гость", то поиск не срабатывает. Контрпример: поиск слов "pgpru" или pgpru* возвращает "Результатов не найдено", хотя есть (один из примеров) /comment43978.
  • При вставке ссылки, содержащей кириллические символы, копированием из firefox (например, из русской википедии), бьётся кодировка, и ссылка становится нерабочей (сайт не делает преобразование "URL-encoded → UTF-8").
    • Обходной путь: перенабирать кириллические символы в ссылках руками при вставке в вики-документы.

Идеи


  • Возможность загрузить в профиль электронную визитку (vCard ver. 3.0) и её подпись.
  • Автоматическое получение метки времени на каждую редакцию документа.
  • Замена RSS 2.0 на Atom 1.0 (RFC 4287), как на свободный и более современный формат.
  • Добавить тэг [offtopic] (можно сокращённо [off]), чтоб по умолчанию (без клика) показывал бы только одну строку, в начале которой он стоит, а по клику веcь блок до закрывающего тега [/off]. Или даже сделать тег [subtopic имя_подтемы], при клике на котором будут раскрыты все субтопики с этой подтемой.
  • Было бы не плохо сделать древовидными комментарии: ответ на комментарий дается под конкретным постом, а не просто в общей ветви. Так же полезно добавить возможность отображения комментариев как с первой записи, так и с последней (новые записи в начало)
  • Надпись "Комментарий добавлен" лучше сделать зелёной.
  • Поиск попросту не работает, use-case нулевой, я в шоке! (пункты 2 и 3 — крайняя необходимость, 1, 4, 5 и 6 — можно отложить на потом):
    1. Так называемый
      стандартный поисковый синтаксис: знаки "плюс", "минус", "звездочка", скобки и т.д
      должен быть описан, либо дана ссылка на его описание. Мне, например, совершенно неочевидно есть ли отличие "слово1 + слово2" от "слово1+слово2". Так же, не ясно как использовать скобки. Выводить каждому эти правила эмпирически — не лучший подход.
    2. Очень существенная часть полезной информации размещена как комментарии к каким-то, зачастую слабо связанным с темой самого комментария, темам. Найти эти комментарии очень трудно. Ввиду этого наличие переключателя "Не искать в комментариях страниц" при отсутвии переключателя "Искать только в комментариях страниц" — форменное издевательство. Предлагается реализовать. Да, и лучше писать "в комментариях к станицам", а не "комментариях страниц" (страницы сами комментируют?) — так точней и звучит лучше.
    3. В выводе результатов поиска вместо того, чтобы (как и делают поисковики типа гугла) показывать кусок текста, содержащий искомое слово или их комбинацию, всегда выводится начало комментария. Не трудно догадаться, что если искомое слово (предложение, цитата) — где-то в середине "простыни", часто посвящённой ответу на несколько слабо связанных между собой вопросов, то догадаться, где же оное среди десятков безликих шапок комментариев, практически невозможно. Это ключевой момент, который полностью обесценивает наличие поиска на сайте. Если трудно сейчас реализовать вывод контекста, путь хотя бы найденные комментарии выводятся полностью, целиком.
    4. В выводе результатов поиска, в порядке очень странного и необъяснимого исключения, показывается сам вики-сорс со всей текстовой разметкой вместо того, чтобы показывать собственно результат её действия. Это улучшает восприятие? Кроме того, это существенный privacy leak: одно и то же "на печати" можно получить разными способами и используя разные форматы (BB, вики-разметку и т.д.), и в самих комментариях этого не будет видно, зато отлично видно в поиске: кто, и как в точности использует эту разметку и какие именно из её элементов.
    5. В поле "Автор" логично было бы включить поддержку списка пользователей (не забывайте, что Гость — тоже пользователь!). Т.е. если указано "SATtva, unknown", это бы значило "все документы/комментарии, опубликованные либо SATtva'ой, либо unknown'ом".
    6. Было бы очень кстати реализовать поиск по документам/комментариям, появившимся за последние n месяцев (или m лет, если им больше года), добавив соответствующее поле/параметр. Часто хорошо помнится, когда примерно было опубликовано то или иное, но вот поисковику на сайте это не объяснить.
  • Разрешить при создании темы вводить ограничения для комментаторов. Например, запрещать им писать под гостем, чтобы псевдоним в теме был обязателен. Или, если более общо, можно разрешить вводить допусимую (для создателя темы) долю таких комментариев (на каждой странице или во всей теме)
  • Выделение цитат <[цитата]> неудобно по двум причинам: нужно переходить в латинский регистр и символы разные. А ведь это одно из наиболее часто используемых форматирований! Ну и поскольку в первую очередь оптимизировать надо самое частое, то хорошо бы добавить возможность выделять цитаты на русском регистре и повтором символа, например ;;цитата;;. Или лучше \\цитата\\ – даже на шифт не надо нажимать.
  • При использовании сносок (разметка наподобие ((*1)) и ((#1))) оные относятся ко всей странице, а не к комментарию, где они нужны (т.е. если в одном комментарии уже есть первая сноска, то первую сноску во втором комментарии необходимо нумеровать как минимум с двух). Лучше, когда каждый комментарий — "корнем" для собственных сносок. При желании сослаться на объект в других комментариях или на объект в самом топике можно воспользоваться другими элементами wiki.
  • Появление нового опроса не отображается в "последних изменениях". Почему бы не добавить? Сайт проще всего отслеживать по странице последних изменений и последних комментариев — там должны быть отражены все изменения, произошедшие на сайте. К тому же, было бы намного удобней иметь не 2 страницы ("комментариев" и "изменений"), а одну, где все изменения отражены.
  • Подобно черновикам в wiki удобно было бы иметь поддержку «черновых комментариев»: возможность к каждому треду обсуждений писать и сохранять черновик комментария, который не будет никак отображаться в треде до тех пор, пока не будет официально отправлен. Мотивация: длинные комментарии, дорабатываемые втечение длительного времени, пишутся долго и при этом нигде не сохраняются, кроме как во временном буфере сообщений, потому падение браузера приводит к потере всего комментария. Можно подумать над тем, как такую опцию сделать непротиворечащей анонимности (иметь черновики комментариев так же для гостей).
  • Сделать поддержку тегов для форумных веток и новостей. Теги могут придумываться/назначаться пользователями и меняться постфактум. Это позволило бы объединять набор новостей на определённую тему (к примеру, cold boot атаки) в одну виртуальную тематическую подшивку, а также упростило бы поиск.
  • Подобно тому, как это сделано для самих тредов и новостей, хотелось бы иметь возможность просматривать referrers для каждого комментария на сайте (список тем и комментариев, которые на него ссылаются). Цель — упрощение тематического поиска.
  • Ряд обёрток (box, wacko) не закрывают контекст в конце комментария, из-за чего конец комментария не является реально концом, и один комментарий начинает обтекать другой при неаккуратном форматировании. В итоге, из-за ошибок в разметке одного гостя портится форматирование и последующих постов от других гостей. Исправить.
  • Имеется проблема с двойным минусом при его использовании в комментировании wiki-сорса. PoC: %%(comments) тест -- тест%%
  • Подстроку вида Гость (24/05/2013 13:02) автоматически превращать в ссылку, если она встречается в тексте.
  • 10 – 50 – 100 – 500 комментариев на страницу. 20 листов комменариев, невозможно читать, а так развернул одной страницей, полистал, и задача поиска пропадает, F3. Можно открыть страницу в режиме печати (ссылка в правом верхнем углу).
  • Большинство форумов и, например, livejournal поддерживают стандартный обычный html. Почему бы не сделать так, чтобы разметку можно было прямо в комментариях оформлять, да и плюс с поддержкой стилей? Было бы здорово и очень просто.
  • SatVa, запили, что бы можно было youtube ролики вставлять в ветвь обсуждения? Нафиг.
  • SatVa, верни картикни? Например, всякие блок-схемы тех же шифров, иногда, лучше 1 раз увидеть, чем пять листов прочитать. Локальные изображения работают. Поддержка удалённых неприемлема из-за HTTPS mixed content.
  • Сделать тэг, чтобы можно было что-то убрать под кат (например исходник LaTeX-формулы, которая вставлена картинкой).
    • На данный момент может быть убрано в html-комментарий: %%(comment) текст %%

 
На страницу: 1, ... , 13, 14, 15, 16, 17, ... , 26 След.
Комментарии [скрыть комментарии/форму]
— SATtva (22/02/2012 16:29)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Готово. Версия обновлена.
— Гость (09/03/2012 06:52)   <#>
На странице /proekt/propuschennyestranicy среди названий фигурируют в том числе те, которые относятся к страницам ограниченного доступа (например, unknown-статья на тему QKD), но Гости могут их видеть. Это такой особый вид квантовой секретности? Как бы скрыто, и как бы нет одновременно? Так задумано, или я что-то не понимаю?
— unknown (09/03/2012 13:30, исправлен 09/03/2012 13:31)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Эта статья неспешно переводится здесь. За ходом перевода могут наблюдать и принимать в нём участие те, кто зарегистрирован на сайте и включён в группу OpenPGP. Заголовки отдельных страниц из этой статьи, для которых составлено оглавление, но которые ещё незаполнены, попадают туда, где вы их заметили. Как только статья будет готова, она будет перенесена из черновиков в общий доступ.

— Гость (09/03/2012 17:38)   <#>
За ходом перевода могут наблюдать и принимать в нём участие те, кто зарегистрирован на сайте и включён в группу OpenPGP.

Это всё понятно.

Заголовки отдельных страниц из этой статьи, для которых составлено оглавление, но которые ещё незаполнены, попадают туда, где вы их заметили.

О том и речь, что заметны они там должны быть только для группы OpenPGP, а не для всех. И я говорю не о секретности конкретно этой вашей статьи, а о том, что это баг движка: допустим, кто-то воспользуется движком форума для своего сайта и сделает непубличными ряд веток, тогда будет не очень хорошо, если незарегистрированные пользователи смогут читать названия ссылкок в этих ветках.
— unknown (09/03/2012 17:59)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Тогда замечание верное, согласен. Даже для нашего сайта, если например в каких-то случаях возникла бы потребность не анонсировать содержимое подготавливаемых к публикации документов раньше времени.
— SATtva (09/03/2012 19:43)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Гость совершенно прав, это непредусмотренное раскрытие информации. Будет исправлено.
— Гость (14/03/2012 04:04)   <#>
Как вставлять ссылки, содержащие пробел? Если его заменить на %20, и вставить такую ссылку в браузер, всё сработает, а если предварительно пропустить через движок, то %20 трансформируется в плюс. В чём логика? Как-то заквотить пробел внутри ссылки тоже не получается.
— Гость (18/03/2012 08:48)   <#>
Можно ли установить данный движок на Денвер в Win 7 (64)?
Если да, то можно описать пошагово. Спасибо.
— spinore (28/03/2012 00:00, исправлен 28/03/2012 00:11)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786

Спасибо за оперативную реакцию. Ещё одна проблема того же типа: на страницах пользователей указана статистика (число документов, комментариев, ещё число редакций известно). Захожу на свою страницу под Гостём и вижу: 27 документов, причём в списке только 21. Куда делись ещё 6? :) [вопрос риторический].


Кстати, исчезают статьи из списка документов очень интересно: просто не показываются в выводе на той странице, где они должны быть (вместо того, чтобы переформатировать по стандартным блокам — 20 тем в выводе). Зная, в каких страницах в списке документов «окна» (меньше 20 в выводе), можно предсказывать, в какое время были созданы соответствующие непубличные страницы. Утечка? По крайней мере, различитель между реализацией и идеальным оракулом скрытием налицо [а атаки со временем становятся только сильнее :)]

— spinore (14/04/2012 23:12, исправлен 16/04/2012 09:45)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786

Ответ на /comment52121:

Заебали писать мелким и прозрачным шрифтом. Протокол это стенограмма, а не ваша попытка стеганографироваться от читателя.

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

  • Основной текст, on-topic — чёрный и нормальный.
  • То, что имеет отношение к делу, но опосредованное — чёрный мелкий.
  • То, что написано только в силу того, что просто «пришлось к слову» (т.е. оффтоп — формальное нарушение правил, номинирующееся на удаление) — серый мелкий.

Эти градации, IMHO — ясные и прозрачные; сделаны для того, чтоб сразу было видно, что стоит читать, а что — нет, и пользуются такой схемой здесь многие — не только я. Если вы считаете, что для широких масс это кажется неудачной подачей материала, можно провести отдельный опрос/обсуждение, но уже в другой ветке. Мелкий шрифт и курсив — конвенция, также принятая в книгах (если их ещё кто-то читает из посетителей этого форума). На каких-то ресурсах вместо тегов «оффтоп» есть убирание «под кат», т.е. чтобы прочитать, нужно явно куда-то ткнуть, но в этой версии движка такого функционала нет (хотя SATtva задумывался о его введении в новом движке).




К слову, про цитирования:

  • Есть цитаты в смысле диалогов, по документации вики они обозначаются через «>» и «>>», а есть просто цитирования. Когда идёт много цитирований в тексте, разумно вышесказаное по треду (по сути, т.е., диалог) цитировать через «>», а внешние источники — через конвенциональные <[ ]>. IMHO, это облегчает чтение. С другой стороны, <[ ]> поддерживает вложенность, а «>» — нет (нет выделения по цвету, наглядного отделения по уровню вложенности и т.д.).
  • То, как расставляются переводы строк при использовании «>», очень неудобно. Почему-то, чтобы сделать перевод строки перед «>», нужно поставить две пустых (о чём многие забывают). Если не хочется ставить дополнительный перевод строки после цитирования методом «>», приходится юзать трюк с --- — т.е. склеить, как для <[ ]>, не получается.
  • Сайд-эффект использования --- — невозможность писать чёрным текстом после цитирования. По умолчанию он идёт тем же грязно-синим, что и сама цитата, и приходится его руками менять на серый (поддержки чёрного цвета в движке нет, не говоря уже о задании своего цвета по RGB). SATtva всё это исправлять не планирует, т.к. «всю систему менять надо», поэтому исходить приходится из того, что есть.
  • С недавних пор кто-то добрый «пофиксил» разметку %% %%, после чего началась вставка дополнительных бесполезных переводов после кода внутри этой разметки. Хочешь написать одну строку вербатимом — вставляется две и т.д., ещё и лишние переводы строк до/после %% %% добавляются. Хайлайтеры, правда, пока этим не болеют, но зато там нет поддержки раскраски базовых вещей, типа /bin/sh. Конечно, говнари знают только про пых и джаваскрипт, зачем там иметь шелл-раскраску? Изменение рамера шрифта, кстати, внутрь окружений %% %% и хайлайтеров тоже не протащить, т.е. ++%% %%++ работать не будет — вот кто это так придумал? Да, я понимаю, что все претензии — к разработчику wakowiki, на котором основан сей движок, но от этого легче не становится.

Напоследок:

  • Движок wakowiki — явная демонстрация кулхацкерского подхода. Нифига нам продумывать архитектуру, зачем нам математика, зачем нам полнота модели. Мы выучили пыхпых и мы знаем синтаксис, погнали! Потом только вдруг начинает сказываться, что все введения покрывают только процент возможных ситуаций, в то время как в акадмиеческих языках разработках есть полнота, и даже на каком-то примитивном sed можно написать свой калькулятор, ибо он — тьюринг-полный. А тут даже цвет и мелкость шрифта сквозь переводы строк не пробросишь: автор, видимо, решил, что в этом нет необходимости, потому разметку каждого абзаца приходится делать руками.
  • Ограничение на объём поста и объём страницы в wiki считаю несуразным (не надо его отменять совсем, но раз в 10 я бы его увеличил) — ещё до Eridan'а с этим столкнулся в своих документах.
  • Подметил, что несмотря на отсутствие поддержки UTF в движке, из-за чего все спецсимволы при очередном редактировании могут превратиться в знаки вопроса, есть обходной путь: не надо никогда копировать спецсимволы и вставлять их в движок из буфера — надо всегда их писать по html-коду: например, &#9001; — левый бракет, &#9002; — правый бракет, &#968; — греческая ψ, « — левые кавычки, » — правые кавчки (это конвенция в русском языке, в английском должен быть аналог латеховских `` и '', которые на печати превращаются в конвенциональные кавычки английского [где, опять же, есть отличие левых и правых], но в этом движке не знаю как это сделать. Двойные же кавычки на клавиатуре — ad-hoc замена обоих стандартов, но явно им уступающая по наглядности и красоте).
  • UPD: Поскольку мелкий шрифт приписывается элементам абзаца, между абзацами соответствующая настройка не сохраняется. Как следствие, если имеем несколько абзацев, идущих мелким шрифтом, то расстояние между строк будет такое же, как и без использования мелкого, что выглядит вычурно. Аналогично, размер сносок никак не учитывает размер основного шрифта, где они проставляются, из-за чего расстояние между строк сильно увеличивается при проставлении сноски.

P.ک.: на сегодня хватит, ушёл, всех с праздником!

— Гость (16/06/2012 09:51)   <#>
Как установить?
Залил на хост, отредактировал config.php, больше ничего не делал. Получается openSpace DBAL error: SQL query failed. на индексе.
— Гость (16/06/2012 10:05)   <#>
openSpace DBAL error: SQL query failed
Такое и на pgpru.com иногда бывало... хотя последнее время не видел.
— Гость (16/06/2012 10:33)   <#>
Проблема в том, что в моем случае это постоянно.
— Гость (08/07/2012 06:22)   <#>
Просмотр редакций документа уже глючит (видимо, из-за того, что текст длинный), потому дальше будет уже обрезание текста и совсем конкретные глюки. Предлагаю отделить секцию «Идеи» в отдельный документ — всё равно всем рекомендуется добавлять запрос новых фич только в «Идеи». Правда, уже не будет той просты при переносе пунктов из «Идеи» в «Исправить», но, тем не менее...
— Гость (26/09/2012 03:41)   <#>
Открыты несколько вкладок. В одной отправляю коментарий, а в другой жму на предпросмотр (почти одновременно). В итоге страница, где нажал на предпросмотр, загружается первой и пишет сверху "комментарий добавлен". При этом комментарий для предпросмотра на ней исчезает. Офигенно.
На страницу: 1, ... , 13, 14, 15, 16, 17, ... , 26 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3