Как написать блог на php

Пишем движок блога: часть первая

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

Начнем с базы данных. Я считаю, что самым оптимальным вариантом будет mysql. Создадим через phpmyadmin новую таблицу со следующими полями: id (уникальный номер статьи), title (заголовок статьи), date (дата добавления статьи), content (текст статьи). Чтобы Вы не теряли время, я собрал sql запрос:

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

В первой части мы напишем скрипт, который будет выводит главную страницу со свежими статьями и сделаем постраничную навигацию.
Создадим конфигурационный файл, чтобы в будущем Вы всегда смогли изменить настройки блога. Я буду использовать ini файл т.к. такой способ оказался быстрым и удобным. Подробнее о файлах настроек Вы можете прочитать в интересной статье «Самые быстрые настройки для PHP-скриптов». Наш файл будет содержать следующие строки:
#Настройки базы данных
mysql_host = localhost
mysql_user = root
mysql_password = 12345
mysql_database = blog
#Количество статей на страницу
pp = 5
Сохраняем файл и даем ему произвольное название, я назвал просто — config.ini.
Приступаем к написанию главной страницы блога. Сначала нам предстоит собрать html каркас. За одно создадим файл стилей.

style.css
* <
font-family: Arial, Helvetica, sans-serif;
>

/* Блоки */
header <
width:850px;
height:200px;
margin:5px auto;
border-radius:6px;
background:white url(‘i/bg.jpg’) no-repeat top left; /* можете скачать картинку в интернете */
>

article <
width:850px;
height:auto;
margin:auto;
>

article section <
border-bottom:1px dashed #BDECFE;
>

article section h2 <
color:#41738A;
font-size:17pt;
>

article section p <
font-size:10pt;
>

article section p.date <
font-size:9pt;
color:#516168;
text-align:right;
margin-bottom:0px;
padding-bottom:0px;
>

Создадим еще один файл, в котором будет прописано подключение к базе данных, дадим ему имя con.php.

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

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

Настало время попробовать сделать постраничную навигацию.

Вверху index.php, после подключения con.php, следует вставить следующие строки для того, чтобы узнать количество статей на сайте и общее количество страниц:

Проверяем, не передавал ли пользователь номер страницы и переделываем наш запрос.

Для проверки данного скрипта, вы можете в файле настроек заменить pp = 5 на pp = 1, чтобы на страницу выводилась только одна статья.

Осталось добавить кнопки навигации. Сразу после тега article пропишем:

И не забудьте добавить стиль для данных ссылок. Давайте сделаем их в виде кнопок:

nav <
width:850px;
height:auto;
margin:10px auto;
text-align:center;
>

nav a <
padding:2px;
background-color:#EFEFEF;
border:1px solid #D5C2C2;
text-decoration:none;
color:black;
font-size:10pt;
margin:2px;
border-radius:5px;
>

Для тех, кто не разобрался в коде главной страницы, выкладываю его сюда:

Данная статья не подлежит комментированию, поскольку её автор ещё не является полноправным участником сообщества. Вы сможете связаться с автором только после того, как он получит приглашение от кого-либо из участников сообщества. До этого момента его username будет скрыт псевдонимом.

Источник статьи: http://habr.com/ru/sandbox/35748/

Первый блог на PHP для начинающих

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

Также перед этим посмотрите наш учебник по PHP.

Создаём базу данных для блога:

В качестве базы данных мы используем MySQL, вот как её сделать, тут не будет показываться как сделать БД и таблицы в ней, просто покажу структуру.

Таблица articles (Статьи):

id — id статьи;
title — Заголовок статьи;
text — Текст статьи;
id_categories — id темы;
views — просмотры;
date — дата создания статьи;

Таблица categories (Категории):

Таблица comments (Коментарии):

id — id комментария;
comment — Комментарий;
id_article — id статьи которому прикреплён комментарий;
date — Дата комментария;

Как видите БД получилась не большая.

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

