ExBB Community ExBB Community
 Сайт проекта ExBB Общение объединяет!
Войдите на форум при помощиВойти через loginza
 Чат на форуме      Помощь      Поиск      Пользователи     BanList BanList


 Страниц (6): [1] 2 3 4 5 6 »   

> Описание: Тема для систематизации списка необходимых доработок и неисправленных багов ExBB
WebMaster
Отправлено: 30 июня 2018 — 11:01
Post Id



Пользователь
Advanced Member


Покинул форум
Сообщений всего: 428
Дата рег-ции: Окт. 2013  
Репутация: 32




Улыбка Доброго всем времени суток! Сразу прошу прощения за длительное отсутствие (учёба, увы, занимает много времени).

Предлагаю в этой теме составить список самых необходимых доработок, а также ошибок, которые были найдены пользователями ExBB, но не исправлены.
 
 
Yamaliya
Отправлено: 30 июня 2018 — 11:11
Post Id



Пользователь
Super Member


Покинул форум
Сообщений всего: 659
Дата рег-ции: Авг. 2012  
Откуда: Ямал
Репутация: 20




WebMaster , о какой версии идёт речь?
Если пробежаться по последним сообщениям, то там видны все возникшие проблемы.
 
 
WebMaster
Отправлено: 30 июня 2018 — 11:14
Post Id



Пользователь
Advanced Member


Покинул форум
Сообщений всего: 428
Дата рег-ции: Окт. 2013  
Репутация: 32




Yamaliya пишет:
WebMaster , о какой версии идёт речь?

Речь идёт о последних версиях движка. В течение последнего года я не следил за происходящим здесь, поэтому не знаю, что изменилось. Сейчас как раз просматриваю сообщения на форуме.
 
 
Flat
Отправлено: 8 июля 2018 — 10:03
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




На мой взгляд, самое главное, что надо сделать в первую очередь, это изменить способ сохранения массивов в файл. В движке это делается путём обнуления существующего файла, а затем записи в него новой информации. Это потенциально опасная операция, ибо если на сервере произойдёт сбой, например по причине отключения электроэнергии, то пропадёт ВСЯ тема с сообщениями. Мы же качаем её всю в ОЗУ. Выручит только существующий бэкап форума если таковой имеется у админа.
Правильней сделать примерно так: создаём временный файл; сохраняем туда наш массив; проверяем произошла ли запись правильно и не является ли файл пустым; если всё в порядке удаляем старый файл и переименовываем временный файл в старый.
 
 
Flat
Отправлено: 8 июля 2018 — 11:18
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




Добавлю. Это я сделаю сам, тут делов на пол часа.
Сейчас курю тему "Перспективы дальнейшего развития". Там yura3d сказал такую фразу: "Перспективы файловой версии - раз и навсегда кануть в лету. Это случится рано или поздно, более того, это уже сейчас происходит. "
Он там усиленно продавливал тему изменения базы данных с файлов последовательного доступа к файлам прямого доступа, как в СУБД. И говорил, что это раз в 50 ускоряет работу форума.
Я согласен с ним, что ускоряет, тем более, что сам написал и тестировал функцию бинарного поиска по файловой базе прямого доступа, и скорость оказалась просто КОСМИЧЕСКОЙ)). А ведь можно сделать и прямую выборку.. Но всё это сильно усложнит двиг форума.
Но я не согласен, с yura3d в том, что исчерпан потенциал данного движка.
Не исчерпан. Просто не там искали..
Например: зачем качать всю тему целиком, если мы выводим всего например два десятка сообщений? Это имеет смысл делать если мы осуществляем поиск по теме. А в обычном случае этого не требуется. И если тема разрастётся, то скорость форума упадёт. Хотя, я тестил: 4 мегабайтная тема грузится у меня за 0,2 сек.
Например: мы можем делить тему на несколько отдельных файлов, тогда загрузка страниц будет линейной константой..
Можно упростить форум сделав его с постоянным числом сообщений на страницу, зато скорость будет приличной.
Конечно можно оставить и в этом случае выбор за пользователем, хотя логика работы форума несколько усложнится.
Малое количество сообщений на страницу тоже плохо, так как пользователь всё равно просматривает предыдущие страницы если тема имеет большой процент новых сообщений. Тогда можно сделать 50 сообщений на страницу либо константой либо оставить выбор пользователям. Или сделать например по 100 сообщений на файл, тогда, к тому же, нагрузка на сервер уменьшится и количество файлов будет приемлемым.
Как считаете? Для меня важно мнение простых и не простых пользователей.

