Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 1837 сообщений
Cообщения с меткой

cms - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

[Из песочницы] Как я написал свою CMS, и почему не рекомендую вам делать то же самое

Пятница, 22 Сентября 2017 г. 14:52 (ссылка)




Cheburator2033


сегодня в 14:52

Разработка





Как я написал свою CMS, и почему не рекомендую вам делать то же самое










Работа над программами управления контентом CMS (content management system) полна чудес. Под катом поучительная история Petr Palas. Если у вас все хорошо с английским, то в оригинале текст можно почитать здесь. Enjoy!



Написание собственной CMS — это как держать у себя дома слона.

Для большинства людей гораздо проще сходить в зоопарк.




В 2000-м я обучался в университете и работал Интранет-разработчиком: публиковал в Интранет контент, написанный на статичном HTML. Это была моя первая «программистская» работа, и я ею наслаждался. Пару недель.



Потом стало очевидно, насколько мои обязанности являются однообразными и неавтоматизированными. И я начал писать приложение на классическом ASP, которое позволяло бы пользователям самостоятельно управлять контентом. Я и понятия не имел о существовании такой штуки, как Content Management System, и потому изобретал велосипед. В то время существовало всего несколько коммерческих CMS, зачастую стоившие сотни тысяч долларов. Учитывая распространённость и ценовой диапазон этой категории ПО, неудивительно, что не я один пытался уменьшить свои неудобства и повысить эффективность, создавая собственную CMS.



К 2004-му почти каждое интернет-агентство создавало собственную CMS, нередко кастомизируя под конкретных клиентов. Это приводило к появлению десятков модификаций — кошмар с точки зрения управления. «Это бессмысленно», думал я. К тому моменту я уже написал несколько специализированных CMS и снова заскучал. «А что если написать CMS, которая может быть полезна для любого сайта?» В результате я организовал компанию Kentico Software, чья миссия была очень проста: создать CMS, которую любой разработчик в мире может использовать для создания любого сайта.



Сюрприз: люди всё ещё пишут собственные CMS!



13 лет спустя меня ещё поражает количество людей, которые пишут собственные CMS. Существует масса зрелых продуктов, под все виды проектов: от open source до коммерческих систем корпоративного уровня, от лучших в своём классе до универсальных «всё-в-одном».



Так зачем кому-то до сих пор нужно писать собственную CMS?

Ответ прост: люди делают это из-за разочарования.



Традиционные веб-ориентированные CMS чреваты недостатками и ограничениями. Но правда в том, что все эти разочарования уже утратили актуальность. Знаю, звучит лицемерно. Ведь мне помогло написание своей CMS, так почему это не поможет другим?

Позвольте объяснить.



Самописные CMS устарели из-за headless-архитектуры



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



И сегодня новое поколение CMS-технологий — облачные, с headless-архитектурой — скоро совершит революцию в сфере управления контентом. В отличие от традиционных решений, headless-CMS сосредоточены только на управлении контентом и на том, чтобы сделать его доступным любому приложению посредством API. Поскольку у таких продуктов нет «головы» (head), которая обычно диктует, как нужно отображать контент, headless-CMS оставляют вопрос дизайна полностью на откуп разработчикам.







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



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



Причина №1: стандартные CMS ограничивают мой творческий потенциал



Первое, на что жалуются фронтенд-разработчики, это вмешательство CMS в их HTML-код и необходимость искать обходные решения.



Но с этим покончено: headless-CMS дают вам полную свободу и никак не влияют на результирующий HTML-код. Для извлечения контента из репозитория вам достаточно лишь с помощью своего любимого языка программирования вызвать соответствующий REST API.

И более того, вы сами полностью решаете, как будет этот контент отображаться!



Причина №2: интерфейсы стандартных CMS слишком сложны



