Сделал для вас простенький плагин. Еще не разобрался, как делать страницы админки, так что настраивать его придется вручную, задав в config/config.php ссылку на логотип и цвет. Для более тонкой настройки можно подправить manifest.json согласно документации Яндекса.
Ну хоть вы-то можете привести пример сайта, где такое же узнаваемое вертикальное меню на фротнэнде? Потому что badkidddd затрудняется это сделать, показывает зачем-то шаблоны админок. И вообще, что за личные наезды? Я тоже могу сказать, что если у вас есть сайт, то там, наверное, табличная верстка и скрипты на vbscript-е.
Честно пролистал всю первую страницу выдачи Гугла. Из более чем сотни вариантов вертикального меню похож на хабровский всего один. При этом заметно, что ваш вариант на оригинал похож больше. Все так, как я говорил — этот вариант меню крайне редок, и вам не повезло влезть на одну поляну с сайтом-миллионником :) А Лайвстриты могут быть и не похожими на Хабр, как тот же литературный сайт в соседнем посте, просто вы со своим дизайном сделали так, чтобы не узнать оригинал было невозможно. На этом спор закончу — каждый сам творец своего (не)счастья.
Я ж говорил, движок начался с передирания хабра, с чего бы ему не быть похожим? Вы просто добавили последние штрихи к этому сходству. Кстати, вполне возможно, что Alto в будущем тоже перейдет на хабы %)
С themeforest вы хитрите, указав раздел шаблонов админки. С тем, что в админках такие шаблоны встречаются, я вроде бы и не спорю — даже Битрикс в таком стиле уже переделали, в подражание мобильным приложениям. Я другое прошу — указать реальные сайты, у которых такое же сворачивающееся меню с иконками на фронтенде.
Забавная у вас аудитория — таких графоманистых срачей, когда ради поддевания соперника пишутся не помещающиеся на экран комменты, я не видел даже на Самиздате. Вообще сам факт, что у вас там без стеснения общаются люди, уже достаточен, чтобы сказать, что сайт очень хорош.
Что резануло глаз — явное несоответствие дизайна наполнению сайта. К примеру, у вас на главной очень короткие посты (между прочим, обрезанные как попало, обычно на середине предложения, что лучше бы исправить), а дизайн рассчитан на посты большие и с картинками. Получается, что жирные и контрастные «шапки» постов притягивают к себе внимание, и читать маленькие заметки становится очень неудобно, примерно как считать полоски на зебре.
Ну и непонятно, почему у вас некоторые посты повторяются три раза. Вы их откуда-то транслируете?
Уверяю вас, я далеко не последний, кто обвинит вас в нехорошем. Так как у вас аудитория во многом пересекается с Хабром, значительное число пользователей вы потеряете просто потому что в вашем сайте они увидят очередной хабраклон. Что же до того, где и чем вы вдохновлялись — это не суть важно. Лично я такой тип дизайна много раз видел в мобильных приложениях, но на фротнэнде сайта — ровно два раза (если считать проекты ТМ за один).
Кстати, я отписался-то только потому, что меня изрядно развеселило это реальное или мнимое передирание дизайна. Дело в том, что Лайвстрит сколько-то лет назад начинался именно с клонирования Хабра. Так что вы просто продолжаете добрые традиции… :)
ИМХО: Выкиньте к чертям свои iphone и телефоны прошлого века и тогда поймете, что адаптивные шаблоны это полное убожество и сайты с ним лично моего внимания не заслуживают.
Поддерживаю!
Даже шаблон этого сайта — живая антиреклама адаптивности, т.к. он одинаково плохо работает на любом «мобильном» разрешении: везде или заползают друг на друга блоки, или появляются нечитаемые шрифты, или пропадает навигация.
А главное — я уже крах подобного явления видел. В начале нулевых, когда пытались делать программы, в неизменном виде запускающиеся на разных ОС. Тогда это закончилось тихой катастрофой, так как системы слишком между собой отличались, и никто, за редким исключением, не захотел пользоваться получившимися программами. Очередные сотни тысяч человеко-часов были потрачены впустую. А тут не просто другая ОС, а другой способ взаимодействия с пользователем и намного более примитивные, чем в то время, средства.
Чего реально добились адаптивщики — так это усложнения всего и вся. Я, например, только с их появлением стал с трудом читать код сайтов. Да и компьютер, на котором я прошел Crysis, уже не способен без рывков прокручивать даже некоторые информационные сайты.
Проверьте, работают ли ссылки вида «вашсайт/blogs/», «вашсайт/people/» и подобные им. Если будут выдавать, что страница не найдена — у вас не работает mod_rewrite (с этим к хостеру) или поврежден/отсутствует файл .htaccess (восстановить из дистрибутива).
Список просто ужасает. Даже если взять за основу стандартный шаблон, каждую из этих страниц придется дополнительно тестировать на всех поддерживаемых устройствах и браузерах… Дизайнерам будет тяжело отрабатывать свой хлеб. Вернее, не так — уникальный дизайн золотым выйдет. Да и стоковый просто так натянуть не получится.
Кроме того, длинный список страниц — отнюдь не то, что лично мне, как разработчику, хотелось бы видеть. Он вообще был бы неактуален, если бы был некий стандартный набор css-классов, на который можно было бы опереться при доработке стандартного дизайна и создании дополнений: всякие панельки, кнопки, формы и прочая дребедень.
Не воспринимайте это за наезд лично на себя, просто я одно время рассматривал разработку дополнений под opencart — другой пошедший простым путем движок — и там даже с учетом ecommerce направленности она не окупалась, т.к. совместимость со сторонними шаблонами настолько плоха, что почти что каждое дополнение приходилось бы дорабатывать под клиента.
Заранее скажу, что полного решения этой проблемы не знаю. Частичное, виденное мною неоднократно — провести стандартизацию css-классов и паттернов элементов управления для возможности доработки дизайне через css (ага, как в zen garden), сделать наследование одного шаблона от другого, привить дизайнерам мысль, что *не надо* в своих шаблонах изобретать каждую форму заново.
Таскать за собой все возможные модальные окна плохо. Пример с формой логина: если человек не хочет логинится, то она подгружается в код и простаивает; если же у него кончилась сессия и он попытается отправить коммент, то тут-то ему форма и понадобится, но не судьба — он, типа, уже залогинен и её нет. В результате человек получает ошибку и грязно ругается.
P.S. Есть мелкая бага в форме логина/регистрации: инициализация капчи навешена на щелчок по кнопке «регистрация», так что если открыть форму по кнопке «вход» и потом перейти на вкладку регистрации, картинка с капчей пустая. Лечится буквально одной строкой в нужном месте.
Да, в перспективе хотелось бы уйти от этого, и даже есть некоторые наработки
О, здорово. Рад, что не я один так думаю. Я бы сделал немного не так, как у них, добавив в базовые классы что-то типа такого (псевдокод, сильно упрощенный):
function __get($name) {
$this->$name = $name::getInstance();
return $this->$name;
}
Тогда первый вызов модуля станет просто дешевым (не будет кучи обработок строк), а остальные будут бесплатны (т.к. ссылка на модуль пропишется в переменную и __get повторно вызываться не будет). Насколько я понимаю, такое упрощение сэкономит тысячи вызовов функций на каждую страницу (в цифрах это прирост производительности где-то на 1/4). А для подсказок в ide там же прописать имена классов всех стандартных модулей через @var.
Кстати, переход на такую схему совсем не сложен, достаточно написать парсер, который перепишет все вызовы на новый синтаксис. Совместимость со старым можно оставить, тогда писатели модулей не пострадают.
Но, как вы правильно заметили, сейчас другие приоритеты — отловить все баги и поскорее выпустить релиз. Я просто хочу сказать, что такое изменение — не такая уж титаническая работа, как кажется.
Структура папок…
Почитаю, спасибо. Вообще, такие вещи стоит вынести в какой-нибудь faq. Ну или сделать что-то типа вики или вопросов-и-ответов.
Юзать PDO в чистом виде все равно не удобно, нужна обертка по любому
Вообще, неудобства вы преувеличиваете — напрямую база используется относительно мало (если искать строку «oDb->», найдется файлов на 300кб) и в абсолютном большинстве случаев это просто запросы с подстановкой. Кроме того, библиотека слабовата, и ей все равно нужна дополнительная обертка. Например, вот от таких «паттернов» явно надо избавляться:
Ну и, чисто теоретически, кэширование, профилирование и логирование запросов все-таки ближе к приложению, чем к сторонней библиотеке.
Думаю, вместо dbsimple нужно взять что-то типа zend_db, где простые select-ы реализованы методами. Подобные простыни кода тогда сократятся вдвое-втрое.
И еще, по-моему mapper-ы можно сделать удобнее и производительнее, если снабдить их описаниями таблиц: методы для CRUD тогда не нужно будет прописывать вручную, плагинами можно будет расширять таблицы, не боясь, что ядро потеряет какие-то поля, а если сделать двойную буферизацию полей, то в запросы на сохранение будут передаваться только измененные данные (сумбурно, постараюсь потом более развернуто объяснить идею).
А что за патч? Только под Виндой он нужен?
Да даже не патч, а хак. У Винды есть трудноуловимый баг, когда она лезет резолвить 'localhost' в интернет, причем делает это медленнее, чем обычно (у меня получалось полсекунды-секунда). Сейчас воспроизвести не могу, но с первой публичной версией движка я на него наткнулся — почему-то смена в конфиге 'localhost' на '127.0.0.1' не помогала — и я тупо прошил этот адрес в библиотеке, сразу после парсинга DSN. На Линуксе с этим не сталкивался ни разу.
Иногда критика высказывается в не очень приятной форме
Сам такой критики не получал, но да, было бы неприятно. Исключение делаю для одинэсников и битриксойдов — у них спеси и глупости такие вагоны, что грех их не попинать :)
Потихоньку осваиваюсь с движком (и правлю баги — по-моему, далек он ещё от релиза), но очень не хватает информации.
Есть ли где-нибудь заметки по архитектуре движка и, главное, причинах принятых при её разработке решений?
От некоторых просто корежит:
Способ вызова методов хелперов через подчеркивание безнадежно ломает подсветку синтаксиса во всех ide.
Структура папок… таинственная. Без проводника в ней можно заблудиться и погибнуть.
Повсеместно используется DbSimple, хотя на всех хостингах уже давно поддерживается PDO (терпеть не могу Котерова, а сама библиотека у меня занимается откровенным вредительством, без мелкого патча на windows она тормозит движок почти на секунду).
wiid.ru/profile/admin/created/topics/ и habrahabr.ru/users/milfgard/topics/
wiid.ru/people/ и habrahabr.ru/users/
wiid.ru/blogs/ и habrahabr.ru/hubs/
Я ж говорил, движок начался с передирания хабра, с чего бы ему не быть похожим? Вы просто добавили последние штрихи к этому сходству. Кстати, вполне возможно, что Alto в будущем тоже перейдет на хабы %)
С themeforest вы хитрите, указав раздел шаблонов админки. С тем, что в админках такие шаблоны встречаются, я вроде бы и не спорю — даже Битрикс в таком стиле уже переделали, в подражание мобильным приложениям. Я другое прошу — указать реальные сайты, у которых такое же сворачивающееся меню с иконками на фронтенде.
Что резануло глаз — явное несоответствие дизайна наполнению сайта. К примеру, у вас на главной очень короткие посты (между прочим, обрезанные как попало, обычно на середине предложения, что лучше бы исправить), а дизайн рассчитан на посты большие и с картинками. Получается, что жирные и контрастные «шапки» постов притягивают к себе внимание, и читать маленькие заметки становится очень неудобно, примерно как считать полоски на зебре.
Ну и непонятно, почему у вас некоторые посты повторяются три раза. Вы их откуда-то транслируете?
Кстати, я отписался-то только потому, что меня изрядно развеселило это реальное или мнимое передирание дизайна. Дело в том, что Лайвстрит сколько-то лет назад начинался именно с клонирования Хабра. Так что вы просто продолжаете добрые традиции… :)
Даже шаблон этого сайта — живая антиреклама адаптивности, т.к. он одинаково плохо работает на любом «мобильном» разрешении: везде или заползают друг на друга блоки, или появляются нечитаемые шрифты, или пропадает навигация.
А главное — я уже крах подобного явления видел. В начале нулевых, когда пытались делать программы, в неизменном виде запускающиеся на разных ОС. Тогда это закончилось тихой катастрофой, так как системы слишком между собой отличались, и никто, за редким исключением, не захотел пользоваться получившимися программами. Очередные сотни тысяч человеко-часов были потрачены впустую. А тут не просто другая ОС, а другой способ взаимодействия с пользователем и намного более примитивные, чем в то время, средства.
Чего реально добились адаптивщики — так это усложнения всего и вся. Я, например, только с их появлением стал с трудом читать код сайтов. Да и компьютер, на котором я прошел Crysis, уже не способен без рывков прокручивать даже некоторые информационные сайты.
Кроме того, длинный список страниц — отнюдь не то, что лично мне, как разработчику, хотелось бы видеть. Он вообще был бы неактуален, если бы был некий стандартный набор css-классов, на который можно было бы опереться при доработке стандартного дизайна и создании дополнений: всякие панельки, кнопки, формы и прочая дребедень.
Не воспринимайте это за наезд лично на себя, просто я одно время рассматривал разработку дополнений под opencart — другой пошедший простым путем движок — и там даже с учетом ecommerce направленности она не окупалась, т.к. совместимость со сторонними шаблонами настолько плоха, что почти что каждое дополнение приходилось бы дорабатывать под клиента.
Заранее скажу, что полного решения этой проблемы не знаю. Частичное, виденное мною неоднократно — провести стандартизацию css-классов и паттернов элементов управления для возможности доработки дизайне через css (ага, как в zen garden), сделать наследование одного шаблона от другого, привить дизайнерам мысль, что *не надо* в своих шаблонах изобретать каждую форму заново.
P.S. Есть мелкая бага в форме логина/регистрации: инициализация капчи навешена на щелчок по кнопке «регистрация», так что если открыть форму по кнопке «вход» и потом перейти на вкладку регистрации, картинка с капчей пустая. Лечится буквально одной строкой в нужном месте.
на
Тогда первый вызов модуля станет просто дешевым (не будет кучи обработок строк), а остальные будут бесплатны (т.к. ссылка на модуль пропишется в переменную и __get повторно вызываться не будет). Насколько я понимаю, такое упрощение сэкономит тысячи вызовов функций на каждую страницу (в цифрах это прирост производительности где-то на 1/4). А для подсказок в ide там же прописать имена классов всех стандартных модулей через @var.
Кстати, переход на такую схему совсем не сложен, достаточно написать парсер, который перепишет все вызовы на новый синтаксис. Совместимость со старым можно оставить, тогда писатели модулей не пострадают.
Но, как вы правильно заметили, сейчас другие приоритеты — отловить все баги и поскорее выпустить релиз. Я просто хочу сказать, что такое изменение — не такая уж титаническая работа, как кажется.
Почитаю, спасибо. Вообще, такие вещи стоит вынести в какой-нибудь faq. Ну или сделать что-то типа вики или вопросов-и-ответов.
Вообще, неудобства вы преувеличиваете — напрямую база используется относительно мало (если искать строку «oDb->», найдется файлов на 300кб) и в абсолютном большинстве случаев это просто запросы с подстановкой. Кроме того, библиотека слабовата, и ей все равно нужна дополнительная обертка. Например, вот от таких «паттернов» явно надо избавляться:
Ну и, чисто теоретически, кэширование, профилирование и логирование запросов все-таки ближе к приложению, чем к сторонней библиотеке.
Думаю, вместо dbsimple нужно взять что-то типа zend_db, где простые select-ы реализованы методами. Подобные простыни кода тогда сократятся вдвое-втрое.
И еще, по-моему mapper-ы можно сделать удобнее и производительнее, если снабдить их описаниями таблиц: методы для CRUD тогда не нужно будет прописывать вручную, плагинами можно будет расширять таблицы, не боясь, что ядро потеряет какие-то поля, а если сделать двойную буферизацию полей, то в запросы на сохранение будут передаваться только измененные данные (сумбурно, постараюсь потом более развернуто объяснить идею).
Да даже не патч, а хак. У Винды есть трудноуловимый баг, когда она лезет резолвить 'localhost' в интернет, причем делает это медленнее, чем обычно (у меня получалось полсекунды-секунда). Сейчас воспроизвести не могу, но с первой публичной версией движка я на него наткнулся — почему-то смена в конфиге 'localhost' на '127.0.0.1' не помогала — и я тупо прошил этот адрес в библиотеке, сразу после парсинга DSN. На Линуксе с этим не сталкивался ни разу.
Потихоньку осваиваюсь с движком (и правлю баги — по-моему, далек он ещё от релиза), но очень не хватает информации.
Есть ли где-нибудь заметки по архитектуре движка и, главное, причинах принятых при её разработке решений?
От некоторых просто корежит:
Способ вызова методов хелперов через подчеркивание безнадежно ломает подсветку синтаксиса во всех ide.
Структура папок… таинственная. Без проводника в ней можно заблудиться и погибнуть.
Повсеместно используется DbSimple, хотя на всех хостингах уже давно поддерживается PDO (терпеть не могу Котерова, а сама библиотека у меня занимается откровенным вредительством, без мелкого патча на windows она тормозит движок почти на секунду).