На этом настройка БД закончилась.

Также, если вы плохо знаете как работать с PhpMyAdmin, то прочитаете часть учебника: Работа с PhpMyAdmin.

Структура файлов блога:

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

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

Как работает блог:

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

А в ссылки к статьям будут отсылаться к шаблону с Get параметрами с данными о статье которая нужна.

Если вы не знаете как работает форма и что такое Get и Post запросы то зайдите сюда.

Источник статьи: http://prognote.ru/web-dev/beck-end/first-php-beginner-blog/

Пишем блог на PHP

Вначале разберемся, что это за тип сайта – блог. Это такой сайт, где размещается текстовая, графическая или видеоинформация. Обязательная особенность – это возможность комментирования всей размещенной информации.

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

Этапы создания блога

Определяемся с тематикой. Задаем вопросы: кто и зачем будет делать посты, какой материал будет представлен и в каком виде. Набрасываем общий вид страниц сайта.
Продумываем функциональную часть: какие действия может совершать пользователь, и как должна отреагировать система. Все это лучше записать в виде отдельных блоков.
Определяемся, где и в каком виде будет храниться информация. Выбираем СУБД. Проектируем структуру базы данных.
Выбираем, будем ли мы сами писать «движок» или возьмем уже существующий.

Движок блога на PHP

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

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

Если вы принципиально решили писать блог на PHP самостоятельно, тогда рекомендуется разобраться в паттернах, т.е. шаблонах проектирования, чтобы не «изобретать велосипеды», ведь многие типичные проблемы решены и представлены в готовом виде. Рекомендуется посмотреть MVC и Singleton. Все это изучается в продвинутом курсе PHP.

Если же вы решили использовать CMS, перечислим некоторые из них: Joomla, Drupal, WordPress, Magento, OpenCart, osCommerce и т.п. И хотя большинство из них гибко настраиваемы, для блогов рекомендуются WordPress, vBulletin, phpBB , поэтому их и рассмотрим.

WordPress – наиболее универсальное и популярное средство, на котором возможно создать практически любой проект. Из преимуществ: множество бесплатных плагинов и шаблонов, понятный интерфейс, огромное количество материалов и уроков.
vBulletin – данное программное обеспечение ориентировано специально на форумы и блоги. Имеет большой набор плагинов для блогов, много компонентов для СЕО, высокий уровень безопасности. Но данный ресурс платный.
phpBB – бесплатное и удобное средство для форумов и блогов. Поддерживает множество баз данных, но является уязвимым к взломам.

Скрипт блога на PHP

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

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

Заключение

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

Источник статьи: http://webshake.ru/post/kak-napisat-blog-na-php

Готовим простой блог на микросервисах, пишем свой микрофреймворк на php и запускаем все на Docker с примерами

А что если я скажу вам, что новый продукт можно сразу начинать писать на микросервисной архитектуре, а не заниматься распилом монолита? Это вообще нормально? Удобно? Хотите узнать ответ?

Задача: необходимо написать за выходные (время ограниченно 10-15 часами) сферический блог на микросервисах, на php, не используя никаких фреймворков. Можно пользоваться здравым смыслом. А еще забудем о том что такое фронтенд и вспомним что мы жить не можем без виртуализации. Выберем Docker. Интересно? Вперед под кат.

Микросервисы

Если вам интересен микросервисный подход, но вы не знаете с чего начать, начните с книги «Building Microservices» Сэма Ньюмена. Постараюсь немного описать основные моменты данного подхода, если у вас будут какие-то дополнения, пишите пожалуйста в комментариях. И вообще по любому поводу пишите, я не претендую на истинность какого-либо из описанных ниже подходов, особенно в Вашем конкретном случае.

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

Суть микросервисов легко понять в сравнении с монолитной архитектурой. Как у нас выглядит обычный движок для блога? Грубо говоря это просто одно приложение. Работа с статьями, комментариями, страницами, пользователями и прочими функциональными единицами заключена в едином пакете исходного кода, который не делится никак.