(Отредактировано автором: 8 июля 2018 — 11:38)

 
 
Flat
Отправлено: 9 июля 2018 — 12:34
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




Текстовая база предполагается будет иметь такой вид:
<?die;?>$arr=array (
'id' => 1,
'name' => 'admin',
'pass' => 'jfjdkfvslklak84j4wyff7dhe7dhe'
'mail' => 'hhhhh@mail.ru',
array (
0 => 1
),
);
Это гораздо читабельней чем:
a:4:{s:2:"id";i:1;s:5:"name";s:8:"admin";s:4:"pass";s:29:"jfjdkfvslklak84j4wyff7dhe7dhe";s:4:"mail";s:13:"hhhhh@mail.ru"}
 
 
Flat
Отправлено: 10 июля 2018 — 09:01
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




"Все ушли на фронт" по своим делам, и вернутся не скоро.. Хорошо, буду писать свои соображения в этой теме на будущее.
-----------
Вчера реализовал и протестил две функции работы с файлами. Это для инфо по делам текущим.
------------
По мере знакомства с кодом возникают некоторые мысли и соображения, которыми хочется поделиться с заинтересованной публикой. Критика уместна в любом случае, ибо позволяет найти правильный путь и исправить ошибки, так что не принимайте близко к сердцу.Итак приступим.

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

2)Из рук вон плохо поддерживается модульность, коей, по большому счёту вообще не видно.

3)Папка members содержит файлы с некоторой информацией о пользователях. Другая информация о данных пользователях разбросана по другим папкам. Например те же аватарки и т.п. Имело бы смысл каждому пользователю дать отдельную папку и сбрасывать туда все файлы которые его касаются.

4)В скрипте используются сессии. Сессии полезны, например в том случае, если пользователь отключил куки. В этом случае при входе на сайт он будет залогинен пока есть сессия, то есть, пока не закрыт его браузер.
Теперь попробуйте заблокировать куки с данного форума, и вы увидите, что при попытке захода на форум не происходит авторизации. Это серьёзное упущение. Тогда зачем нужны сессии? Детство какое-то..

5)В куках сохраняется хэш пароля. Так лучше не делать. В куки надо сохранять рэндомный токен, который обновляется при каждом заходе на сайт.

Пока всё.

(Отредактировано автором: 10 июля 2018 — 09:30)

 
 
Flat
Отправлено: 10 июля 2018 — 13:47
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




6) Шаблоны.
Свалены в одну папку. Чтобы понять код приходится постоянно лазить по разным папкам, что сильно утомляет. Может быть вообще отказаться от шаблонов. В FluxBB их нет, и код намного легче воспринимается на глаз и более понятен.

7)Языки.
Универсализация, в расчёте, что кто-то(а кто - один два чел.?) когда-то(в 22 веке)захочет сделать свой форум на суахили, приводит к тому, что код становится абсолютно не читаем. А чтобы понять что же здесь в данном конкретном месте выводится приходится лопатить не один десяток файлов. А там поди найди, ибо этих файлов целая куча. Если форум позиционируется как форум для русскоязычного сообщества, то нужно отказаться от языковых алиасов. У зарубежных товарищей существуют десятки форумов, которыми они и пользуются, а вот зачем ради мнимой универсализации усложнять жизнь админам, вообще не представляю. О вкусах не спорят..
Тут я высказываю то, что хотел бы видеть в своём собственном форуме.
Когда понимаешь что придётся переделывать почти всё, то это будет уже другой форум, хотя местами и с включением старого кода..
В общем, exbb является крайне не дружелюбен к простым админам, что необходимо срочно исправлять. К сожалению его эволюция почему-то двигается по пути усложнения кода. Код должен быть простой и ясный, только тогда он будет безопасен. Без выкрутасов, типа, "я и так ещё могу". Да я могу круче, но не буду из принципа.

(Отредактировано автором: 10 июля 2018 — 13:52)

 
 
Flat
Отправлено: 10 июля 2018 — 14:12
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




8)Вернусь к ООП.
ООП надо делать там, где его не видно: в десктопных приложениях, системах, которые поддерживают ТОЛЬКО разрабы. Для обычных админов, которые знакомы с PHP на среднем уровне, и для которых концепция ООП тёмный лес с чертями, это на фиг ненужно! Мы же делаем форум для пользователей, а не для себя. Хотя некоторые товарищи специально усложняют код, чтобы можно было делать бабки. Ну, это их проблемы.
 
 
Yamaliya
Отправлено: 10 июля 2018 — 17:42
Post Id



