У Вас в настройках PHP register_globals=ON? какеры идут к Вам!!!

Файловый Архив

  • Неограниченное количество категорий и суб-категорий
  • Настройки прав доступа по группам
  • Настройки прав доступа по каждой категории
  • Предпросмотр медиа файлов: FLV, IFLV, F4A, F4V, MP4, MP3, MOV и других...
  • Мультизагрузка файлов - SWFUploader
  • Добавление файлов с сервера
Подробности и история обновлений продукта в этой теме
Loading

Go Back   форум vBSupport.org > > >
Register Изображения Меню vBsupport Files Manager Аллея Звёзд Реклама на форуме Search Today's Posts Mark Forums Read
  • Мемберка
  • Администраторам
  • Premoderation
  • For English speaking users
  • Изменения в правах
  • Каталог Фрилансеров
Пароли на скачивание файлов в Member Area меняются автоматически каждый день
Если вам нужно скачать какой то скрипт, за паролем ко мне в ЛС
привет какирам kerk
Ещё раз обращаем Ваше внимание: всё, что Вы скачиваете и устанавливаете на свой форум, Вы устанавливаете исключительно на свой страх и риск.
Сообщество vBSupport'а физически не в состоянии проверять все стили, хаки и нули, выкладываемые пользователями.
Помните: безопасность Вашего проекта - Ваша забота.
Убедительная просьба: при обнаружении уязвимостей или сомнительных кодов обязательно отписывайтесь в теме хака/стиля
Спасибо за понимание
На форуме введена премодерация ВСЕХ новых пользователей

Почта с временных сервисов, типа mailinator.com, gawab.com и/или прочих, которые предоставляют временный почтовый ящик без регистрации и/или почтовый ящик для рассылки спама, отслеживается и блокируется, а так же заносится в спам-блок форума, аккаунты удаляются
for English speaking users:
You may be surprised with restriction of access to the attachments of the forum. The reason is the recent change in vbsupport.org strategy:

- users with reputation < 10 belong to "simple_users" users' group
- if your reputation > 10 then administrator (kerk, Luvilla) can decide to move you into an "improved" group, but only manually

Main idea is to increase motivation of community members to share their ideas and willingness to support to each other. You may write an article for the subject where you are good enough, you may answer questions, you may share vbulletin.com/org content with vbsupport.org users, receiving "thanks" equal your reputation points. We should not only consume, we should produce something.

- you may:
* increase your reputation (doing something useful for another members of community) and being improved
* purchase temporary access to the improved category:
10 $ for 3 months. - this group can download attachments, reputation/posts do not matter.
20 $ for 3 months. - this group can download attachments, reputation/posts do not matter + adds eliminated + Inbox capacity increased + files manager increased permissions.

Please contact kerk or Luvilla regarding payments.

Important!:
- if your reputation will become less then 0, you will be moved into "simple_users" users' group automatically.*
*for temporary groups (pre-paid for 3 months) reputation/posts do not matter.
Не можете скачать вложение?
Изменения в правах групп пользователей
внимательно читаем эту и эту темы
Короткая версия - тут
Уважаемые пользователи!

На форуме открыт новый раздел "Каталог фрилансеров"

и отдельный раздел для платных заказов "Куплю/Закажу"

 
 
Первый пост
Old  
syn
Эксперт
vBSNews
 
syn's Avatar
Default 0

@YURSHAT, ну так я о том же.
Форум, это просто условное название структуры контента на странице.
Если назвать это как-то иначе (прам-пам-пам) сути это не изменит. Всё тот же текст, картинки, файлы, видео и кнопачки.

Функции везде одни и те же. Расположил на странице хитро, обозвал, как нравится, вот тебе и мегахрень какая-то.
Потом человеки на каком-то хитром интеллектуальном уровне понимают, что на форум нужно пару слов запостить (а можно котика совсем без слов)
В файловик, то надо файлик загрузить... В разделе вопрос/ответ надо задать вопрос или ответить (ну то же самое можно делать на форуме).

