До вчерашнего дня у меня на ноутбуке под Linux Mint “Qiana” стояли два незаменимых для меня пакета для кодинга - Sass + Compass.

Оба пакета были не самой свежей версии, но стабильной. Однако, с недавних пор к ним прибавилось еще два пакета - Susy 2 и Breakpoint. Но Susy 2 для своей работы требует фреймворк Compass версии 1.0.0.

Поэтому, пришла пора обновить Compass и под Linux Mint. Под Windows 7 у меня уже давно стоит Compass-1.0.0.alpha.19 + Sass-3.3.8 (Maptastic Maple) + Susy-2.1.2 + Breakpoint-2.4.2.

Под эту систему процесс инсталляции Compass v1.0.0 замудреный и описан в этой статье - “Медиа-запросы Breakpoint в Sass”.

Но работать под Windows мне не нравиться, поэтому поставил для себя задачу перейти на Compass версии 1.0.0.alpha.19 на Linux.

На момент написания статьи Compass и Sass у меня под Linux Mint “Qiana” были следующих версий:

$ sass -v
Sass 3.2.19 (Media Mark)
$ compass -v
Compass 0.12.6 (Alnilam)

Произвожу “зачистку” системы командами:

$ gem uninstall compass
$ gem uninstall sass

Установка Compass alpha-версии производится командой:

$ gem install compass --pre

Но вот беда, под Linux Mint “Qiana” эта команда выдает ошибку:

...
Unable to install gem - Failed to build gem native extension - cannot load such file — mkmf (LoadError)
...

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

И о чудо - на StackOverflow нашелся такой вопрос и готовое решение на него. Правда, вопрос там относился к проблеме запуска Ruby определенной версии -

1
v 3.2.9
под Ubuntu 12.04, но это дела не меняет. Ошибка одна и таже и решение мне подошло однозначно.

На удивление, решение оказалось простым - нужно всего лишь установить в системе developer-версию Ruby -

1
ruby1.9.1-dev
.

На момент установки Compass версии

1
alpha.19
у меня имелся следующий Ruby:

$ ruby -v
ruby 1.9.3p194 (2012-04-20 revision 35410) [i686-linux]

Ставлю developer-версию Ruby (вот оно - решение!):

$ sudo apt-get install ruby1.9.1-dev

И затем снова пробую установить Compass alpha-версии:

$ sudo gem install compass --pre
Building native extensions.  This could take a while...
Fetching: rb-inotify-0.9.5.gem (100%)
Fetching: rb-kqueue-0.2.3.gem (100%)
Fetching: listen-1.1.6.gem (100%)
Fetching: json-1.8.1.gem (100%)
Building native extensions.  This could take a while...
Fetching: compass-1.0.0.alpha.19.gem (100%)
...

На этот раз установка пошла успешно и Compass 1.0.0.alpha.19 появился в моей системе:

$ sudo compass -v
Compass 1.0.0.alpha.19

Препроцессор Sass подтянулся автоматом, в качестве зависимости:

$ sass -v
Sass 3.3.8 (Maptastic Maple)

Отлично! Теперь настала очередь сладкой парочки Susy 2 + Breakpoint:

$ sudo gem install susy
Fetching: susy-2.1.2.gem (100%)
Successfully installed susy-2.1.2
...
$ sudo gem install breakpoint
Fetching: sassy-maps-0.4.0.gem (100%)
Fetching: breakpoint-2.4.2.gem (100%)
Successfully installed sassy-maps-0.4.0
Successfully installed breakpoint-2.4.2
...

Ну вот и все, проблема установки Compass 1.0.0.alpha.19 под Linux Mint “Qiana” успешно решена! Можно продолжать с удобством кодить под Linux.

Для полного счастья нужно еще разобраться с установкой Photoshop под Linux - тогда жизнь будет полной.

Удачного кодинга!


Время от времени в Twitter, Reddit или StackOverflow возникает такой вопрос.

Почти каждый, кто работал с Sass хотя бы раз задавал его себе - что выбрать, Compass или Bourbon?

Оба проекта Compass и Bourbon являются фреймворками под Sass. Sass, как вы помните, является препроцессором CSS, не правда ли? Хорошо. Точно также, как если бы вы имели дело с jQuery или Backbone при работе в JavaScript, использование фреймворка для Sass облегчает работу с последним.

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

История Compass и Bourbon

Compass заявляет о себе как о CSS фреймворке под Sass. Он поддерживается Chris Eppstein, одним из двух разработчиков Sass. Compass - это наполовину Ruby и наполовину Sass, он представляет из себя полный набор миксинов и инструмент под Sass. Более подробно о нем позже.

С другой стороны, Bourbon создан на Sass и для Sass великолепной командой разработчиков Thoughtbot. Если верить домашней странице проекта, Bourbon - это скорее библиотека, нежели фреймворк; простая и легковесная библиотека миксинов под Sass.

В итоге мы имеем с одной стороны Ruby/Sass фреймворк, а с другой стороны мы имеем библиотеку Sass. Совершенно разные вещи, не правда ли?