Многие традиционные CMS в последние десять лет существенно разрослись. Хотя все они начинались с идеи предоставления замечательного решения по управлению контентом, большинство не смогли избежать «ползучего улучшизма», поскольку они проникли в электронную коммерцию, автоматизацию маркетинга, системы бронирования, почтовый маркетинг и так далее. Хотя для кого-то удобно иметь всё в одном месте, но новым пользователям трудно изучать такие CMS. Большинству нужно всего лишь управлять контентом, избыток опций снижает продуктивность.



Новые headless-CMS создаются исходя из другой предпосылки: это всего лишь один из фрагментов мозаики микросервисов, и потому эти продукты обладают пользовательским интерфейсом, оптимизированным именно под управление контентом. В то же время современные CMS предоставляют API управления контентом, позволяющие создавать собственные интерфейсы редактирования поверх их репозиториев контента. Это удобно, если вы хотите создать более специализированный интерфейс или интегрировать в приложение возможности по редактированию контента, а не перенаправлять пользователей в другой интерфейс.



Причина №3: стандартные CMS слишком дороги



«Мы не хотели платить Х рублей за коммерческую CMS, поэтому решили написать свою». Если вам не нужно что-то гораздо более простое, чем реальная CMS (вроде управления списком новостей), в долгосрочной перспективе вы не сможете сэкономить с помощью самописной CMS.



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



Причина №4: стандартные CMS не безопасны



Для многих организаций обеспечение безопасности CMS является кошмаром. Поэтому некоторые разработчики думают: «Если мы напишем свою CMS, то хакерам будет труднее найти в ней баги».

Классическое обеспечение безопасности через неясность (security by obscurity).



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



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



Причина №5: стандартные CMS не вписываются в мою архитектуру



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



Не удивительно, что множество программных архитектур не могли следовать по этому пути! Приходилось создавать прокси-слой между CMS и приложением, или — сюрприз! — писать свою собственную CMS.



К счастью headless-архитектура позволяет легко обращаться к контенту с помощью API и писать свои приложения так, как вам хочется.



Причина №6: многие клиенты всё ещё пользуются написанной нами CMS



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



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



Мой совет: сделайте этот смелый шаг, пока ваше агентство не проиграло!

Выберите современную CMS и выделите основные преимущества, которые привлекут к ней ваших клиентов. Наконец, дайте своим разработчикам новую игрушку! Подсказка: большинство из них очень быстро влюбятся в headless-CMS.



… и две причины, когда использование самописной CMS оправдано



Честно говоря, всё же есть ситуации, когда использовать собственную CMS либо целесообразно, либо это вообще единственный возможный вариант:



Управление контентом — основа вашего бизнеса: если вы компания наподобие Medium, то вам наверняка нужен абсолютный контроль над системой управления контентом. Если вы большое издательство с десятками публикаций, и вам нужен полностью кастомизированный рабочий процесс, то вам тоже может понадобиться собственная CMS (или хотя бы кастомный редакторский интерфейс). Однако в мире ОЧЕНЬ мало компаний, относящиеся к этим категориям и для которых оправданы подобные инвестиции.

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



Если что-то из сказанного — про вас, то помните, что каждый час, потраченный на создание своей CMS, это час, который вы могли бы потратить на создание конкурентного преимущества, а не на изобретение колеса.



Не пишите свою CMS, пока не возникнет очевидный бизнес-случай



Люди ВСЕГДА недооценивают объём работы по созданию настоящей CMS.



Возможно, в первый момент вы подумали: «Что такого сложного в CMS? Я просто возьму задокументированную базу данных и прикручу сверху интерфейс редактирования». Это лёгкий старт, но ещё не настоящая CMS. Когда вы начнёте добавлять уровни, например, моделирование контента, языковые варианты, рабочий процесс, разрешения, доставку контента, поиск и так далее, то обнаружите, что разрабатываете и управляете по-настоящему сложным решением.



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


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/338492/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Концепция развития платформы: ожидания 2013 года и реальность 2017-го