Я даже не знаю зачем это всё. Может это потуги как-то разнести, упорядочить.

В профиле инфа обо мне людимом.
В блогах какие-то объемные статьи инструкции
Вопросы в разделе вопрос/ответ.
Зипы, рары в файловик кладем.
Ну и так далее.

хз. ну а как еще объяснить такое разнообразие сущностей...

syn добавил 13.07.2015 в 02:14
Вот негодяи, устроили тут ромашку jQuery, YUI, форумы, блоги, 5-ки, 3-ки.
вот не спится вам.

Last edited by syn : 07-13-2015 at 03:14 AM. Reason: Добавлено сообщение
 
Bot
Yandex Bot Yandex Bot is online now
 
Join Date: 05.05.2005
Реклама на форуме А что у нас тут интересного? =)
Old  
hoo
Мастер
 
hoo's Avatar
Default 0

Наверняка, это будет полезно тем, у кого булка 3.6 и проблемы с новыми версиями php.
Но вот с 3.8 съезжать вряд ли кто будет, в сторону уменьшения. И будут альбомами пользоваться и социальными группами хотя вроде бы они не нужны (вернее кому-то очень даже нужны).
Всё упирается в нужны населения и если это востребовано, то этим будут пользоваться.
 
Old  
YURSHAT
Coder
 
YURSHAT's Avatar
Default 0

Quote:
Originally Posted by syn View Post
Вот негодяи, устроили тут ромашку jQuery, YUI, форумы, блоги, 5-ки, 3-ки.
вот не спится вам.
Такова наша "сущность"
 
Old  
Core dumped
Продвинутый
 
Core dumped's Avatar
Smile [3.6.12] Ностальгии псто 6

Quote:
Originally Posted by YURSHAT View Post
Это вообще идеальный кандидат на форк
Очень хорошее начинание, позволю высказать ряд пожеланий, которые у меня, в свое время наболели. Сейчас для меня это уже не особо актуально, но сообществу, желающему развивать продукт далее, могут пригодиться.


База данных

Запросы