Миксины Compass и Bourbon

Если спросить пользователя Compass/Bourbon, для какой цели он использует данный инструмент, высоки шансы услышать однозначный ответ: для кросс-браузерной совместимости. Возможно, он ответит не совсем так, но ответ будет иметь приблизительно такой же смысл.

Как Compass, так и Bourbon являются огромной коллекцией миксинов для создания CSS3-эффектов; благодаря этим миксинам отпадает необходимость детально вникать в браузерные префиксы или CSS-уловки (CSS hacks).

Ниже показан пример миксина

1
box-sizing
в обоих библиотеках Compass и Bourbon. Как видим, синтаксис и результат работы одинаков:

// Compass

  .boxsizing {
    @include box-sizing(border-box);
  }

// Bourbon

.boxsizing {
  @include box-sizing(border-box);
}

Тот факт, что Compass и Bourbon имеют одинаковый синтаксис для большинства миксинов, делает переход в использовании с Compass на Bourbon и с Bourbon на Compass очень легким.

Существует одно важное различие между этими инструментами: начиная с Compass 1.0 (вышел совместно с Sass 3.3), Compass получает информацию с сайта Can I Use. Это означает, что почти всегда данный фреймворк получает самую свежую информацию по браузерным префиксам.

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

Замечание: если вы используете Autoprefixer для решения вопросов браузерных префиксов, то все вышесказанное не относится к вам.

Типографика в Compass и Bourbon

Оба - Compass и Bourbon - предоставляют набор готовых миксинов, переменных и функций для работы с типографикой. Помимо этого, Compass имеет в своем составе полноценный модуль для создания вертикального ритма, включая набор переменных и пару миксинов:

// Compass Vertical Rhythm
  $base-font-size: 16px;
  $base-line-height: 1.35;
  $rhythm-unit: em;

  element{
    @include adjust-font-size-to(42px);
  }

// CSS result
element{
  font-size: 2.625em;
  line-height: 1.06071em;
}

У Compass также есть возможность поддержки единиц измерения

1
rem
с откатом к
1
px
, если вы используете
1
rem
в качестве значения переменной
1
$rhythm-unit
вместо
1
em
.

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

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

1
em
или
1
rem
, но также такие великолепные функции, как
1
golden-ratio()
и
1
modular-scale()
.

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

Собственно, Thoughtbot решили адресовать вопрос с типографикой другому их проекту (который может использоваться совместно с Bourbon) под названием Bitters. Более подробно о нем будет говориться в конце статьи.

CSS-сетки в Compass и Bourbon

Разве можно назвать фреймворк полноценным, если у него нет системы сеток (grid system), верно?

Фреймворк Compass имеет в составе систему Blueprint Grid, которая, насколько я знаю, не имеет ничего общего со старым фреймворком под названием Blueprint. Стоит сказать, что система Blueprint фреймворка Compass является неполноценной.

Среди всех людей, которые используют Compass и с которыми мне приходилось общаться, только один пробовал работать с Blueprint. Эта система настолько несовершенна, что Chris Eppstein решил убрать ее из Compass начиная с версии 1.0.0 (что соответствует Sass 3.3).

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

1
flex-*
(не стоит путать с моделью Flexbox) и
1
grid-width()
.

Помимо этого, у команды Thoughtbot имеется своя собственная, отдельная от Bourbon, система сеток под названием Neat, которая позиционируется как легковесный семантичный фреймворк под Sass и Bourbon.

Таким образом, библиотека Bourbon не имеет в своем составе системы сеток (grid system), но можно свободно воспользоваться для этой цели фреймворком Neat.

Если сделать краткий итог по вопросу системы сеток, то можно сказать следующее. Если необходима система сеток с тесной интеграцией Sass-фреймворка, то мое мнение - это использовать связку Bourbon + Neat. Оба проекта были созданы одними и теми же людьми; в обоих проектах была заложена одна и таже основная идея. Это можно сравнить как два кусочка одного пазла.

Примечание переводчика: автор статьи упоминает о стороннем проекте Neat (система сеток) для библиотеки Bourbon. Но почему-то ни словом не говорит о проекте Susy?

Helpers

Одной интересной вещью Sass-фреймворков являются так называемые helpers. Helpers - это предустановленные CSS-правила, которые можно использовать в таблицах стилей как есть, для сокращения времени разработки проекта.

Например, Compass имеет набор helpers для float-clearing (включая несколько способов, как это сделать) и несколько CSS-хаков для старых версий браузера Internet Explorer; сброс стилей (несколько вариантов); несколько способов замещения текста изображением и многое другое.

В Bourbon такие helpers называются add-ons, но они выполняют туже работу; правда, в Bourbon их немного меньше, чем в Compass. Стоит сказать, что команда Thoughtbot включила с состав проекта Bitters большое количество helpers. Как было уже сказано выше, Bitters является сторонним проектом, который имеет прекрасную интеграцию с Bourbon и служит для целей создания типографики в проекте.

Спрайты Compass и Bourbon

