Технология AJAX используется для того, чтобы с помощью javascript отправлять «фоновые» http-запросы, что позволяет не перезагружать страницу, как это происходит при обычной отправке форм.

Реализация AJAX довольно сложна с технической точки зрения. На самом деле происходит работа API XMLHttpRequest, который и выполняет всю работу. Чтобы упростить код, используются функции-«обертки», которые освобождают нас от сложного программирования XMLHttpRequest. В jQuery для этого используются функци ajax, а также её «модификация» post. При этом, если jQuery не нужна, то в Сети можно найти другие библиотеки, реализующие функционал AJAX, например Selector (которая вообще выступает как легковесная замена jQuery).

Не зависимо от используемой библиотеки, основные принципы отправки даных с помощью Аякса будут едиными. Я буду всё показывать на примере jQuery. В конце статьи вы найдете ссылку на zip-архив со всеми примерами.

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

SQLite — это база данных, чем-то похожая на MySQL. Принципиальное отличие SQLite от других БД в том, что вся база представляет собой один файл. Если в MySQL база хранится где-то в дебрях сервера и недоступна для переноса, то в SQLite с этим всё до безобразия просто: один файл — одна база.

Конечно же, сервер должен поддерживать драйвер SQLite (также как и любой другой БД), но как правило сейчас с этим проблем нет.

SQLite позволяет привычно работать с базой через SQL, создавать таблицы, поля и т.д. В целом можно сказать, что SQLite ни в чем не уступает привычной MySQL, за исключением, пожалуй более медленной работы с «тяжелыми» sql-запросами по обновлению данных (insert и update). Но, опять же, это для высоконагруженных сайтов.

Огромным плюсом SQLite будет её легкая переносимость. Скопировать файл — что может быть проще? Не нужно заботиться о бэкапах, как в MySQL, не нужно создавать на сервере пользователя с паролем, не нужно создавать саму базу. С SQLite просто берём и пользуемся.

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

Роутинг — это маршрутизация: входящий URL разбирается специальным образом и по его результату выполняется определенный код. С роутингом напрямую связано понятие ЧПУ (человекопонятные урлы), которое позволяет исключить в адресах сложные параметры. Например вместо http://сайт/admin/new-pageпришлось бы использовать http://сайт/admin.php?action=new-page

Любой входящий URL на сервере разбирается по единому стандарту. Полностью приводить документацию не буду (см. как пример функцию parse_url), важно лишь понять, что в адресе передается параметр path (путь на сервере), которого на сервере реально может не быть. Например в адресе http://сайт/adminкаталога adminреально может не существовать.

То есть сервер, получив такой адрес, попытается найти каталог admin, но не найдя его, выдаст 404-страницу (not found).

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

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

Как правило, первое, что делает блогер - это устанавливает кэширующие плагины. Нагрузка, если и уменьшается, то незначительно. Далее, начитавшись «якобы гуру», начинают самостоятельно «оптимизировать» шаблон или даже сам WordPress. Тут можно только посочувствовать, особенно умиляют советы о включении например gzip-сжатия в самом шаблоне. Стоит ли говорить, что подобные действия в самом лучшем случае не приводят к результату вовсе, либо, наоборот нагрузка на сервер ещё больше увеличиватся.

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

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

В своих учебных статьях о MaxSite CMS я подразумеваю, что их читатель хоть немного, но программист. И поэтому привожу куски кода чтобы те, кому это интересно, мог использовать в своих проектах. Если читатель не имеет представлений о PHP, то мои рассказы ему мало интересны. Однако есть группа тех, кто непосредственно связан с вебстроительством, и при этом имеет посредственные знания PHP. Речь идет о верстальщиках-дизайнерах. Большинство из них могут разобраться в базовом синтаксисе PHP, выучить несколько функций CMS и всё это использовать при верстке шаблона. Как правило, верстальщики (будем дальше по тексту их так именовать) имеют некий отлаженный и готовый «программистский шаблон», где уже выставлены нужные функции в нужных местах. :)

Речь в статье пойдет именно для этой категории, и я постараюсь максимально исключить сложный код, сосредоточившись на теории и конкретных описаниях с практическим уклоном. Чтобы привнести некоторый накал страстей, я решил усложнить себе задачу, но упростить её тем, кто умеет делать шаблоны для WordPress: я буду приводить сравнение и рассказывать об отличиях в MaxSite CMS. Таким образом верстальщику будет проще понять что к чему.

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

В последнее время почему-то активизировалась тема о том, что якобы MaxSite CMS идеологически неверно построена. Нужно было делать по туториалу CodeIgniter, а я, подлец, сделал по-другому и теперь, якобы нельзя совместно с MaxSite CMS делать «классические» CodeIgniter-приложения.

Основные претензии сводятся к тому, что в MaxSite CMS используется единый контролер, что не нравится фанатам CodeIgniter, которые не в состоянии продвинуться дальше прочтения хелпов.

Я решил, вместо того чтобы крутить пальцем у виска, объяснить и продемонстрировать использование MaxSite CMS с «классическим» CodeIgniter-приложением.

Но, для начала немного объяснялок.

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

Пост-солянка. :)

1. На новом сервере я включил PHP как FastCGI. Скорость тестового сайта несколько увеличилась (примерно в 2 раза). Это на WordPress. Теперь я решил поставить другой сайт на своей MaxSite CMS и как оказалось .htaccess при таком режиме работает как-то по другому. В частности при использовании ЧПУ, сервер выдает, что файл не найден.

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