Kohana *

Всем привет. С момента написания последней статьи в системе произошло много изменений, о которых хотелось бы рассказать.

Лет пять назад подсел на разработку сайтов, причем чисто из интереса к вебу. Хотелось осознать, как их делать и делать лучше, чем другие. Начиналось всё это, как и для большинства разработчиков, с простого познания HTML, CSS и, конечно, популярных CMS, таких как Joomla, Wordpress и Data Life Engine. По мере роста приходилось углубляться в Javascript и, конечно, в мой любимый сейчас PHP. Но все шло не так быстро, как хотелось. Тренируясь на простом, хотелось понять сложные вещи. PHP поначалу плохо давался, но характер взял верх и все же через некоторое время написал что-то вроде похожее на мини-социальную сеть.

Ну а затем пошло-поехало: ООП, MVC и, наконец, пришло время покорять фреймворки. На тот момент самыми известными для меня были Zend, Kohana и CodeIgniter. Позже узнал о Symphony и YII. Выбор пал на Kohana, т.к. для новичка была проще в освоении и с нормальной документацией. Ну и недостатков в принципе для себя не видел в этом фреймворке.

Введение

Всем привет, в этой статье я постараюсь кратко рассказать о компонентах, которые составляют архитектуру CMS, их много (думаю все они не поместятся в статью), контроллерах, модулях, плагинах и организации подключения css, js файлов.

Всем привет, на Хабре уже вот как 6 лет и только сейчас решился написать свой первый пост, хотя до сих пор не уверен что это хорошая идея.

Предисловие

Уже более 6 лет я занимаюсь разработкой web приложений, начинал с верстки, javascript, php, python и т.д., в общем за все время я прошел все этапы создания сайта от дизайна в фотошопе и заканчивая созданием полноценного сайта.

Уже много описано про memcache, однако я помучался прежде чем нашел оптимальный вариант для одного проекта на PHP, достаточно ресурсоемкого с большим объемом расчетов в Kohana.

Memcache пришлось отфутболить сразу же, так как когда ключей набегает пару сотен, нереально отследить, когда и какой ключ нужно убить. Смотрел в сторону MemcacheTag, где применено использование тэгов для объединения нескольких ключей, однако он оказался слишком сырым и весьма неудобным для работы. В конце концов был найден самый, на мой взгляд, оптимальный вариант работы с memcached.

Описание принципа работы данной технологии лучше всего посмотреть здесь или в первоисточнике.

Я же напишу как подключать и использовать в фреймворке Kohana, каким образом отследить ключи кэшей и собственно протестировать как работает кэширование в проекте.

Итак, начнем:

Здравствуйте. Наконец то настал тот день, когда модуль приобрел те очертания к которым я стремился. В связи с этим вышел beta релиз, и я бы хотел рассказать вам, что нового появилось в функционале kohana-form.

Первая статья — habrahabr.ru/post/216187

Здравствуйте. Этой статьей я хочу презентовать свой модуль форм для фреймворка Kohana, который написал вдохновившись аналогичным модулем для Django.

Я не буду глубоко вдаваться в предыстории и размышления, а перейду сразу к делу. Сначала опишем недостатки:

• Модуль сырой. Это конечно же не значит что он ничего не умеет, и совершенно бесполезен, это значит лишь то что он требует масштабирования и небольшого рефакторинга. А так же работы над документацией.
  
• Насчет рефакторинга. Я искренне старался держать код в чистоте, и чаще всего у меня даже получалось это сделать, однако никто не идеален, и небольшому количеству мест не помешала бы работа напильником.
  
• Не хватает некоторого количества некритичного функционала.
  

Достоинства:

• Сохранилась распределенная структура которую можно наблюдать в django forms. Форма состоит из экземпляров класса Field, которые в свою очередь связаны с классом Widget. Благодаря этому открываются богатые возможности для кастомизации.
  
• Автоматическая генерация форм из ORM моделей с валидацией данных и автоматическим сохранением данных из POST.
  
• Каждый виджет — это дефолтные кохановские view, что позволяет без особых проблем создавать новые темы для виджетов или быстро корректировать имеющиеся. И для этого не потребуется лезть в исходные коды самого модуля.
  

Подробности под катом.

На моём сайте в определенный момент очень остро встал вопрос организации мультиязычности, причём речь шла не о 2-3 языках, а о том, чтобы перевод сайта на другой, абсолютно любой язык мог быть осуществлен за считанные минуты. При этом у каждого языка должен был быть уникальный адрес, то есть домен/ru/, домен/en/ и т.п. Информации в сети на эту тему не так много(может я плохо искал?) и мне пришлось думать самому. Хотя моё решение довольно простое и многим может показаться очевидным, я всё равно приведу его, надеюсь кому-нибудь оно будет полезно. Сразу предупреждаю, что необходимо мало-мальское представление о фреймворке kohana 3.