Где все связи между компонентами — это вызовы внутри кода, какие-то отношения между классами, паттерны и т.п. или даже просто говнокод, если нельзя отделить одно от другого.

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

Единственное отличие, что квадратики с компонентами — это больше не компоненты заключенные в код одного приложения, а стрелочки — это больше не системные вызовы классов внутри этого кода. Теперь — это отдельные компоненты, а стрелочки — обычные запросы по http.

Зачем это нужно? Сразу определимся, что наверное, это нужно не всем. Это должно быть очень удобно, если вы — достаточно крупная компания, способная выделить по команде разработки на каждый сервис. Думаю, даже средним компаниям, если выделить по человеку на каждый сервис будет тоже неплохо. Впрочем, даже если ты один на всю компанию, ты сможешь найти в микросервисах что-то интересное.

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

Итак, позитивные вещи, которые я смог выделить для себя, в целом все они проходят под одним трендом: Невероятное удобство для разработки:

Отказоустойчивость. Так как связи между сервисами больше не жесткие, сервис может умереть по чьей-то глупости (например сервис комментариев), но в целом на блоге это не скажется никак, кроме того что пропадут комментарии.
Язык. Вы можете разработывать новый сервис на чем угодно. В общем выбор языка перестает напоминать поиск серебряной пули, для каждого компонента системы вы можете выбрать тот инструмент, который ей подходит больше всего в текущий момент времени. Почему? Потому что это больше не дорого для компании (сервис маленький), вы всегда можете выкатить старый сервис назад, вы даже можете использовать одновременно одинаковые сервисы написанные на разных языках, чтобы понять, что лучше. Цена ошибки неизмеримо меньше.
Маштабируемость. Приложение тормозит и не справляется? Нужен новый огромный сервер для всего приложения, а лучше 10? Забудьте. Теперь вы можете масштабировать сервисы. Просто добавьте побольше сервисов 🙂
В целом высокая скорость работы, как результат всего что выше.

Что должно уметь наше приложение? Так то не очень много.
Четыре страницы:

Список постов
Открытый пост с комментариями
Добавление поста
Авторизация

Авторизованный пользователь может добавить пост
Кто угодно может его комментировать.

Docker

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

Кстати, вот ссылка на репу, из которой вы можете скачать и запустить блог, посмотреть что-то по коду ниже. https://github.com/gregory-vc/blog

Сколько будет контейнеров в нашем простейшем блоге? Контейнер, это кстати по сути виртуализация отдельного сервера, который общается по сети с другими контейнерами, правда если проводить жесткую аналогию контейнер=сервер, от некоторых контейнеров нужно будет отказаться, но тем не менее. Для простейшей реализации блога на микросервисах я насчитал 24 контейнера. Давайте посмотрим.

Общие контейнеры: база для сервиса авторизации, основная база блога, редис.
Сервис-шлюз: php, контейнер для исходного кода, nginx.
Сервис для работы с постами: (php, контейнер для исходного кода, nginx) х 2
Сервис для работы с комментариями: тоже х 2
Сервис авторизации и аутентификации: тоже х 2

Зачем на по две копии некоторых сервисов? Потому что с одной будет не интересно и не понятно.

Файл docker-compose, который развернет все это одной командой выглядит вот так:
https://github.com/gregory-vc/blog/blob/master/host/docker-compose.yml
Из самого интересного рассмотрим настройки php контейнера нашего шлюза.

Раздел описания контейнера links, это по сути просто редактирование /etc/hosts/

Где по обозначенному хосту мы просто имеем доступ к другому контейнеру через внутреннюю сеть докера.

А раздел environment — это просто обозначение переменных, которые мы сможем достать с вами внутри приложения через getenv(). Сделано так, чтобы файл docker-compose был единой точкой входа для настройки всего приложения.