Вторник, 19 Сентября 2017 г. 11:17 (ссылка)




sapozhkov


сегодня в 11:17

Разработка





Концепция развития платформы: ожидания 2013 года и реальность 2017-го














    Четыре года назад я выступал на осенней конференции Tabtabus с рассказом о том, как мы в WebCanape разрабатываем и выпускаем сайты. В процессе выступления я сделал несколько прогнозов на 4 года вперед. Срок прошел, и настало время проанализировать, насколько они были верны и как все поменялось за это время.



    Сначала проведу небольшой сравнительный анализ предметной области (2013 vs 2017), затем расскажу об основных направлениях в работе и наших методах реализации.



    Если кому интересно, добро пожаловать под кат.






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



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



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



    В данный момент я руковожу направлением разработки ядра Canape CMS, на которой собираются все сайты, выпускаемые студией WebCanape. Мой отдел непосредственной прибыли не приносит, но результаты его работы лежат в основе большинства процессов, которые монетизируются напрямую.



    Работу студии можно разделить на несколько направлений


    1. Продажа и производство сайта

    2. Продвижение и реклама сайтов — генерация клиентов (абонентские платы и разовые услуги)

    3. Инструменты для работы — CRM (абонентка)





    Ожидание №1. Основную прибыль будет приносить не разработка сайтов, а их продвижение



    Реальность. Прогноз оправдался.



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



    Каким должен быть процесс разработки сайта, чтобы клиент был довольным и заинтересованным в дальнейшей работе именно с нами?


    • Быстрым — максимально быстро создать и запустить в работу сайт

    • Не дорогим — за счет автоматизации и стандартизации работы на всех этапах Удобным — клиенту должно быть комфортно наблюдать за процессом создания сайта, это повышает эго доверие к компании и её профессионализму

    • Надежным — полученный в результате разработки проект должен работать без ошибок и отказов

    • Гибким — сайт можно дорабатывать по желанию клиента, вносить изменения, которые позволят лучше выполнять задачи бизнеса.



    Отсюда требования к работе команды Canape CMS и к продукту.


    • Платформа Canape CMS и все процессы разработки должны быть стандартизированы и описаны в регламентах разработчиков;

    • Наличие инструментов для удобной и быстрой доработки индивидуальных функциональных модулей;

    • Регулярный сбор требований от пользователей для формирования пула доработок;

    • Ведение актуальная документация по продукту: 1) для пользователей, 2) для разработчиков.

    • Автоматическое тестирование типовых проблем и функций;

    • Доработка инструментов для упрощения разработки.



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



    Ожидание №2. Через 4 года будет выпущено более 5000 сайтов



    Реальность. На текущий момент сдано более 2350 сайтов.



    Клиентам больше не нужен сайт за 12 000 рублей со стандартным функционалом. За такую же стоимость клиент хочет продукт с множеством уникальных доработок под конкретный бизнес.



    Ожидание №3. Будем выпускать типовые сайты с минимальными доработками



    Реальность. Многие клиенты хотят серьезных индивидуальных доработок, а количество запросов на типовые решения сокращается. Если раньше большинство продаваемых нами сайтов были без глобальных доработок и собирались на конвейере по 30 штук за месяц, то теперь таких клиентов единицы — большинство хотят серьезные проекты с уникальным функционалом.



    Почему клиентов для типовых решений стало меньше?



    Возможно, из-за финансового кризиса. Возможно, из-за серьезного развития конструкторов сайтов.



    5-6 лет назад бесплатные конструкторы на выходе давали достаточно топорный сайт. Элементы были расклеены, как стикеры, на четко определенные места. Чтобы настроить SEO-продвижение такого сайта, необходимо было долго разбираться в этом вопросе.



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



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



    Ожидание №4. Выпустим свой конструктор сайтов, чтобы компенсировать недостаток типовых проектов и займем эту нишу



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



    Наше агентство ориентировано прежде всего на малый бизнес, где нет крупных бюджетов на разработку и маркетинг, поэтому мы стараемся поддерживать выпуск большого количества сайтов в месяц — около 20–25. Отсюда вытекает ряд проблем, которые мы решаем.




    • Единый центр управления для сайтов

    • Горизонтальное масштабирование — ввод в строй новых серверов должен быть максимально простым

    • Регулярные обновления — быстрый и удобный инструмент накатывание изменений на сервера / площадки

    • Ускорение и упрощение процесса разработки конечных сайтов — площадки для новых проектов должны создаваться быстро



    Как мы решаем эти задачи

    Для работы с большим количеством однотипных площадок был разработан собственный продукт: SMS — Site management system (по аналогии с CMS — Content management system).



    Это система управления площадками. Из функциональности на борту:


    • создание базовых конфигураций сайтов с набором предустановленных функциональных модулей;

    • клонирование — это основной инструмент, имея набор сконфигурированных площадок, можно брать готовый вариант, максимально соответствующий конечной цели, за основу для разработки. В результате получается до 50% экономии времени и средств;

    • резервное копирование — как по cron, так и в ручном режиме;

    • архивирование — перемещение в архив площадок временно не используемых или устаревших, с возможностью их быстрого восстановления;

    • импорт/экспорт — сохранение файлов и данных с метаинформацией в архив, для их дальнейшей публикации на сторонних хостингах или для перемещения на другой сервер Canape SMS;

    • привязка доменов к площадкам;

    • формирование очередей задач, выполняемых по cron, для выравнивания нагрузки на ресурсы сервера;

    • мониторинг состояния сервера;

    • и многое другое.



    Система активно используется:


    • для размещения сайтов — как хостинг для разработанных на Canape CMS проектов;

    • для разработки — мы создаем сайты в аналогичной инфраструктуре с небольшим дополнительным функционалом для разработчиков;

    • как самостоятельная платформа — мы продаем не просто сайт, а целую инфраструктуру для того, чтобы клиент имел возможность генерировать новые площадки под свои нужды. Сайты создаются из специально собранного набора «болванок», которые можно быстро превратить в самостоятельные проекты.



    Пример — сайты органов государственной власти, сформированные на Canape SMS, находятся в одном кластере: admin-smolensk.ru, korso.admin-smolensk.ru, antinark.admin-smolensk.ru, antiterror.admin-smolensk.ru и другие. Все площадки имеют типовую структуру, сгенерированную заказчиком, вынесены на собственные домены и имеют отдельные системы управления содержимым.





    Ожидание №5. Будет много заказов на «мультисайтовые» системы с единым центром управления



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



    «Кластерные» и «отцепленные» площадки



    Это внутренние термины. «Кластерной» мы называем площадку (сайт), созданную через SMS и не имеющую собственных файлов ядра CMS. Все файлы ядра лежат в специальной директории, которой заведует SMS. Для каждой версии сборки есть свой набор файлов.



    Соответственно, «отцепленными» от кластера площадками мы называем обычные сайты, содержащие в рабочей директории полный комплект файлов для функционирования.



    Что дает эта концепция работы?


    • Снижение размера площадки: резервные копии делаются быстрее и занимают меньше места, процесс клонирования площадки идет быстрее, снижение суммарного объема памяти для множества сайтов одной версии.

    • Ускорение работы — одни файлы делают работу для многих сайтов.

    • Возможность обновления менеджером — если площадка кластерная, то доработок на ней гарантированно нет, и можно провести автоматическое обновление. Участие программиста не требуется.

    • Возможность быстро накатить «баг фигсы» на часть площадок



    Доработка уникального функционала проектов



    Если проект не может быть собран на типовом функционале и его надо дорабатывать, то он «отцепляется» от кластера. Для этого есть специальный инструмент в SMS, и впоследствии сайт спокойно дорабатывается независимо от общего программного ядра.



    Вот как это происходит с технической точки зрения.



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


    • SMS создает Fork (копию проекта) от основного репозитория.

    • Разворачивает его в отдельной директории.

    • Создает индивидуальную ветку доработок в том месте, где стоит метка текущей версии проекта.

    • Разворачивает эту ветку.

    • Поверх копируются файлы площадки.



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



    Fork позволяет решить:


    • вопрос с Pull Request (запросами на добавление нового реализованного функционала в основной репозиторий);

    • вопрос с точечными заборами коммитов (изменений) из доработанного проекта в сборку.



    Ожидание №6. Система должна быть понятна для клиентов, администраторов и разработчиков



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



    Разработчики могут быстро (в зависимости от сложности задачи и собственного опыта) дорабатывать конкретные решения.



    SEO-специалисты регулярно транслируют информацию о том, что Canape CMS — очень удобная и прогрессивная платформа с точки зрения поискового продвижения. Понятно, что лучшая – та CMS, которую знаешь ты. Но наш отдел продвижения работает почти со всеми популярными на рынке системами. И такая оценка с их стороны является показателем хороших результатов работы нашей команды и неплохой мотивацией для дальнейшего развития платформы Canape CMS.



    Итоги



    Это слайд с моего доклада 2013 года.





    Четыре года назад мы прогнозировали выпуск более 5 000 сайтов к 2017 году. По факту сегодня создано 2350+ сайтов. Изначально мы ориентировались на несложные сайты с типовым дизайном, то по факту сейчас разрабатываем достаточно объемные проекты с интеграциями, адаптивным дизайном и уникальными программными модулями.



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

    В завершении статьи



    Есть набор вопросов, которые часто задают, поэтому сразу отвечу на некоторые из них





    Почему создали свою CSM, а не использовали другую?

    — Canape CMS — система полного цикла для быстрого производства сайта студией. Не одиноким фрилансером, не собственными силами клиента, не системным администратором компании, а именно студией, где все процессы регламентированы и стандартизированы. Сайт с индивидуальным функционалом и дизайном разрабатывается не за год или полгода, а за 2-3 недели.



    CMS разрабатывалась под конвейер сайтов на студии, чтобы процесс не застревал ни на одном из этапов производства — от макета до финального тестирования и SEO-продвижения.



    Почему не взяли бесплатное решение?

    — Потому что оно не соответствует первому пункту.



    Почему не взяли приличное платное решение?

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



    Почему не облачное решение по подписке для конечного клиента, а CMS с исходным кодом?

    — Потому что ваш сайта — это ваша собственность и ресурс.



    Другие материалы по теме:





    Original source: habrahabr.ru (comments, light).

    https://habrahabr.ru/post/338184/

    Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
    rss_rss_hh_new

    [Из песочницы] Создание модулей для MODX Evolution в 2017 для самых маленьких

    Вторник, 22 Августа 2017 г. 18:53 (ссылка)

    Что такое модули



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



    Но в этой статье я хочу рассказать немного о другом, о модулях. Эту статью я пишу по той причине того что в интернете очень мало информации на эту тему, в русском сегменте такой я вообще не нашел.
    Модуль — это приложение, основанное на архитектуре MODX и расширяющее возможности системы управления. Модуль может группировать набор элементов (сниппеты, чанки, данные), реализуя принцип инкапсуляции через разделение интерфейса и реализации.
    как нам говорит сам MODX. Если говорить конкретнее, то с помощью модулей вы можете создавать надстройки со своими интерфейсами, например для массового редактирования документов или для управления интернет магазином, которые будут удобны пользователю.

    Читать дальше →

    https://habrahabr.ru/post/336182/

    Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

    Следующие 30  »

    <cms - Самое интересное в блогах

    Страницы: [1] 2 3 ..
    .. 10

    LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
    О проекте: помощь|контакты|разместить рекламу|версия для pda