Прежде всего, каждый разработчик, который захочет сделать что-либо под vBulletin столкнется с написанием SQL запросов. И в этом плане все весьма печально и остало от жизни, система не предлагает никакого вменяемого API для этого дела, по сути являясь прокладкой до сырых mysql_ функций, использование которых приносит боль как разработчику, так и пользователю, который будет потом с этим делом мучиться и ловить неочевидные инъекции.
К счастью, решение этой проблемы существует. PDO уже довольно давно часть стандарта языка, имеет вполне себе приятное API и не требует никаких особых навыков для использования, зато помогает сэкономить кучу времени, а главное нервов.
Без этого даже в ядре можно найти массу подобных штук:
Code:
$vbulletin->db->query_write("
	INSERT INTO " . TABLE_PREFIX . "strikes
	(striketime, strikeip, username)
	VALUES
	(" . TIMENOW . ", '" . $vbulletin->db->escape_string(IPADDRESS) . "', '" . $vbulletin->db->escape_string(htmlspecialchars_uni($username)) . "')
");
что у любого, даже скептически относящегося к религии человека, вызывает стойкое желание перекреститься.
PDO же позволит сократить вышенаписанное до
Code:
$vbulletin->db->query("INSERT INTO " . TABLE_PREFIX ."strikes(striketime, strikeip, username) VALEUS (?, ?, ?)", [TIMENOW, IPADDRESS, $username]);
Такая запись уже не будет вызывать определенных позывов и в общем и целом будет соответствовать духу современной разработки (Современной - то бишь с 2005 года и далее).

Так же PDO имеет приятной бонус, отвязывая пользователя от использования mysql или mariadb в своем стеке. Если в форке, помимо прочего, избавиться от мускулизмов (Которых там, вроде как, и не должно быть особо много), то можно будет запускать продукт и на PostgreSQL, что добавит вам изрядное количество плюсов в карму от благодарных системных администраторов, вынужденных держать Maria-стек только ради vBulletin.


Внешние ключи

Вторая претензия так же касается работы с базой данных, но на этот раз уже на уровне самой схемы. В vBulletin напрочь отсутствует связность данных через внешние ключи, что всегда делало меня грууууустным пандой.
Я не спорю, что подобное решение иногда вынужденное, когда имеются таблицы, в которых одно поле может ссылаться на разные таблицы (Так называемые generic-и, не помню как это называется по научному, связи вида object_id, object_type). Но ведь в vBulletin это совершенно не так! Здесь самая что ни на есть явная реляционная модель, со вполне себе однозначными связями. Но при этом сам встроенный механизм построения связей отчего-то не используется. В результате все поддержание консистенси сваливается на приложение, которое просто физически не в состоянии обеспечить его со стопроцентной гарантией. Более того, если у вас есть проект с установленными сторонними модулями, то всего через пару лет вы внезапно обнаружите, что целостности вашей базы данных и след простыл, она будет полна обрывков каких-то данных минувших лет, появившихся непонятно откуда и мешающих проводить хоть какую-либо аналитику.
Поэтому основное пожелание к форку: при инсталляции прописать-таки внешние ключи, никому от этого плохо не станет, зато благодарные DBAшники скажут вам большое спасибо.
Ну, и если вспомнить предыдущий пункт, то неплохо бы сделать и инсталляционный скрипт для PostgreSQL. Много правок там потребоваться не должно, будет некоторое различие в типах полей, но это не страшно.

Туда же кстати странное именование PrimaryKeys в таблицах. Вместо единого и понятного всем id возникают всякие postid, visitormessageid и прочие монстры. Какой в этом смысл - честно говоря до сих пор не понял, кроме того, что с первого раза не всегда удается вспомнить, как же там называется этот самый первичный ключ. Ну это так, уже просто старческое ворчание, это-то уж точно форком не поправить, в противном случае о совместимости с плагинами можно вовсе забыть.


serialize (Гори он в аду)

Третье пожелание к форку: пожалуйста, отучите ядро сохранять данные в базу используя serialize. Серьезно, использование serialize - это БОЛЬ, превращающее интеграцию со сторонними системами в кромешный ад, закливающий инфраструктуру на php, либо требующий изрядных костылей для попыток понять, что же там в этих полях написано. Заменив serialize на json вы спасете немало котят, покидающих этот бренный мир не в силах вынести несовершенства serialize. json - вполне удобный формат для хранения коллекций, прекрасно читаемый как человеком, так и, что более важно, машинами, при этом используя абсолютно любой стек. В случае PostgreSQL можно даже напрямую искать по json, если тип данных json или jsonb, что так же говорит не в пользу serialize.
Кстати, все проблемы при конвертации кодировок базы возникают именно из-за безумного решения использовать serialize вместо json. serialize сохраняет необходимое количество байт для хранения коллекции, поэтому переход на мультибайтовые кодировки делает такие записи нечитаемыми даже для самого php. Обидно будет иметь данные, которые больше нельзя прочитать, не так ли?


В дополнение к предложениям относительно базы можно упомянуть и возможность внедрения какого-либо QueryBuilder'а в форк. Хоть это предложение и совсем космическое и не будет поддерживаться сторонними плагинами, разработанными для оригинала, но все же вполне поможет разработчикам под форк, да и само ядро избавит от необходимости собирать запросы конкатами, что выглядит уж совсем дико. Тем не менее, это не обязательно и не столь критично, так как задача собирать запросы встает вовсе не так часто, как задача писать запросы без инъекций



Инфраструктура


Шаблоны

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

Туда же, из области космоса - заменить собственный откровенно куций шаблонизатор vBulletin, заставляющий совершать много лишних действий по типу ручного эскейпинга данных, на один из промышленных стандартов в виде Smarty, Twig, либо любой другой по вкусу. Один раз попробовав нормальный шаблонизатор уже весьма трудно вернуться к тому, что предоставляет vBulletin. Наследование шаблонов, циклы, шаблонные фильтры, управление контекстом - все это весьма притягивает и вызывает боль в случае отсутствия.
Хотя, конечно, это решение, как бы не было оно хорошо для разработчиков и дизайнеров, сделает форк несовместимым со сторонними плагинами, но мечты, мечты.


Фразы

Сколько раз я не пытался использовать фразы в свое время, сам механизм локализации отталкивал меня от этого решения. Казалось бы авторы системы сделали все, чтобы фразами было пользоваться максимально неудобно, и разработчик, не ставивший себе целью приведения кода к стандартам для выкладывания в паблик, от них попросту отказывался. Что очень зря, кстати, и изрядно мешает образованию интернациональных сообществ.
К счастью, в этом плане так же все уже придумано до нас. Есть гнутый gettext, прекрасно поддерживающийся самим php из коробки, есть изрядное количество инструментов для перевода, и, что самое главное, есть возможность в автоматическом режиме исследовать код на предмет наличия фраз и генерировать файлы для перевода без видимых ручных затрат.
Единственное что, данный подход не совсем подходит к идеологии vBulletin, так как в gettext обычно используются настоящие фразы на языке разработчика, в то время как в vBulletin исользуются так называемые slug-названия, вроде x_powered_by_vbulletin вместо реальной фразы. В принципе, ничего не мешает использовать их в качестве msgid, создавая дополнительный перевод на основной язык, хотя, конечно, это не всегда удобно для конечного переводчика.
В любом случае, за внедрение инфраструктуры gettext сотни переводчиков скажут вам огромное спасибо.


Бэкпорт табов в профиле

Нет, это не подразумевает перенос социальных функция, в частности visitormessage. Имеется ввиду именно механизм разделения информации на табы. Причем желательно, чтобы бэкпорт был выполнен с полным сохранением API, что позволило бы ставить продукты от "вышестоящих" линеек 3.7 и 3.8. Да, насколько я помню, это API было так себе и в свое время вызывало у меня ряд вопросов, но тем не менее оно вполне себе используется и было бы нерационально от него отказываться. Разделение информации в профиле - здравая идея, не имеющая никакого отношения к "социальности". Было бы здорово, если бы форк эту идею подхватил.


Установка без веба

Для установки vBulletin требует отдавать апачем целый установочный каталог на всеобщее обозрение, чтобы пройти там несколько шагов, лишь на немногих из которых требуется реальный пользовательский ввод. На мой взгляд это не очень хорошо, я бы даже сказал совсем не хорошо. Более того, это не автоматизируется ну абсолютно никак (Сомнительно, конечно, что кто-то будет авто-раскатывать форк на множество инстансов, писать всякие ansible скрипты на это и вообще заниматься подобным непотребством, но вдруг. Случаи бывают разные, а возможность иметь хотелось бы). Поэтому было бы очень неплохо, если бы существовала ещё и консольная установка, не требующая выставления в публичный доступ каталога install, ровно как и веб-интерфейса в целом. Простая консольная команда, принимающая аргументом путь до конфига способна установить рабочий инстанс форума без всякого участия со стороны пользователя. Это будет как быстрее, так и безопаснее. Было бы интересно увидеть такую возможность в форке.


Субъективные пожелания от пользователя


Внедрение второй разметки вместо bbcode, с возможностью выбора при написании сообщений.

Не важно, что это будет за разметка, markdown, reStructuredText, Creole или любая другая. Главное, чтобы эта разметка была стандартизованна и позволяла везде получать одинаковый результат.
BBCode вызывает лишь боль и уныние, вместо написания статей я вынужден бодаться с неудобной разметкой, которая, что самое ужасное, ВЕЗДЕ РАЗНАЯ (Смайл, бьющийся головой апстену). Отсутствие стандартизации BBCode просто убивает. С ужасом вспоминаю те дни, когда мне приходилось форматировать тексты на форумах, это просто непередаваемое удовольствие, сравнимое разве что с самобичеванием или перерезанием вен.
Если у пользователя будет возможность выбора простой разметки вместо BBCode прямо из коробки, то данному форку просто не будет цены.


Медиа-аттачи

Насколько я помню, форум позволяет встраивать медиа-аттачи прямо в тело сообщения, например прикрепленные картинки. Эта возможность просто ужасна. Из-за этого сообщения для гостей выглядят приветом из девяностых с побитыми картинками (А вместо картинок там будут отображаться квадраты с крестиками, ведь гостям эти самые аттачи недоступны). С этим определенно нужно что-то делать, как вариант например конвертировать такие финты ушами на этапе сохранения, заливая на человеческий картинко-хостинг по типу Imgur (Благо API в наличии, да и квоты весьма щедрые: 1250 загрузок в день. Вряд ли пользователи смогут генерировать больше контента аттачами). Ну или просто более колхозный вариант - запретить такие "вставки" вовсе. Насколько я помню, они встроены в ядро, поэтому так просто отключить их не получится, так что вся надежда в этом плане на форк.



Как-то так. Не воспринимайте как истину в последней инстанции или как попытку учить кого-то как жить, просто некий субъективный опыт, собранный за годы сосуществования с системой, к тому же изрядно подзабытый в последние годы. Раньше у меня, вероятно, было бы больше предложений, но сейчас вспоминаются только самые яркие, выпившие у меня больше всего крови в свое время. Прошу прощения за некую сумбурность, текст не подразумевался связным и разбитым на подпункты, это я добавил уже к концу и как-то перечитывать и править стиллистику было уже лень. Можно сказать поток чистого разума, не более.

P.S. Эх, пока писал прям чуть ли не прослезился) Ностальгии пост, прямо как будто оказался в 2006-2007 году, когда этим форумом зачитывался. Эхе-хе, куда все ушло.
 