Спросите пользователя Compass, почему он из месяца в месяц и из года в год использует эту библиотеку; клянусь, что в ответ услышим что-то о системе создания спрайтов. Это та вещь, которую Compass действительно выполняет хорошо. Благодаря тому, что Compass написан на языке Ruby, он может выполнять некоторые очень интересные вещи с файловой системой. Одной из таких фишек является способность создавать спрайты из коллекции изображений, размещенных в одной папке. Замечательно, не правда ли?

// Пример создания спрайтов в Compass
  @import "icon/*.png";
  @include all-icon-sprites;

Помимо автомагического способа генерации спрайтов, Compass предоставляет пару интересных функций для доступа к файлу изображений прямо из таблицы стилей, наподобие

1
image-width()
,
1
image-height()
и даже
1
inline-image()
для преобразования файла изображения в Base64:

// Функции Compass доступа к файловой системе
.logo{
  $image: "path/to/my/logo.png";
  width: image-width($image);
  height: image-height($image);
  background: inline-image($image) no-repeat;
}

Так как Bourbon построен только на Sass, у него нет возможности доступа к файловой системе и эта библиотека не может выполнить таких вещей, какие может Compass. Поэтому, если вы ищете способ динамического создания спрайтов и не хотите заморачиваться с такими менеджерами задач, как Grunt, Gulp или Ant, то выбор для вас очевиден.

Итог

И так, что же получаем в итоге - Compass или Bourbon?

Если спросить об этом меня, то я отвечу: никакой из них. Долгое время я был пользователем библиотеки Compass, покуда не отказался от его применения.

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

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

Библиотека Compass великолепно подходит для этих целей, но она выполняет свою задачу медленно, слишком медленно. Поэтому, если вас не устраивает такой факт, то посмотрите в сторону Bourbon. Эта библиотека замечательно быстрая хотя бы потому, что состоит из одних Sass-миксинов, выполняющих задачи Sass внутри таблиц стилей Sass.

Если вы решили использовать библиотеку Bourbon, то я бы рекомендовал вам также задействовать другие проекты команды Thoughtbot: Neat в качестве системы сеток (grid system), Bitters для типографики и еще не упомянутый до этого момента Refills (который является полной альтернативой фреймворка Bootstrap) с полным набором компонентов, готовый для использования в создаваемом проекте.

Примечание переводчика: в этой статье дан сравнительный обзор двух фреймворков - Compass и Bourbon. Лично для меня было бы интереснее посмотреть практические примеры использования библиотеки Bourbon.

Оригинал статьи: Sass Frameworks: Compass or Bourbon? от автора Hugo Giraudel.


Под локальным сервером XAMPP можно создавать неограниченное количество виртуальных хостов.

Что такое виртуальный хост (Virtual Host)? Применительно в серверу XAMPP - это поддиректории, в которых размещаются отдельные сайты. То есть, имеется директория

1
htdocs
, а в ней размещены поддиректории
1
site_1
,
1
site_2
,
1
site_3
(или же так -
1
redface
,
1
football
,
1
greenpark
, название может быть любым).

В каждой из этих поддиректорий распакован и установлен движок CMS WordPress (к примеру). Вот эти поддиректории

1
site_1
,
1
site_2
,
1
site_3
и являются виртуальными хостами под локальным сервером XAMPP.

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

Настройка виртуальных хостов на XAMPP под Linux Mint почти ничем не отличается от подобной настройки под Windows, меняются только пути конфигурационных файлов. Весь процесс настройки можно свести к двум шагам:

  1. Настройка хостов в файле
    1
    
    /etc/hosts
  2. Настройка виртуальных хостов в файле
    1
    
    /opt/lampp/etc/extra/httpd-vhosts.conf

Ниже на примере расмотрим подробное описание создания одного виртуального хоста на XAMPP под Linux Mint.

Создание поддиректории виртуального хоста (Virtual Host)

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

1
redface
(имя произвольное) и обязательно разместим в ней индексный файл
1
index.html
:

$ sudo mkdir -p /opt/lampp/htdocs/redface
$ sudo touch /opt/lampp/htdocs/redface/index.html

Виртуальный хост с именем

1
redface
почти создан. Осталось “сказать” об этом локальному серверу XAMPP и операционной системе Linux Mint.

Редактирование файла /etc/hosts

Операционной системе Linux Mint нужно “сказать”, что виртуальный хост

1
redface
размещен по адресу
1
127.0.0.1
. Для этого открываем для редактирования файл
1
/etc/hosts
командой:

$ sudo nano -w /etc/hosts

… и дописываем в нем строку

1
127.0.0.1 redface.dev
:

127.0.0.1 localhost
127.0.1.1 zmk

# Virtual hosts
127.0.0.1 redface.dev

Окончание

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

Сохраняем Ctrl+O и выходим Ctrl+X из редактора

1
nano
.

Включение поддержки виртуального хоста в XAMPP

По умолчанию в настройках XAMPP отключена поддержка виртуальных хостов. Для включения такой возможности нужно отредактировать конфигурационный файл

