Не так давно столкнулся с замечательным движком iLance и о нем хотел бы написать свой первый обзор.
Система платная, хотя есть и nulled версии вроде как. На сайте движка www.ilance.com описано как все там замечательно, все отлично настраивается и вообще убермегатру. Маркетологи как обычно постарались и описали все в лучших традициях, даже подготовив демки.
К сожалению мне довелось увидеть эту систему не со стороны красивых админок и замечательных обзоров, а изнутри.Честно говоря я очень давно программирую и мне нравится колупать именно чужой код, это очень обогащает идеями, и я не ожидал увидеть там четкой объекто-ориентированной вылизанной системы, но некоторые решения просто убили на месте... Стоит отметить что iLance сам по себе по тому_что_он_может и что_там_можно_настроить довольно функционален. Действительно, на уровне самой цмски заложена мультиязычность с легкой возможностью настраивания через файлы конфигурации. И первое что отвалилось в процессе установки русской версии была именно она. В программировании мультиязычных сайтов есть 2 основных подхода:
- Каждая языковая версия - это логически отдельный сайт со своей внутренней системой страниц, данных и т.п;
- Структура данных одна и та же, но чуть ли не каждая запись сопровождается полем с идентификатором языка.
Ребята же решили не париться со всеми этими сложными ссылками и прочей лабудой и просто продублировали каждую запись с языковым префиксом: title стал title_en и title_ru к примеру. И действительно зачем напрягаться, если title_en заполнен - значит английская, а нет - русская. И я честно понимаю разработчиков. Если бы я знал, что на сайте будет 2 языковые версии и только они - то в рамках баланса время/деньги действительно не стал бы заморачиваться. Принцип "делай то что нужно, а не то что может быть понадобится потом когда-нибудь а может и нет" знаете ли. Но парни явно забыли, что iLance - это система на продажу. И я не буду писать про расход памяти, про то какая задница добавить новую версию через тупое дублирование всех полей везде с дополнительным языковым префиксом - это хрен с ним, потому что даже эти 2 несчастных языка система не могла сожрать без глюков: Регионы глючили и глючили жестоко... И тут начался мой выход.
Первая попытка установить сайт на локальную площадку с треском провалилась. Мне искренне интересно, какой индусский программист указал для половины полей в каждой таблице not null default null ? Но на удивление это работало на "живом" сайте, и не работало у меня. Любая попытка что-то записать в базу падала на инсерте когда такие поля были не заполнены. А система ведь на продажу, должна запускаться везде, ага 
Признаюсь честно, я не осилил переколбасить все эти поля, успел только то, что касалось моей работы. И как только у меня это получилось полез в код. Тут меня ожидал большой сюрприз 
Как известно, многие продукты, которые выставляются на продажу пишутся на функциях без ООП. Это делается для того, чтобы система действительно работала абсолютно везде, при любой сборке php и на любом сервере. Если это не учитывается - строится мощная объектно-ориентированная архитектура приложения, все абстрагируется, пишутся требования к серверу и т.п. Но не тут. Действительно нет. Разработчики iLance настолько крутые ребята, что используют ООП в лучших традициях Индии. Первым делом я встретил антипаттерн God Object. Объект $ilance действительно настолько крутой что управляет и переменными реквеста, одновременно он и шаблонизатор и хранит настройки и вообще (я до многого не добрался, тут все его фичи описать не могу). Есть у объекта-бога и пару приспешников - объекты некоторых сущностей (функционально это не объекты вообще, а статические либы), некоторых означает примерно 10% сущностей, все же остальное хранится в файле с функциями на 4 тысячи строк и тотальной копипастой.
К слову об объектах. В php никогда не было толком никаких соглашений. Да, были попытки, но такого явного как скажем в java чтобы только camel hump и все, не было. И каждый мог выбрать то что ему нравилось. Но называть классы с маленькой буквы через подчеркивание, увольте.
А ужас нарастал. Вместо хоть какой-нибудь пародии на контроллеры и хотя бы уже черт с ним я бы смирился, чтобы отдельная страница отрисовывалась в отдельном php-файле без классов и функций. Пусть говногод ну да и ладно, в одном месте хотя бы, а значит - разобраться можно. Вместо этого меня встретили файлы по 3-5 тысяч сторок php кода, в очень редких местах были вызовы функций из либ (примерно таких же по объему и каше). Копипаста наполнила проект чуть более чем полностью. Некоторые записи вставляются через либы, а апдейтятся тут же через sql-ник. Кстати, очень много sql-ников и никакой абстракции под их генерацию даже для простейших тупых запросов из серии select * from table where че_то_там. Рендеринг страниц с помощью шаблонизатора идет вперемешку с расово индусским спагетти-кодом.
Кстати о шаблонизаторе. В iLance он есть, но лучше бы его не было. Все что он умеет - это условия (if-else) и циклы (loop). Кстати, я так и не нашел как же в цикл вставить условие 
а все потому, что эти шаблоны никуда не транслируются. Обычно ж как, если есть псевдоязык - он транслируется в php файлик, который затем каждый раз подключается (чтобы не транслировать его еще раз) и уже по внутренностям этого файла можно догадаться о том как нужно писать в шаблонах чтобы оно работало. Но сохранения результатов нет, они есть в памяти черт знает где и потом по всему этому счастью происходит eval. Вот так-та.
Казалось бы, что уже после всего, что я увидел, сложно наляпать еще где-то. Я искренне в это верил пока не узнал как в iLance происходит работа с css. Надо отметить что во всех проектах, с которыми я работал (а это порядка 80 штук от самых мелких до монстров) я не встречал такого. Разработчики iLance действительно гении, они первые придумали хранить стили в базе данных! Нет, они не хранят там целые файлы стилей, это было бы еще полбеды. Каждый css-класс - это запись в базе. Имя записи к примеру .blog и код стиля padding: 0px; к примеру. А потом это все собирается в css-ку, которая ложится в кеш и подключается при запуске страниц. Редактирование этого всего - только через админский интерфейс. А в нем мегафишка! : область видимости стилей можно указать. Например можно чтобы определенный стиль был и в админке и на фронте, а другой только на фронте. Почему нельзя было сделать 3 файла скажем global.css, front.css и admin.css, как делают все нормальные люди? Да потому что там есть подсказки для стандартных стилей, наверное для того чтобы люди непросвященные в css легко могли добавлять и менять там что-то свое. Возможно, разработчики и не знали, но мы то точно знаем, что ни один нормальный человек, который в этих ваших стилях ничего не понимает никогда в жизни не попрется туда что-то править, а если уже человек решил разобраться в css, то в самих файлах ему будет куда проще (хотя бы потому что все доки именно по .css-файлам, а не по хренпойми чему), не говоря уже о профессиональных верстальщиках, которые скорее всего и будут делать редизайн в случае чего.
Подводя итоги моей работы с ее величеством iLance CMS хочу отметить, что, хотя она и ужасная внутри, работать с ней можно. Если ничего не нужно менять - работать она будет как 95% аналогичных систем по всему интернету. Парням из iLance искренне хочется пожелать хотя бы иногда включать мозг и прочитать пару книжек по ООП, их менеджерам - никогда не нанимать студентов, тем, кто прочитал эту статью и думает работать с этим или нет, подсказать уже нечего - вы и так молодцы, что не ограничиваетесь только тем что пишут на сайте самой cms-ки о ней, ну а программистам - никогда не повторять этих ошибок.