Old  
kerk
k0t
 
kerk's Avatar
Default 1

Quote:
Originally Posted by Core dumped View Post
заменить собственный откровенно куций шаблонизатор vBulletin, заставляющий совершать много лишних действий по типу ручного эскейпинга данных, на один из промышленных стандартов в виде Smarty, Twig, либо любой другой по вкусу. Один раз попробовав нормальный шаблонизатор уже весьма трудно вернуться к тому, что предоставляет vBulletin.
вот это делать не нужно категорически, смарти - гори он в аду
я как то пару раз сталкивался с этим шаблонизатором, nunca mais...
хранить шаблоны в файловой системе? да ладно
самое тормозное на серваке, да и в любом компе - это жесткий диск, и постоянно его дергать при запросе шаблона, скорости движку не прибавит, а даже совсем наоборот
шаблоны из базы запрашиваются и хранятся в памяти при инициализации движка, это граздо быстрей
==
с сериализе - в принципе согласен, давно уже порываюсь все свои скрипты перевести на json, но останавливает не только лень и нехватка времени, но и то, что не у всех есть библиотеки на серваке поддерживающие json, а подпихивать для совместимости довольно объемный файл пхп, не есть гутт

Quote:
Originally Posted by Core dumped View Post
Медиа-аттачи
есть вариант с редактированием файла воблы, что бы картинки отображались гостям (где то уже выкладывал)