В Кохане встроен модуль авторизации пользователей. В базе уже есть таблица с ролями. Но пошарив по пространствам интернета я так и не нашел как же удобно сделать разграничение прав доступа. Поэтому предлагаю Вам свое решение этой задачи.

Доброго времени суток, Хабрасообщество!
Недавно задался целью сделать поиск на своем сайте, написанном на Kohana Framework. Решил использовать именно морфологический поиск, т.к. считаю его более правильным (относительно полнотекстового поиска с применением LIKE). Поиски готовых модулей для Kohana с требующимся функционалом не увенчались успехом, но я нашел отличную библиотеку: phpMorphy, которая замечательно подошла для решения моих задач.

В данной статье я бы хотел поделиться знаниями о том, как устроены, для чего нужны и что из себя представляют packages(далее пакеты) в Fuelphp. Прошу помочь сравнить реализацию и возможности пакетов Fuelphp с аналогами из других фреймворков. Думаю всем будет интересно узнать мнение адептов Simfony2 и Yii по этому поводу, милости просим, кидайте свои выкладки в комменты. Далее в примерах будет рассмотрен пакет fuel-ninjauth

Intro

Хотел было почитать на хабре об изменениях в новом релизе замечательного фреймворка Kohana и не обнаружил упоминаний об этом. Исправляю ситуацию.

ORM, несомненно, мощная и удобная вещь, но запросы генерируются не только не всегда оптимальные, но еще и лишние. При создании объекта модели ORM должен знать информацию о всех полях соответствующей таблицы БД. Что приводит к нежелательным запросам к БД.

Вчера наш портал, написанный на Kohana, подвергся успешной атаке. Мысль, что грешить надо именно на уважаемый фреймворк, безопасность в котором далеко не на последнем месте, сначала даже не обсуждалась. Программке, которой сканировали наш сайт, потребовалось порядка 95 тысяч запросов и 5 часов времени, чтобы найти эту уязвимость.

С недавних пор, примерно год назад, перед нашей командой стояла задача выбора PHP фреймворка для реализации «серьезных» проектов. Почему в итоге выбрали Kohana, я уже и не помню, скорее всего интуитивно, подкупившись на его простоту, легкость и не высокий порог входа. На тот момент текущая версия была 3.0 и мы полные энтузиазма вгрызлись в документацию.

В любом «серьезном» проекте перед разработчиком встает задача генерации уменьшенных копий загружаемых пользователем картинок. Почитав различные HOW TO, мы решили использовать генерацию превью при запросе изображения через url.

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

Поэтому было решено поискать на хабре готовые библиотеки или методики по борьбе со спамом.

Рассмотрим заготовку для сайтов, обладающую хорошими возможностями для дальнейшего расширения. Будут указаны её основные особенности, и подробно описан процесс установки.
Если представленная заготовка окажется полезной большинству пользователей, о чем они не преминут указать в комментариях, тогда, скорее всего, отдельные её модули и особенности будут рассмотрены в дальнейшем.
Некоторые функции, код и отображение данных используются больше в показательных целях, чем для практического применения в рамках создания рабочего сайта.
В представленном виде заготовку уже можно применять для создания простых сайтов, но с неплохими возможностями для расширения.

Если вы используете Kohana, то скорее всего уже видели модуль DebugToolbar. Испробовав его на нескольких проектах, стало понятно, что его возможностей явно не хватает. А при использовании Ajax запросов данный модуль становиться вообще бесполезным.

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

Не так давно на Хабре была статья про виджет авторизации uLogin.
Что мне в нём очень понравилось, это возможность указать обязательные поля, при этом, в случае их неполучения от провайдера, пользователю предлагается врчуную их заполнить. Так возникло желания написать модуль в Kohana, который позволял бы легко осуществлять регистрацию пользователя с помощью виджета uLogin.

Приветствую уважаемое хабросообщество!

В предыдущей публикации я рассказывал о своем бесплатном видеокурсе по Kohana 3 для начинающих, где опубликовал первые 15 видеоуроков.

На прошлой неделе я закончил работу над видеокурсом. Видеоуроков получилось 27. Я считаю, что рассмотренного в них материала достаточно для преодоления порога вхождения новичка и дальнейшего самостоятельного изучения возможностей фреймворка.

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