Пользователь
Super Member


Покинул форум
Сообщений всего: 659
Дата рег-ции: Авг. 2012  
Откуда: Ямал
Репутация: 20




Flat , по структуре данных. Надо бы предусмотреть конвертер туда и обратно.

По пункту 7 двумя руками ЗА.

А то, что Все ушли на фронт, так ведь пора отпусков.
 
 
1Bot
Отправлено: 10 июля 2018 — 22:22
Post Id



Пользователь
Super Member


Покинул форум
Сообщений всего: 768
Дата рег-ции: Апр. 2009  
Откуда: Днепропетровск
Репутация: 69




Yamaliya пишет:
по структуре данных. Надо бы предусмотреть конвертер туда и обратно.

Проще сразу в функции класса для чтения такой структуры делать проверку что в начале файла <?die;?> или <?php die;?>
и независимо от того правильно считывать, тогда в функции сохранения можно использовать любой из этих форматов данных.
 
 
1Bot
Отправлено: 10 июля 2018 — 23:03
Post Id



Пользователь
Super Member


Покинул форум
Сообщений всего: 768
Дата рег-ции: Апр. 2009  
Откуда: Днепропетровск
Репутация: 69




Flat, рассуждая об ООП не забывайте, что основной код был написан еще для PHP4 и лишь немного видоизменен для работы с PHP5 на уровне "чтобы не возникало фатальных ошибок и предупреждений". Используется практически только один класс fm, хотя у меня от него стойкая ассоциация с микросервисом со своим апи.

Сейчас же есть возможности как раз использовать средства ООП из новых версий PHP7 и по возможности убирать таким образом функциональные повторы в существующем коде.
Так что полный отказ от ООП будет скорее ошибкой.

Каждый модуль вполне себе может быть отдельным сколь угодно сложным объектом, который взаимодействует с классом ядра форума и реализует заданный интерфейс модуля, а также использует все возможности ядра.

До сих пор сложно разрабатывать модули (нет описания интерфейсов взаимодействия ядра и модуля, тут полиморфизм ООП был бы очень кстати), чтобы их было легко интегрировать в админку и в основной форум.
 
 
NordWest
Отправлено: 10 июля 2018 — 23:18
Post Id



Пользователь
Super Member


Покинул форум
Сообщений всего: 986
Дата рег-ции: Дек. 2011  
Откуда: Северо-Запад
Репутация: 74




1Bot пишет:
нет описания интерфейсов взаимодействия ядра и модуля
Я бы сказал что нет такой концепции. Многие дополнения позиционируются как модули но настолько жёстко вшиты в ядро, что по сути модулями не являются. Хотя справедливости ради стоит сказать, что Юра пытался это дело стандартизировать. В его модулях прослеживается структура.
(Добавление)
1Bot пишет:
тогда в функции сохранения можно использовать любой из этих форматов данных
Я слышал, что в последних версиях PHP грозились запретить использование сокращённой конструкции <?
 
 
Flat
Отправлено: 11 июля 2018 — 11:27
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




Yamaliya пишет:
Надо бы предусмотреть конвертер туда и обратно.

Согласен. Просто прежде чем говорить о конвертере, необходимо сначала создать новый двиг.
Yamaliya пишет:
двумя руками ЗА.

Всё, значит так и будет. Ха-ха
1Bot пишет:
тогда в функции сохранения можно использовать любой из этих форматов данных.

Там ещё надо будет предусмотреть правильный разбор формата. Вот рабочие функции по новой базе, черновой вариант, но рабочий, кому интересно. Я не профессиональный программист, а программист-любитель, который любит копаться в чужом коде и старается писать по крайней мере не хуже приличий, так что не пеняйте, если что:
Пример кода (Отобразить)

1Bot пишет:
не забывайте, что основной код был написан еще для PHP4 и лишь немного видоизменен для работы с PHP5 на уровне "чтобы не возникало фатальных ошибок

Я прекрасно всё понимаю. Также прекрасно вижу откуда растут ноги многих функций. Первоначальный автор форума, Александр Субханкулов, использовал код IPB форума. И, кстати, правильно делал, ибо зачем городить велосипед если есть хорошие рабочие решения, жизнь-то одна.
Потом, уже после него, форум был изменён, хотя структура осталась практически прежней.
1Bot пишет:
Сейчас же есть возможности как раз использовать средства ООП из новых версий PHP7 и по возможности убирать таким образом функциональные повторы в существующем коде.
Так что полный отказ от ООП будет скорее ошибкой.