1
httpd.conf
сервера Apache.

Для этого открываем его командой:

$ sudo nano -w /opt/lampp/etc/httpd.conf

В открытом файле

1
httpd.conf
нужно найти (в редакторе это сочетание Ctrl+W) строку
1
# Virtual hosts
и раскомментировать (снять знак решетки
1
#
) строку:

#Include etc/extra/httpd-vhosts.conf

Создание виртуального хоста в файле httpd-vhosts.conf

Открываем для редактирования файл

1
httpd-vhosts.conf
и знакомимся с его содержимым:

$ sudo nano -w /opt/lampp/etc/extra/httpd-vhosts.conf

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

1
httpd-vhosts.conf
от этого мусора.

Далее идут два блока с открывающим тегом

1
<VirtualHost *:80>
и закрывающим тегом
1
</VirtualHost>
. Данные блоки являются виртуальными хостами - их два по умолчанию, но можно добавить сколько необходимо.

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

1
<VirtualHost *:80>
/
1
</VirtualHost>
размещена служебная информация - описание виртуального хоста:

<VirtualHost *:80>
  ServerAdmin webmaster@dummy-host.example.com
  DocumentRoot "/opt/lampp/docs/dummy-host.example.com"
  ServerName dummy-host.example.com
  ServerAlias www.dummy-host.example.com
  ErrorLog "logs/dummy-host.example.com-error_log"
  CustomLog "logs/dummy-host.example.com-access_log" common
</VirtualHost>

Жизненно необходимыми для существования виртуального хоста (Virtual Host) под XAMPP являются две строки:

  • DocumentRoot - путь размещения виртуального хоста в файловой системе
  • ServerName - доменное имя виртуального хоста

Остальные строки носят дополнительный характер:

  • ServerAdmin - e-mail адрес “администратора” хоста
  • ServerAlias - синоним доменного имени ServerName
  • ErrorLog и CustomLog - логи виртуального хоста

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

1
redface
:

<VirtualHost *:80>
  ServerAdmin         redface@mail.dev
  DocumentRoot        "/opt/lampp/htdocs/redface"
  ServerName          redface.dev
  ServerAlias         www.redface.dev
  ErrorLog            "logs/redface-error_log"
  CustomLog           "logs/redface-access_log" common
</VirtualHost>

Обратите внимание, как поменялись значения в этм блоке на конкретные, под хост

1
redface
.

Запускаем (если еще не запущен) или перезапускаем (если уже был запущен) локальный сервер XAMPP:

$ sudo /opt/lampp/lampp start
Starting XAMPP for Linux 1.8.2-5...
XAMPP: Starting Apache...ok.
XAMPP: Starting MySQL...ok.
XAMPP: Starting ProFTPD...ok.

… и “вбиваем” в адресной строке браузера доменное имя созданного нами виртуального хоста

1
redface.dev
:

Virtual Host под XAMPP

ОК, все работает!

Проблемы с правами доступа на виртуальном хосте

При создании виртуального хоста (Virtual Host) под XAMPP в директории

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

Чтобы можно был вносить в них изменения с правами обычного пользователя, нужно выполнить команду:

$ sudo chmod g+w /opt/lampp/htdocs/redface/index.html

Изменение точки монтирования виртуального хоста

В этой статье точка монтирования виртуальных хостов (Virtual Hosts) располагалась по адресу -

1
/opt/lampp/htdocs/
. То есть, поддиректории виртуальных хостов находились внутри директории
1
htdocs
.

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

Вся настройка для переопределения точки монтирования виртуальных хостов (Virtual Hosts) сводится к одному действию - изменить значение строки

1
DocumentRoot
. Но, к моему сожалению, мне не удалось настроить XAMPP на своем ноутбуке подобным образом.

Все попытки переименовать значение строки

1
DocumentRoot
приводили к тому, что XAMPP не мог открыть индексную страницу.

В чем причина подобного отказа со стороны XAMPP, я так и не разобрался. Может быть, внимательный читатель подскажет, в чем причина?

P.S. от 09.09.2014

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

Так можно добавить в рабочую папку с проектами на другом диске (например, для использования на Linux и Windows отдельно):

1. Файл httpd.conf

Найти строки и заменить (Имя пользователя):

  • User (username)
  • Group (по умолчанию или username)

Не меняем:

DocumentRoot "/opt/lampp/htdocs” и Directory “/opt/lampp/htdocs"

2. Создаем мягкую ссылку:

$ sudo ln –s /media/(username)/mydisk/Open Server/domains /opt/lampp/htdocs

Права на мягкую ссылку “opt/lampp/htdocs/domains” д. б. 777 ( или около того )

3. Файл httpd-vhosts.conf

#localhost
  
  <VirtualHost *:80>
    DocumentRoot "/opt/lampp/htdocs"
    ServerName localhost
  </VirtualHost>

  <VirtualHost *:80>
    ServerAdmin mydomain@mail
    DocumentRoot "/opt/lampp/htdocs/domains/mydomain/www"
    ServerName mydomain
    ServerAlias http://www.mydomain
  </VirtualHost>