В то время как структура наших сервисов выглядит как просто директории лежащие рядом,

Но, на самом деле, при запуске докера хостов, каждая из этих директорий оказывается внутри отдельного изолированного соответствующего контейнера. Делается это как-то так:

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

Сервис Gate

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

Итак, у нас есть php и больше ничего. Хотя, давайте возьмем хотя бы composer, куда без него. Создадим еще две директории, одну с нашим микрофреймворком, который мы сейчас напишем, вторую для public скриптов, js, и прочих ресурсов.

В composer просто укажем, откуда осуществлять autoload, чтобы нам самим с этим не заморачиваться, и подключим сгенеренный autoload в public/index.php

Так, что-то у нас уже есть, давайте определимся что нам вообще еще будет надо?

MVC, а значит контроллеры
Место для бизнес логики
Шаблоны
Шаблонизатор

Немного di, самый простой, ввиде хранилища объектов.
Само хранилище
Запрос
Ответ
Роутинг, о да, с него стоит начать.
Сессии и прочее по мелочи.

Напишем вот такое хранилище объектов, чтобы не создавать их где попало, а иметь возможность получить доступ (inject) к уже созданным в любой точке приложения со всем нужными зависимостями (dependency). Мы не будем развлекаться с Reflection и прочими интересными штуками, время у нас жестко ограничено.

В Di, используя это хранилище просто добавляем все объекты что нам нужны.
В паблике стартуем Di, получаем роутер, регистрируем все урлы что нам пригодятся, получаем приложение и стартуем его.

В приложении получаем request, маппим в роутере существующий экшен существующего контроллера по этому реквесту, одновременно еще записываем в request все пост или гет переменные, что нам пришли.

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

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

Там внутри при запросе выбираем рандомны коннектор из предоставляемых сервисом, как-то так

Делаем запрос, из контроллера и рендерим, вот так:

Нам нужно отрендерить, но как? Шаблонизаторов у нас нет. Писать свой? Ну нет. Просто используем php.

Черезвычайно мощный шаблонизатор размером с 4 строчки.

Сервис post и comment

Что дальше? Теперь мы можем делать запросы и рендерить результат, теперь нам нужно написать сервисы отдающие ответ. Все просто копируем наш новый движок в другие сервисы, меняем урлы и пишем работу с моделями и бд, вместо удаленных сервисов.

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

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

Результат

Вообще, можете скачать и развернуть его одной командой, напомню репозиторий: https://github.com/gregory-vc/blog

Где подходило по смыслу — я вывел для наглядности какой именно нодой был сгенерен тот или иной блок.

Еще меня впечатлило время генерации странички. Это 5-9 мс для странички с постом и несколькими комментариями (!). Да, все это необъективно, да, все это попугаи, да, микросервисы тут не при чем, да, смотря с чем сравнивать. Но. Тот же ларавель генерит свою страничку, вообще без запросов и данных, просто приветствие, за 90 мс, на моей же машине. Это в 10-20 раз дольше.

Я понимаю, что там происходит куда больше всего, не сравнить, но тем не менее, попытаюсь выразить мысль: для конкретно текущей задачи отдельного изолированного микросервиса всего этого и не надо. Для сервиса комментов я выкинул класс работы с сервисами по сети. Для сервиса шлюза я выкинул класс работы с базой. Для каждого конретного сервиса я собрал лишь то, что ему надо. А правильном сервису надо совсем чуть-чуть 🙂

А главное это невероятный потенциал для масштабирования этого блога под просто невероятные нагрузки. Никто не помешает например потом взять и переписать сервис комментариев на Go.

Проблемы

Сетевые накладные расходы
Не зная о том как работает другой сервис, мы можем вполне попасть в ситуацию, когда, он не то что работает плохо, и портит нам все, он еще и использует наш сервис (!) чтобы нам же отдать наши результаты.

Источник статьи: http://m.habr.com/ru/post/302844/