Любительские сайты на Cotonti: семь бед – один ответ

Далеко не первый год участвуя в работе форумов Котонти, я регулярно наблюдаю одни и те же, мягко говоря, странные моменты, из-за которых общение нередко теряет конструктивный характер и сводится к бесконечным и непродуктивным спорам и даже перепалкам с выяснением отношений.

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

Тренд первый: а вот я так хочу

На форум заходит разработчик-любитель и задает вопрос. Как правило, ответ на такой вопрос прост и очевиден, но топикстартер по никоме не известным причинам отметает абсолютно все ответы и комментарии и сообщает, о том, что решение им найдено или уже известно. Причем, решение это, как правило, самое сложное, самое трудоемкое, и самое… неправильное.

Примеров этому масса, но я приведу самый свежий: одному из участников форумов потребовалось создать на своем сайте раздел Видео. Естественно, самым очевидным стало бы добавление соответствующего раздела в структуру страниц, кастомизация шаблонов, создание необходимых экстраполей и переход к наполнению. Примерное время на подготовку и реализацию зависит от сложности задачи, но в любом случае это вопрос нескольких часов, по крайней мере на начальном этапе. Дальше начинаем наполнение раздела и/или подразделов параллельно с необходимыми доработками.

Как я уже говорил выше, это самое простое и – поэтому – самое очевидное решение. Весь функционал в вашем распоряжении, плюс некоторые другие моменты, которые многие сразу не учитывают. Например, поиск, автоматическое попадание контента в XML- и RSS-поток и другие важные вещи, недостаток которых скажется или сразу или почти сразу.

Именно такие ответы и аргументы и были приведены в ответах топикстартеру. Однако, решение он сформулировал сам, и оно оказалось следующим:

Я буду клонировать модуль Page!

При этом уважаемый коллега тут же признался в том, что кодинг для него – высшая математика, и он совершенно не понимает, что такое хук и как написать свою функцию. После уточняющих вопросов причины такого решения все же были обозначены:

1. Необходимость в “независимых” разделах
2. Желание развивать и документировать, создавать плагины (!!!) под модуль
3. СЕО

Правда пояснений по ним все-таки не последовало. В результате вместо того, чтобы через максимум день предварительной подготовки и кастомизации раздела Видео начать его наполнение, товарищ тратит массу времени на 3 (три!) бесплодные попытки, после чего утыкается в принципиальную проблему: URL’ы склонированного модуля получают лишний УВ (уровень вложенности) и, тем самым, то ли убивают перспективы СЕО, то ли перспективы развития.

Попытки помочь начинающему разработчику модулей и плагинов под него также оказались показательными. Все свелось к простому копированию предложенных вставок кода и ответах в режиме работает / не работает. Даже на тестирование и отладку топикстартера не хватило.

В результате в плюсах имеем только трафик на форумах. Минусов гораздо больше. Но самый главный из них – это то, что данный топик может стать неправильным посылом для более адекватных других начинающих разработчиков сайтов на базе Cotonti. В самом деле, со стороны действительно простая задача выглядит чем-то нереально сложным и монструозным по решению. Явно не аргумент в пользу выбора Котонти.

Тренд второй: дьявол в деталях

Еще одним типичным кейсом в сообществе Котонти стало недавнее обсуждение варианта скрытия формы ответа для просроченного проекта. Речь, естественно, идет о фриланс бирже CMS Works. Впрочем, речь не о конкретике, а о том, насколько действительно мелкие и малозначимые вещи могут вдруг вырастать до уровня глобальных проблем, без которых многие разработчики-любители просто теряют покой и сон.

Вопрос здесь совершенно не в том, что кто-то не желает “помогать по мелочам”, хотя объективных претензий к топикстартерам в таких случаях действительно много:

• даже по мелким задачам вопросы формулируются сложно, невнятно и непонятно,
• пост оформляется то ли безалаберно, то ли безграмотно, то ли с каким-то упорным желанием усложнить понимание проблемы,
• разметка через syntaxhighlighter – один случай на миллион.

Если говорить непредвзято, то надо понимать: и движок Cotonti и биржу создавали далеко не глупые команды разработчиков. Все, что заложено в коде, предназначено для реализаций большинства типовых задач. Поэтому сперва постарайтесь применить типовой функционал и закрыть наиболее принципиальные вопросы. И только после этого “спускайтесь вниз” к менее приоритетным и значимым проблемам, влияние которых на конверсии неудержимо стремится к нулю.

Тренд третий: шаблонизатор – наше всё

Еще один часто наблюдаемый момент: многие считают, что все преимущества Котонти можно реализовать исключительно за счет шаблонизатора coTemplate. Такое утверждение с некоторыми оговорками можно принять. Главное – это наличие у разработчика всех TPL-тегов, необходимых для реализации поставленных задач. Так что применительно к несложным проектам с этим можно и согласиться.

Однако злоупотреблять возможностями шаблонизатора также не стоит. Прежде всего, это инструмент для разумного применения в проекте переменных и TPL-тегов. Нельзя забывать, что coTemplate может выступать и в роли “слабого звена”, особенно если бездумно злоупотреблять его функционалом. 

Даже в рядовых случаях рекомендуется компенсировать влияние шаблонизатора на быстродействие сайта использованием функции статического и xTPL-кэша.

Данный вид заблуждений прежде всего связан с вопросом планирования бюджета для проекта. Если вы разрабатываете хобби-сайт исключительно собственными силами, выбирайте бесплатный функционал и опирайтесь на рациональное использование coTemplate. Если же замахиваться на некий продвинутый или объемный функционал, необходимо понимать, что для его реализации вам все-же понадобится некий финансовый (или, если хотите, мотивационный) ресурс.

Выводы и заключение

Несмотря на все указанные в данной статье нюансы, в сообществе Cotonti вы всегда можете рассчитывать на квалифицированную помощь. Для того, чтобы усилия команды разработчиков не пропадали даром, помните о следующем:

• первое правило разработчика – KISS (keep it short and simple): самым правильным решением, как правило, является самое простое и очевидное,
• чтобы получить правильный ответ, задавайте правильный вопрос,
• учитывайте ваши возможности и ваши запросы,
• планируйте задачи сообразно их приоритетам, не замыкайтесь на малозначимых деталях, мало или вообще не влияющих на конверсии,
• развивайтесь и изучайте не только HTML/CSS, но и PHP/MySQL,
• помните о том, что форумы – это не только средство общения, но и источник информации для ваших коллег и многих начинающих разработчиков.

Пожалуй, это все на сегодня. Обсуждение данной статьи можно продолжить в комментариях.