4. Файл /etc/hosts

#Virtual hosts
  127.0.0.1 localhost
  127.0.0.1 mydomain

5. Меняем владельца файла

Меняем владельца файла

1
/opt/lampp/htdocs/xampp/lang.tmp
:

$ chown (username) /opt/lampp/htdocs/xampp/lang.tmp

Иначе

1
localhost xampp
дальше стартовой страницы может не загрузиться.

6. Перезапуск сервера

Перезапуск сервера:

$ sudo /opt/lampp/lampp restart

… и проверка в браузере:

1
http://mydomain/

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

Если каким-то образом, диск в Linux откажется монтироваться, нужно в Windows отключить быструю загрузку (Fast Boot) в параметрах электропитания.

Для тестирования IE в Linux ставится виртуальная машина (например, VirtualBox), куда устанавливаем Windows7 и любимый браузер IE. В самой Windows редактируем файл

1
hosts
также как и в Linux, с одним условием – нужно вписывать другой IP, вместо 127.0.0.1, нужно вписывать 10.0.2.2.

Вот так:

c:/windows/system32/drivers/etc/hosts
  10.0.2.2 localhost
  10.0.2.2 mydomain

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


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

Занимался изучением настройки сверстанного HTML-шаблона под WordPress. То есть, другими словами - создания темы WordPress из готового HTML-шаблона.

Для этой задачи у меня на Linux Mint 17 Cinnanom 64-bit установлен локальный сервер XAMPP. Если кто не знает, как сервер XAMPP устанавливается под Linux, то могут почитать в этой статье - “Установка XAMPP под Linux Mint 17”. Под локальным сервером у меня “крутятся” виртуальные хосты на основе движка WordPress.

Предпросмотр темы не отображается в WordPress

После создания директории под новую тему -

1
Choose
закинул к нее скриншот готовой темы для preview в менедежере тем WordPress -
1
wp-admin/themes.php
. Но вот неожиданность - картинка-скриншот будущей темы Choose не отобразилась!

Перепробовал достаточно способов, в том числе и с официального сайта XAMPP - XAMPP работает, но почему картинки не отображаются?. То, что там описано - изменение двух строк файла

1
/opt/lampp/etc/httpd.conf
:

#EnableMMAP off
#EnableSendfile off

… не сработало, так как в моем конфигурационном файле

1
httpd.conf
обе строчки были расскоментированы по умолчанию:

EnableMMAP off
EnableSendfile off

Решение оказалось на удивление простым. Я и не подозревал, что настройка прав доступа в Linux может быть такой “коварной” штукой! Сначала обратил внимание на тот факт, что preview тем WordPress, которые идут “в комплекте” с ним - “Twenty Fourteen”, “Twenty Thirteen”, “Twenty Twelve” нормально отображаются на странице. А вот

1
preview
моей темы - не отображается:

Предпросмотр темы не отображается в WordPress

Решил проверить догадку методом “научного тыка” - тупо сравнить два файла-preview

1
screenshot.png
из разных тем, своей “Choose” и стандартной “Twenty Fourteen”:

$ ls -l choose/wp-content/themes/twentyfourteen/screenshot.png
-rw-r--r-- 1 choose/wp-content/themes/twentyfourteen/screenshot.png

$ ls -l choose/wp-content/themes/choose/screenshot.png
-rw------- 1 choose/wp-content/themes/choose/screenshot.png

Вот оно! У файла

1
screenshot.png
из темы “Twenty Fourteen” имеются права на чтение
1
r
для - владельца, группы и всех остальных
1
-rw-r-r-
. У файла
1
screenshot.png
из моей темы “Choose” имеются права на просмотр
1
r
только для владельца данного файла
1
-rw- - -
.

Ну что-же, нужно добавить

1
+
права чтения
1
r
для всех
1
a
пользователей файла
1
screenshot.png
темы “Choose”:

$ sudo chmod a+r /opt/lampp/htdocs/choose/wp-content/themes/choose/screenshot.png

… и проверить результат:

$ ls -l /opt/lampp/htdocs/choose/wp-content/themes/choose/screenshot.png
-rw-r--r-- 1 /opt/lampp/htdocs/choose/wp-content/themes/choose/screenshot.png

Перехожу в WordPress на страницу управления темами

1
wp-admin/themes.php
и смотрю, что получилось:

Рабочее preview создаваемой темы WordPress

Картинка по центру изображения - это preview создаваемой темы “Choose” под WordPress. Как видно, все прошло удачно.

Картинки темы WordPress не отображаются под XAMPP

Но вышеназванное решение оказалось лишь половиной дела. Вторая проблема заключалась в том, что при активации вновь созданной темы под WordPress изображения из нее не отображаются на странице.

Фоновые изображения, картинки в HTML-файле - ничего не появляется на странице. Firebug не смог мне помочь - единственное, что он “подсказал” - “Файл невозможно загрузить”. Многословно, ничего не скажешь!