Quote:
Originally Posted by Core dumped View Post
PDO же позволит сократить вышенаписанное до
т.е. переменная $username никак не фильтруется?
 
Old  
Core dumped
Продвинутый
 
Core dumped's Avatar
Default 3

Quote:
Originally Posted by kerk View Post
вот это делать не нужно категорически, смарти - гори он в аду
я как то пару раз сталкивался с этим шаблонизатором, nunca mais...
хранить шаблоны в файловой системе? да ладно
самое тормозное на серваке, да и в любом компе - это жесткий диск, и постоянно его дергать при запросе шаблона, скорости движку не прибавит, а даже совсем наоборот
шаблоны из базы запрашиваются и хранятся в памяти при инициализации движка, это граздо быстрей
Смарти я никогда не видел, назвал его потому, что он появился примерно в то же время, что и vBulletin, так что они могли бы не писать свое, а взять готовое. Сам я работал с Twig ну точнее с его "старшим братом" jinja, причем в основном даже не в контексте веба. Очень няшная штука, при всем при этом к тому же даже довольно быстрая (Хотя задачи на скорость у меня никогда не стало).
Нууу, в данном случае есть два типа затрат. Один тип - это затраты ресурсов сервера и второй тип - это затраты времени разработчика на создание и поддержку. В современном мире второе обычно дороже первого, ну так уж вышло. По поводу скорости доступа я бы поспорил (Сами ФС кешируют частые обращения + если прям совсем надо, то можно скидывать результат в какой-нибудь инмемори редис и вообще тогда скорость доступа будет в пределах погрешности). Но на самом деле тут все скоростью доступа не ограничивается. Там же ещё на каждый вызов вызывается eval, который эти шаблоны разбирает через какой-то там strpos или что там было, не помню уже. В то время как Twig, скажем, один раз при запуске компиляет в нативный код и потом уже дергает как php файлы, не тратя времени на разбор. Так что скорость конкретно в данном случае довольно десятое дело, к тому же оптимизируемое. Вот удобство - да.
В целом говорить о производительности в таком разрезе довольно бессмысленно, если там конечно не 1к рпс. Для современного железа и тот и тот подход обычно в пределах погрешности.

