getSettingsTimezone()
KarelWintersky opened this issue · comments
Эта функция вызывается в :
/classes/modules/viewer/Viewer.class.php
/application/classes/actions/ActionSettings.class.php
/application/classes/modules/topic/entity/Topic.entity.class.php
/application/classes/modules/user/mapper/User.mapper.class.php
Но её определения не существует. Нигде. Нигде вообще. Ни в 1.0.3, ни в 2.0.
Нужно еще учитывать, что есть магические геттеры сеттеры.
Это магическая функция. Такой вызов возвращает значение поля settings_timezone через обратное преобразование имени вызываемого несуществующего метода к имени свойства. Тоже с именем set* устанавливает свойство. Одна из ебанутых "фич" данного движка. Если знать как это работает, можно сэкономить себе время, типа не надо добавлять методы. Но нормальные люди от этого подхода слегка охуевают.
Это магическая функция. Такой вызов возвращает значение поля settings_timezone через обратное преобразование имени вызываемого несуществующего метода к имени свойства. Тоже с именем set* устанавливает свойство. Одна из ебанутых "фич" данного движка. Если знать как это работает, можно сэкономить себе время, типа не надо добавлять методы. Но нормальные люди от этого подхода слегка охуевают.
Вы здесь, чтобы помочь или кого нибудь оскорбить?
Конечно помочь.
- Это не геттер, не сеттер и не магический метод.
- Но я слегка охуел, увидев в этой портянке
if ($this->oDb->query($sql, $oUser->getPassword(),
$oUser->getMail(),
$oUser->getSkill(),
$oUser->getDateActivate(),
$oUser->getDateCommentLast(),
$oUser->getRating(),
$oUser->getCountVote(),
$oUser->getActivate(),
$oUser->getActivateKey(),
$oUser->getProfileName(),
$oUser->getProfileSex(),
$oUser->getProfileCountry(),
$oUser->getProfileRegion(),
$oUser->getProfileCity(),
$oUser->getProfileBirthday(),
$oUser->getProfileAbout(),
$oUser->getProfileDate(),
$oUser->getProfileAvatar(),
$oUser->getProfileFoto(),
$oUser->getSettingsNoticeNewTopic(),
$oUser->getSettingsNoticeNewComment(),
$oUser->getSettingsNoticeNewTalk(),
$oUser->getSettingsNoticeReplyComment(),
$oUser->getSettingsNoticeNewFriend(),
$oUser->getSettingsTimezone(), //@todo: DECLARED NOWHERE!!!
$oUser->getId())) {
return true;
}
25 декларированных методов, нормально объявленных в User.entity.class.php , например:
public function getSettingsNoticeNewTalk()
{
return $this->_getDataOne('user_settings_notice_new_talk');
}
и единственный "магический" метод, который возвращает неизвестно что, объявлен неизвестно где и реализованный неизвестно как.
Ребята, это хуёвая магия.
И, да, это баг.
@KarelWintersky баг в чём?
Изначально поддержки magic методов не было, поэтому описывались set/get в классе. В какой-то версии появилась возможность не объявлять такие методы - они мапятся на поле в таблице в БД. Далее уже не все методы (поля таблиц) объявлялись явно. Бага в этом нет, другое дело, что по хрошему такие методы нужно было описать в phpdoc к классу.
в идеологии баг, в идеологии. Раз уж в тред пришел автор движка - прошу, скажите мне,
ПОЧЕМУ нигде не используется композер?
ПОЧЕМУ нигде не используюся неймспейсы (появившиеся раньше, чем первая версия LS)
ПОЧЕМУ такой.. такая больная схема наследования классов:
Пример из плагина, нормального, работающего:
class PluginBlacklist_ModuleUser extends PluginBlacklist_Inherit_ModuleUser {
...
$this->Message_AddErrorSingle();
}
Магический методо в классе? Нету. В Классе-предке? Нет такого класса.
Это же пиздец!
они мапятся на поле в таблице в БД.
Где код маппера?
Едем дальше. Официальный плагин AceAdminPanel
class PluginAceadminpanel_ActionAdmin extends ActionAdmin {
...
$this->Lang_AddLangJs();
...
}
Где объявлен Lang_AddLangJs() ?
Идем вверх по иерархии классов.
/classes/actions/ActionAdmin.class.php
class ActionAdmin extends Action {
// нету, но тоже вызывается.
}
/engine/classes/Action.class.php
// Разумеется, тоже нету
Ищем по ВСЕМУ проекту.
Везде вызывается, нигде не объявляется.
Как, блять, человеку должно прийти в голову, что НА САМОМ ДЕЛЕ это вызов метода AddLangJs из класса ModuleLang, объявленного... нет, не в файле ModuleLang.php.
В файле engine/modules/lang/Lang.class.php
Что курил автор?
@KarelWintersky что за официальный плагин?
AceAdmin это хороший пример того как НЕ надо писать плагины для лс.
А для тех кто не знаком со структурой лс и их магических вызовов
это работает так:
$this->Плагин_Модуль_Функция(Аргументы)
$this->Модуль_Функция(Аргументы)
Например
$this->PluginPage_Page_GetPageById($pageId)
$this->Topic_GetTopicById($pageId)
Если после этого не въехали - не лезте в код лс
Окей. Покажите пример того, как надо писать плагины для LS ?
Чтобы я вот посмотрел и смог написать небольшой плагин для своего проекта.
Ну совсем небольшой. Прямо малюсенький - после создания поста должна вызываться некая функция с URL-ом к этому посту. В идеале - с nice-url.
Только есть проблема - niceurl управление не возвращает после своего вызова, хотя в документации прямо сказано, что нужно делать return.
Если после этого не въехали - не лезте в код лс
Если бы:
А) коммьюнити было активно и разработчики реагировали на баги
ИЛИ
Б) для LS2 было больше 3 плагинов (исключая адски дорогие платные... и ненужные)
То я бы не лез в код LS.
А для тех кто не знаком со структурой лс и их магических вызовов
Это плохая магия.
Архитектура проекта была заложена 10 лет назад, именно такой, именно в этом было его отличие от других реализаций и именно так мне нравилось/умелось писать код тогда. Это нужно принять как данность, понять как работает и работать с этим (если требуется). Но называть данную реализацию багом - как-то странно.
Пример простого плагина - https://github.com/livestreet/lsplugin-lssoft_feedback
Здесь http://docs.livestreetcms.com есть скринкасты, которые помогают понять основной принцип работы кода LS. А вот самый первый пост на эту тему - http://livestreet.ru/blog/dev_documentation/113.html
и именно так мне нравилось/умелось писать код тогда
А сейчас? Слишком много переделывать, нехай работает как есть?
и работать с этим (если требуется).
К сожалению. Если бы была возможность перейти на другой движок (если бы он был, точнее) - с радостью. Если бы была возможность написать свой под конкретную задачу - с радостью, но нет, возможности нет.
Приходится грызть кактус. Причем кактус версии 1.0.3.
Плакать не нужно. Работай с чем дают. Livestreet поможет тебе понять магию php. А psr стандарты и уход от магии будут внедрятся. План заложен. Нужно только расписать
Магия PHP не в том, чтобы использовать костыли
На самом деле альтернативы есть, особенно если не привязываться к слову "блог", это всего лишь слово, которое легко заменить не что угодно, например "раздел". Тем более что т.н. "персональные" блоги, которые строго говоря и должны называться блогами, в лс - невнятное убожество, а "коллективные" блоги это вообще нонсенс, и следствие скудной фантазии создателей хабра. Для многопользовательских проектов можно использовать форумные движки. Discourse, Flarum, в крайнем случае XenForo. Там и сообщество и плагины и скины и все что хочешь. И пилить придется в разы меньше. Если же пользователей не так много (а это 99.9%), то еще проще.
Ну, у нас проект - ролевая социальная сеть. К формату "хабра" все привыкли. Просто привыкли.
Если я сейчас скажу "переходим на форумный формат" - разбегутся последние пользователи. И так-то за 5 лет площадка растеряла аудиторию.
Сейчас вот я её получил в свои руки и стараюсь допиливать.
На самом деле у меня есть представление об "идеальной" в моем понимании ролевой площадке. Ни один из движков это не реализует "искаропки". Ни Doscourse, ни Flarum, ни XenForo.
Следует еще отметить, что денег на доработку у нас нет, все на чистом энтузиазме. Денег нет и не будет, но мы держимся :)
По хорошему, то, что я хочу, действительно, проще написать с нуля совсем. Благо фреймворки сейчас предоставляют очень богатые возможности. Но в одиночку это делать очень тоскливо.
@inliquid пойдемте лучше в личку или телеграм. Мыло в профиле, ID в телеге такой же как здесь.
class PluginHttpsdetect_ModulePage_EntityPage extends PluginHttpsdetect_ModulePage_EntityPage_Inherit_PluginPage_ModulePage_EntityPage {
}
Отличное название класса! Магия костылей в действии.