Помог незаменимый ресурс для front-end разработчика - Stack Overflow. Решение проблемы заключено в двух строках:

$ cd /opt/lampp/htdocs
$ sudo chmod 777 -R .

То есть, переходим в директорию

1
htdocs
и меняем рекурсивно
1
-R
права на все действия
1
777
для всего содержимого текущей
1
.
директории. Не знаю, как там с вопросами безопасности в этом случае, но факт остается фактом - все стало работать, как и надо было:

Изображения темы WordPress корректно отображаются на странице

В принципе, на этом все.


Статья посвящена вопросу установки Node.js и пакетного менеджера npm под операционную систему Linux Mint 17 “Qiana” Cinnamon (64-bit).

Также рассмотрен вопрос установки пакетного менеджера Bower в этой же операционной системе.

Почему выбрана система Linux Mint - об этом не стоит говорить долго. Это система гораздо удобнее для задач кодинга, нежели Windows. Пакеты Node.js и пакетный менеджер npm необходим для дальнейшего изучения ремесла верстальщика.

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

О том, что такое Node.js, в этой статье также не будет описано. Во-первых, автор статьи имеет лишь поверхностное представление об этом сервере. А во-вторых, в Интернете есть немало хороших материалов по данному вопросу.

Установка Node.js

Для установки пакета Node.js под систему Linux Mint можно воспользоваться официальным сайтом проекта - Node.js. В разделе Download имеется табличка для скачивания различных версий пакета Node.js. В случае системы Linux в этой таблице нужно найти строку Linux Binaries.

Однако я не буду “заморчиваться” установкой из исходного кода. В Linux Mint есть прекрасный менеджер пакетов

1
apt-get
, которым можно и нужно воспользоваться для быстрой и безопасной установки Node.js под Linux. Единственный минус такого подхода - в результате у меня на машине будет стоять не самая свежая версия сервера Node.js. Однако в данном случае это абсолютно не критично.

В терминале ввожу команду:

$ sudo apt-get install nodejs

… пару секунд терпения и у меня под Linux Mint 17 “Qiana” Cinnamon (64-bit) установлен пакет Node.js версии:

$ nodejs -v
v0.10.25

На момент написания статьи самая свежая версия Node.js (как указано на официальном сайте) - это 0.10.28. Как видим, разница в версиях небольшая, так что я поступил правильно, воспользовавшись

1
apt-get
.

Установка npm под Linux Mint

Как хорошо известно, у данного сервера имеется свой собственный менеджер пакетов npm (Node Packaged Modules), для установки дополнительных модулей под Node.js. Другими словами, с помощью менеджера npm можно установить под сервер Node.js любой модуль, имеющийся в наличии на репозитории GitHub. Модуль расширяет возможности сервера Node.js в зависимости от того, какой это модуль (тавтология). С кратким описанием и списком всех модулей под Node.js можно ознакомиться на официальном сайте проекта npm - Node Packaged Modules.

При установке в свою систему Linux Mint через

1
apt-get
у меня был установлен только сам сервер Node.js. При этом менеджер пакетов npm отстуствовал в системе. Не знаю, как это происходит при установке пакета Node.js из исходников, но при использовании
1
apt-get
у меня получилось именно так. Поэтому следующим шагом будет инсталляция менеджера пакетов npm под систему Linux Mint.

В терминале Linux ввожу команду:

$ sudo apt-get install npm

Пробежит много-много строк, но в результате в системе появиться пакет npm:

$ npm -v
1.3.10

Использование менеджера npm очень похоже на использование менеджеров пакетов a-la Linux:

1
apt-get
,
1
emerge
,
1
pacman
и так далее. npm также является консольной командой и у него схожие ключи, поэтому пользователи Linux без труда разберутся с ним:

$ npm -h

Давайте проверим работу установленного менеджера npm. Для этого я в специально отведенной директории Projects создам поддиректорию npm, перейду в нее для дальнейшего удобства работы и установлю в этой поддиректории модуль

1
underscore
из репозитория npm:

$ mkdir -p Projects/npm
$ cd Projects/npm
$ npm install underscore

Если теперь посмотреть содержимое поддиректории npm c помощью команды

1
ls
, то обнаружим появление папки
1
node_modules
, внутри которой располагается подпапка
1
underscore
c содержимым одноименного модуля:

$ ls node_modules/underscore/
LICENSE  package.json  README.md  underscore.js  underscore-min.js

Модуль Underscore успешно установлен и менеджер npm также успешно справился со своей задачей.

Установка менеджера Bower под Linux Mint

Переходим к заключительному (и продолжительному) вопросу данной статьи и рассмотрим установку менеджера пакетов Bower. Могу предвидеть у читателей логичный вопрос: “Как - еще один менеджер пакетов?! Но зачем? Разве не хватает npm, c которым мы только что познакомились?”

Все правильно! npm - это менеджер пакетов. И Bower - тоже менеджер пакетов. Отличие первого от второго заключается в том, что npm - это менеджер пакетов для сервера Node.js (и только). А Bower (хотя сам является модулем под Node.js) - это менеджер пакетов для всего проекта в целом.