Этим и занимается, насколько я понял, ув. WebMaster . Посмотрел код последней версии, там действительно ООП несколько улучшен. Вот эту ветку и следует продолжать делать в том же духе. Это, так сказать, старая песня о главном, и пусть она будет, кому нужно. Мне - нет.. Я хочу иного.. Закатив глазки
ООП ведь это всего лишь попытка эмулировать модульность, а её можно эмулировать и без ООП, хотя в PHP на это есть определённые ограничения.
1Bot пишет:
Каждый модуль вполне себе может быть отдельным сколь угодно сложным объектом, который взаимодействует с классом ядра форума и реализует заданный интерфейс модуля, а также использует все возможности ядра.

Это самое сложное: понять как всё будет функционировать на всех уровнях; каким образом ДОЛЖНО быть устройство модульного движка. Чтобы и безопасность повысить и чтобы он был понятен и прост. Я постоянно об этом думаю. И уже сложилась определённая картина..
1) На самом верхнем уровне находится файл index.php. Это - головной модуль. Через него происходит вся работа. Его задача: инициализировать данные, авторизовать пользователя, провести валидацию имен существующих модулей в системе с именем того модуля, который приходит с запросом пользователя и подключать эти модули. Он ничего не выводит пользователю, а только выполняет эту черновую работу. Валидация имён позволяет легко обеспечить высокую безопасность движка, по принципу: свой - свой. Валидация ключей и значений возлагается на модули верхнего уровня, ибо только они сами знают "своих подопечных".
2) Модули верхнего уровня это: вывод главной страницы, регистрация и пр.
3)Модули нижнего уровня работают через подключение в модулях второго уровня.
Таким образом осуществляется строгая иерархическая система, которая легко понятна. Есть головной модуль, первого уровня, который знает о существовании модулей второго уровня, а модули второго уровня знают о существовании модулей своих подопечных.
В коде всё станет понятней что где и как. Так мне это представляется, и я начал уже потихоньку это осуществлять.

(Отредактировано автором: 11 июля 2018 — 11:31)

 
 
Flat
Отправлено: 12 июля 2018 — 10:23
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




Выше в коде небольшая оплошность. В связи с тем, что поменял <?die;?> на <?phpdie;?> нужно изменить цифру 8 на 11 в некоторых местах кода.
Код черновой без логирования ошибок. Большой плюс такого подхода в том, что исключается ситуация с обнулением файлов, что иногда наблюдалось в exbb. Если что случится, то хотя бы останется временный файл с данными.
 
 
Страниц (6): [1] 2 3 4 5 6 »
Сейчас эту тему просматривают: 1 (гостей: 1, зарегистрированных: 0)
« Обсуждаем »

> Похожие темы: Доработки и исправления в ExBB
Темы Форум Информация о теме Обновление
Как вставить рекламу
на ExBB FM RC 1.0
Общие вопросы Ответов: 18
Автор темы: SmexotvoriN
10 февраля 2014 — 17:14
Автор: Zeg
Подфорумы
Имеется ли реально работающий мод «Подфорумы» для Exbb.FM.RC1
Обсуждение Ответов: 3
Автор темы: fdg
16 ноября 2009 — 07:03
Автор: fdg
Мод: Похожие темы
Совместимость: ExBB FM 1.0 (версии: RC1, RC2 )
Модификации и дополнения Ответов: 37
Автор темы: Иван Петров
8 сентября 2012 — 14:27
Автор: wasp
Мод: Портал
Простая портальная система на основе ExBB
Модификации и дополнения Ответов: 29
Автор темы: igrok54
22 мая 2014 — 08:41
Автор: GreatALF
Перспективы дальнейшего развития
Отказ от ExBB FM 1.0 и переход на ExBB FM 1.1 и ExBB 2.0
Новости Ответов: 217
Автор темы: yura3d
24 июля 2012 — 16:59
Автор: electron
 



Все гости форума могут просматривать этот раздел.
Только зарегистрированные пользователи могут создавать новые темы в этом разделе.
Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.
 




Яндекс.Метрика   

Powered by ExBB
ExBB FM 1.0 RC1 by TvoyWeb.ru
InvisionExBB Style converted by Markus®

[Script Execution time: 0.2]     [ ]