Forums / National / Russian / Тех. поддержка / Пояснения по проекту

1. Плагины накиданы по принципу создания единой базы плагинов. Причем не для "скачал-поставил", а в первую очередь для дальнейшей доработки. Например, news и textboxer2 там нестандартные. Каюсь и посыпаю голову пеплом, что не проверил их работоспособность на всех версиях движка, не исправил все ошибки и не написал по инструкуции на двух языках сразу. Но тот, кто это сделает, пусть первым кинет в меня камень :wink

2. jQuery включен в основную ветку как фреймворк, а не как некая новая примочка, которая все делает сразу глянцевым и нарядным. Это таки и нужно затем, чтобы кодеры могли спокойно писать плагины, спокойно используя эту библиотеку, не заботясь о зависимостях и конфликтах.

3. Стандартные скины - на общее обсуждение в международный форум.

4. Antar работает над новой версией локализации, когда закончит, тогда она (в utf8) и будет включена в основную ветвь. Что касается этого сайта, то очень хочется скооперировать сообщество из разных стран, вместо того чтобы все расползались по своим углам, а раз так, то надписи на английском не должны вызывать проблем. Полоска внизу преследует ту же цель, с которой Xiode ее туда добавил изначально.

5. Да собственно, все предложения пока за переход на UTF-8, работа над этим ведется. Следующий шаг - рефакторинг на mbstring и новая локализация в utf8.

6. По поводу bbcode советую повнимательнее прочитать ветку в Core Labs. Xbb, к сожалению, мы интегрировать не будем хотя бы из-за его лицензии. Никакие новые ббкоды никуда не добавляются. Добавляется универсальный API, который позволит не только управлять ббкодами в админке, но и в пользовательских плагинах. Привязки ббкодов к конкретному редактору больше не будет, и в комплекте с разными редакторами можно будет устанавливать специфические ббкоды. В качестве нового дефолтного редактора попробуем прикрутить markItUp! с подробными инструкциями, как создавать другие плагины-редакторы. Технически новый парсер реализован на все тех же строках и регулярных выражениях (я бы, может, и рад воспользоваться каким-нибудь бинарным модулем из PECL или написать парсер на Си, да вот только тогда всем надо будет как минимум на VPS переезжать). Можно, конечно, "подсмотреть" идею конечных автоматов у xBB или еще что изобресть, но пока это не самоцель. Про производительность MySQL беспокоиться не стоит, ибо кэширование для этого есть. Кроме того, реализуется новая опция "рендеринга по требованию" для страниц и форумов, т.е. парсинг происходит после того, как были произведены изменения в тексте, а не при каждом отображении. От идеи модульных парсеров в пользу одного универсального пришлось как раз отказаться из-за потерь в производительности, которые возникают вследствие этой самой модульности.

7. В attach я старался закрыть все известные дыры, связанные с закачкой файлов в php, кроме тех, которые в принципе не закрываются (дыры IE в частности). Я, конечно, постарался предоставить API для того, чтобы вложения можно было реализовать в любом плагине или модуле ядра, но PFS - это все-таки немного другое. Иногда нужно именно "личное файловое пространство", а не возможность прикреплять файлы к сообщениям. Так что просто взять и выкинуть PFS на свалку истории - опрометчивый поступок. Доработать - более взвешенный. Все это вопрос чьих-то человеко-часов.

8. Про разделение кода и html полностью согласен, да и все согласны.