Npm понимает и может работать только с JavaScript-приложениями (модулями под Node.js, написанными на этом языке). Bower умеет работать с пакетами на JavaScript, HTML, CSS. C помощью него можно одним движением добавить в разрабатываемый проект все, что нужно: библиотеку jQuery, фреймворк Foundation, модуль Underscore, сброс стилей Normalize.css и так далее.

Не нужно самому “вручную” выискивать на безбрежных просторах Интернет пакет и подключать его в проект - Bower это сделает сам. Заманчиво, не правда ли? На официальной странице проекта Bower можно почитать подробную информацию о данном менеджере (правда, на английском языке). В разделе Search Packages можно поискать нужный пакет для установки.

Я же приступлю к установке Bower на свою локальную машину. Так как Bower является модулем для Node.js, то его можно установить с помощью менеджера npm:

$ sudo npm install -g bower

Однако, если запустить после этого в терминале команду просмотра версии, то увидим такой результат:

$ bower -v
/usr/bin/env: node: No such file or directory

Исправить ситуацию можно созданием ссылки:

$ sudo ln -s /usr/bin/nodejs /usr/bin/node

Теперь если снова посмотреть версию установленного пакета, увидим следующее:

$ bower -v
1.3.3

Создаю специальную поддиректорию

1
bower
в директории Projects, перехожу туда и запускаю менеджер bower на установку пакета jquery:

$ mkdir -p Projects/bower
$ cd Projects/bower
$ bower install jquery

Если до этого момента на локальной машине (как у меня) не был установлен пакет

1
git
, то самое время это сделать, иначе bower не сможет установить указанный пакет jquery:

$ bower install jquery
bower jquery#*  ENOGIT git is not installed or not in the PATH

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

Установка Git на Linux производится простой командой:

$ sudo apt-get install git

После этого, повторив команду установки jquery через bower, получаю следующий отзыв в консоли:

$ bower install jquery
  bower jquery#*              not-cached git://github.com/jquery/jquery.git#*
  bower jquery#*                 resolve git://github.com/jquery/jquery.git#*
  bower jquery#*                download https://github.com/jquery/jquery/archive/2.1.1.tar.gz
  bower jquery#*                 extract archive.tar.gz
  bower jquery#*                resolved git://github.com/jquery/jquery.git#2.1.1
  bower jquery#~2.1.1            install jquery#2.1.1

Если посмотреть на содержимое поддиректории

1
bower
, то увидим, что там появилась директория
1
bower_components
, в которой находится поддиректория
1
jquery
c установленным пакетом:

$ ls bower_components/jquery/
bower.json  dist  MIT-LICENSE.txt  src

В результате была установлена последняя версия библиотеки jQuery - 2.1.1. Если нужна какая-то конкретная версия пакета (jQuery, в частности), то нужно это указать с помощью тега:

$ bower install jquery#1.9.1

Внимательный читатель мог заметить, менеджер пакетов Bower также (как и npm) является консольным. Список доступных для него команд можно получить вызовом:

$ bower -h

В частности, для обновления уже установленного пакета существует команда:

$ bower update [name_package]

Для удаления установленного пакета имеется команда:

$ bower uninstall [name_package]

Посмотреть информацию о пакете:

$ bower info [name_package]

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

1
bower.json

Плагин Bower под Sublime Text

Под редактор Sublime Text имеется одноименный плагин Bower, который в точности повторяет все возможности менеджера Bower. Все преимущество использования плагина Bower заключается в том, что производить инсталляцию, обновление или удаление пакетов можно прямо в редакторе Sublime Text, не переходя в консоль.

Установка плагина Bower выполняется стандартно - через менеджер пакетов Sublime Text: нажимаем сочетание клавиш Shift+Ctrl+P, введем в строке Install и выбираем из появившегося списка пакет Bower.

Теперь попробуем установить какой-либо пакет, не выходя из Sublime Text, c помощью плагина Bower. Для этого снова нажмем сочетание клавиш Shift+Ctrl+P, вводим Bower:Install и из появившегося списка выбираем пакет Foundation (к примеру).

Видим, как в панели проектов Sublime Text, в папке

1
bower_components
появилась целая куча подпапок, являющихся частью единого целого - фреймворка Foundation:

Установленный через Bower пакет Foundation в Sublime Text

Настройка плагина Bower

Поддиректория

1
bower_components
, в которую плагин Bower производит установку пакетов, не является чем-то постоянным. То есть, можно легко изменить имя и расположение этой директории. Делается это следующим образом - в Sublime Text нажимаем сочетание клавиш Shift+Ctrl+P и вводим Bower: Configure project (никто не запрещает создать файл конфигурации вручную).

В текущую директорию автоматически добавиться файл

1
.bowerrc
типа json, в котором будет всего лишь одна строка - имя директории, в которую производится установка пакетов через плагин Bower:

Файл настроек пакета Bower

Для эксперимента изменим имя папки с:

"directory": "components"

на:

"directory": "apps"

… удалим старую директорию

1
bower_components
с пакетом foundation и установим через Bower другой пакет - underscore. В результате получим следущее:

Новое имя директории с пакетами в Bower

Пакетная установка в менеджере Bower

У менеджера пакетов Bower есть еще одна замечательная особенность. Это возможность пакетной установки через специально созданный конфигурационный файл. Другими словами, создается специальный файл формата json (

1
component.json
), в котором прописываются имена всех пакетов, которые необходимы для установки в данном проекте. Затем в консоли запускается менеджер Bower c одной командой:

$ bower install

… менеджер bower прочитает файл

1
component.json
и автоматически установит все пакеты, перечисленные в нем. Отлично, не правда ли?

Примечание: начиная с Bower v.0.9 файл конфигурации

1
component.json
был переименован в файл
1
bower.json
, который я буду использовать в дальнейшем.

Файл

1
bower.json
имеет следующий формат:

{
"name": "name_of_project",
"version": "1.0.0",
  "dependencies": {
    "name_package": "version_package",
    "name_package": "version_package"
  }
}

… где

1
name
- это имя проекта,
1
version
- версия проекта,
1
dependencies
- зависимости проекта. Под зависимостями проекта подразумевается список сторонних пакетов (к примеру - foundation, backborne, jquery и так далее), которые используются при создании данного проекта.

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

1
bower.json
для текущего “проекта” bower. Для этого я удалю все ранее установленные в этой поддиректории пакеты:

$ bower uninstall [name_of_package]

… создам в этой директории пустой файл

1
bower.json
и наполню его следующим содержимым:

{
"name": "bower",
"version": "0.0.1",
  "dependencies": {
     "jquery": "1.9.1",
     "foundation": "latest"
   }
}

… где

1
latest
- самая последняя версия пакета. Сохраняю изменения, перехожу в консоль и запускаю команду:

$ bower install

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

...
Unable to find a suitable version for jquery, please choose one:
    1) jquery#1.9.1 which resolved to 1.9.1 and is required by bower
    2) jquery#>= 2.1.0 which resolved to 2.1.1 and is required by foundation#5.2.3
    3) jquery#>=1.2 which resolved to 2.1.1 and is required by jquery.cookie#1.4.1

Prefix the choice with ! to persist it to bower.json

[?] Answer:
...

… то есть, Bower отследил, что я устанавливаю библиотеку jQuery версии 1.9.1; но при этом самая последняя версия фреймворка Foundation 5.2.3 требует для своей работы jQuery версии 2.1.1. Вот менеджер и спрашивает у меня - как быть дальше? Ай да Bower!

Добавление зависимостей в файл bower.json

После создания пакетного файла

1
bower.json
в менеждере Bower можно автоматически добавлять в него запись при ручной установке отдельного пакета. Допустим, в ходе работы срочно потребовалась установка пакета backbone.

Тогда выполняем следующую команду:

$ bower install backbone --save

… пакет

1
backbone
(и его зависимость
1
underscore
) успешно установились. Но нас интересует факт добавления записи в файл
1
bower.json
, поэтому смотрим:

$ cat bower.json
{
"name": "bower",
"version": "0.0.1",
  "dependencies": {
    "jquery": "1.9.1",
    "foundation": "latest",
    "backbone": "~1.1.2"
  }
}

Автоматическое создание файла bower.json

Помимо ручного создания и настройки файла

1
bower.json
, у данного менеджера предусмотрена команда для автоматического создания и настройки этого файла. Для этого необходимо в консоли запустить команду:

$ bower init

… тогда менеджер проведет нас “за ручку” через все этапы создания настроек файла

1
bower.json
путем задания серии вопросов. Взгляните на примерный результат вышеназванной команды:

$ cat bower.json
{
  "name": "bower",
  "version": "0.0.1",
  "dependencies": {
    "jquery": "1.9.1",
    "foundation": "latest",
    "backbone": "~1.1.2"
  },
  "description": "my firts project",
  "moduleType": [
    "amd"
  ],
  "authors": [
    "zencoder"
  ],
  "license": "MIT",
  "homepage": "http://localhost:7788/third/",
  "ignore": [
    "**/.*",
    "node_modules",
    "bower_components",
    "apps",
    "test",
    "tests"
  ]
}

Плагин AutoFileName в Sublime Text

Редактор Sublime Text имеет неизмеримое количество полезных плагинов. Одним из них является AutoFileName - незаменимая вещь для автодополнения путей файлов в проекте. Кто имел мало-мальский опыт работы в Dreamveawer (или подобные ему IDE), могут сразу догадаться, о чем идет речь.

Поэтому данный плагин “must have” в коллекции под рабочую версию Sublime Text любого верстальщика.

Заключение

Завершаю обзор установки пакетов Node.js, npm и Bower под систему Linux Mint. Надеюсь, статья оказалась достаточно полной, точной и грамотной. В ее написании неоценимую помощь оказало видео “ Bower - Обзор пакетного менеджера “ Sorax’а.

На этом все.