Quote:
Originally Posted by kerk View Post
==
с сериализе - в принципе согласен, давно уже порываюсь все свои скрипты перевести на json, но останавливает не только лень и нехватка времени, но и то, что не у всех есть библиотеки на серваке поддерживающие json, а подпихивать для совместимости довольно объемный файл пхп, не есть гутт
json_encode судя по докам часть стандартной библиотеки начиная с 5.2. При это найти этот самый 5.2 так и не удалось, все работают уже начиная с 5.3. Вопрос об отсутствии библиотеки тут, я думаю, довольно второстепенный..


Quote:
Originally Posted by kerk View Post
есть вариант с редактированием файла воблы, что бы картинки отображались гостям (где то уже выкладывал)
Ну как бы да, поэтому я и упомянул в контексте форка. Форк же может править ядро

Quote:
Originally Posted by kerk View Post
т.е. переменная $username никак не фильтруется?
А зачем? Она подготавливается на стороне драйвера базы данных, совершенно не важно что там будет, хоть Bobby '; -- DROP TABLE students, никаких проблем не возникнет. Тут ключевые слова вроде prepared statements, так это называется, если не путаю.
 
Old  
syn
Эксперт
vBSNews
 
syn's Avatar
Default 0

есть одно "но" / форк коммерческого продукта / лицензия
 
Old  
Smalesh
Эксперт
Default 1

Quote:
Originally Posted by Core dumped View Post
По поводу скорости доступа я бы поспорил (Сами ФС кешируют частые обращения + если прям совсем надо, то можно скидывать результат в какой-нибудь инмемори редис и вообще тогда скорость доступа будет в пределах погрешности).
Подтверждаю, обычно для рядовых файликов ФС сама более чем прекрасно кеширует без деградации производительности; проблема наступает когда заканчивается память, но если у нас заканчивается память, проблемы с таблицей в базе будут посерьезней.
 
Old  
YURSHAT
Coder
 
YURSHAT's Avatar
Exclamation [3.6.12] vBulletin 3.6.12 PL2 (update 2) 3

vBulletin 3.6.12 PL2 (update 2)

Исправлены косяки обнаруженные на PHP 5.6:
  • Ошибки уровня E_STRICT
  • Ошибки уровня E_DEPRECATED (устаревший модификатор "\e" в функции preg_replace)
  • Мелкие правки...

Дистрибутив проверен на PHP 5.6.14 (Debian “jessie”)

Last edited by YURSHAT : 11-12-2015 at 03:38 AM.
 
 

Tags
vbulletin 3.6.12, vbulletin 3.6.12 php 5.6

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off




All times are GMT +4. The time now is 04:18 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd.