Вячеслав

Не раздувая тему

UIkit 3 или Bootstrap...

ответ: однозначно UIkit 3

Хочу посоветоваться, имеет ли смысл запускать сессию исключительно для залогиненых пользователей поскольку последних намного меньше?

На самом деле, так и должно быть почти всегда. Разработчки тех или иных веб-приложений так зачастую сами плохо представляют, что впустую созданная сессия до момента собственно аутентификации ни для чего не нужна. Для целей сбора какой-либо статистики посещения стоит изобретать решение, не зависящие от основной сессии: выставление куки для дополнительных субдоменов или конкретных путей сайта и т.п.
В случаях, когда, например, необходимо настроить кэширование ответов backend'а на сильно нагруженных сайтах, отключить создание сессии для каждого входящего — просто жизненно необходимо.

А совсем по-хорошему, кроме создания сессии только для залогиненных пользователей (что, вообще говоря, правильно), поставьте перед веб-сервером реверс-прокси — nginx или varnish (рекомендую последний), которые будут проверять наличие куки залогиненного пользователя, и в случае ее отсутствия выдавать контент из своего кеша. Таким образом, вы вообще не будете запускать PHP для незалогиненных пользователей.

Вот, например, как решается эта проблема в друпале (неважно, что у вас, принципы, скорее всего, те же) www.varnish-cache.org/trac/wiki/VarnishAndDrupal

Следствие присутствия session_start() в начале скрипта таково: если клиент не поддерживает куки, то файл сессии создается на каждый запрос. А всякие роботы довольно часто куки не поддерживают.

Еще раз — на каждый запрос робота создается новый файл сессии.

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

Поэтому рекомендация такая: храните сессии для пользователей, которые сохраняют ваши куки. Ставим куку, проверяем на следующем запросе, есть ли эта кука, если есть — можно запускать session_start().

Вариант проще, без кук, и будет создаваться еще меньше сессий: создавать сессию только для того, кто авторизовался. То есть, пока не совпал логин и пароль пользователя, не запускаем session_start().

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

Если у клиента есть куки с session id, значит клиент залогинен то запускать session_start()
Если куки нет — значит не залогинен, сессию не запускаем.

Если есть куки с ID сессии, значит, вы уже вызвали session_start(), а значит, файл сессии уже создался. Проверять нунжо как-нибудь по-другому (например, совпадением введенного логина и пароля, как описано выше).

Вот новый open source проект Notejam. Реализация одного приложения на популярных php, python и ruby фреймворках. Можно оценить код и разницу в решениях одной и той же задачи.

Есть для вас решение
Всё, что от вас требуется - это использовать php7

Если нужно графически запускать тесты можно использовать phpstorm выглядит это как то так

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

Прозрачность.
Потому, что так сложнее контролировать то, что приходит (тайпхинтинг), документировать (phpDoc), кроме того нужно ещё дополнительно проверять массив на наличие нужных ключей.
Это не говоря уже о том, что это портит end-user experience, когда вы работаете, скажем, в какой-нибудь IDE, где вам будет очень понятно и удобно показываться, какой аргумент для чего нужен и какого он типа.
Плюс, вы немного странное сравнение делаете. Если уж сравнивать инициализацию через конструктор, то с инициализацией через конструктор с отдельными аргументами.

Вы можете из плагина / темы на этот фильтр навесить свою функцию и указать свою регулярку (в данном конкретном случае). Если WordPress в этом месте увидит вашу подключенную функцию - он будет использовать регулярку (или другой функционал) вашу, если нет - свою стандартную.

Если кратко, есть 2 вида хуков - action и filter.

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

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

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

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

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

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

Вариантов на самом деле не много:
1) консоль через ssh
2) любая другая локальная веб-морда с доступом по паролю (сам использую adminer.org). Но аудит безопасности никакой из них не проводили, поэтому для вас они все "дырявые".
3) те же веб морды, только перед ними HTTP аутентификация. Всё ещё дыряво? Тогда
4) веб-морды с предварительной аутентификацией по HTTP + список ip
5) удалённый доступ к серверу mysql через какой-нибудь клиент. "Но вдруг он сливает мои пароли?" - предвижу ваш вопрос я, тогда вам
6) удалённый доступ к мускулу + список ip в iptables для коннекта на порт. Меняется ip?
7) Аутентификация по ключам в mysql сервере?

Sipout.net или zadarma.com если чтобы не париться, у сипаута лучшие цены, но есть приколы с доступностью номеров не из РФ и с региональных мобильных, для большинства тематик это 1-2% общего трафика. Качественные номера можно посоветовать взять на Манго-телеком, наши крупные клиенты берут у них, но там подключение дольше и придется платить за их сервис.

Это просто бесконтекстная вёрстка и вагон пафоса)))

На самом деле достаточно Элемент-модификаторов:

.menu,
.menu-list{
   position:relative;
}
.menu-list{
   overflow:hidden;
   margin:0 -10px;
}
.menu-item,
.menu-item-current{
   display:block;
   float:left;
   margin:0 10px;
}
.menu-item{
   color:#000;
}
.menu-item-current{
   color:#f00;
}

ну и в этому удобно применять closure-stylesheets

БЭМ - это такая методология вёрстки от Яндекса. Она подразумевает разбиение страниц на отдельные смысловые блоки (комментарий, пост, заголовок, футер, форма, инпут и т.п.). Каждый блок может состоять из других блоков. Основная идея - как можно больше повысить возможность повторного использования уже написанных блоков, для чего используются модификаторы. Плюс, БЭМ подразумевает отказ от каскадных стилей, потому что они препятствуют повторному использованию.
Например, на странице есть два разных заголовка (например, отдельно в статье, и отдельно во врезке). Как все привыкли делать это? есть код заголовка:
<h1 class="header">Заголовок</h1>
И мы ставим эти заголовки в текст статьи и во врезки:

<article class="article">
    <h1 class="header">Заголовок</h1>
    <p>Текст текст текст</p>
</article>
<aside class="incut">
    <h1 class="header">Заголовок</h1>
    <p>Текст текст текст</p>
</aside>

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

.header {font-size: 2em; padding-bottom: 1.5em;}
.incut .header {text-decoration: italic;}

Всё хорошо, но теперь мы не можем просто перенести эти стили заголовка во врезке в другое место, потому что эти стили привязаны именно ко врезке (классу incut). Плюс, что ещё хуже, если к элементу привязано несколько различных стилей, образующихся подобными каскадными правилами, то перенести такой внешний вид в другое место становится очень трудоёмко. А также, из-за большей специфичности каскадных стилей, их сложнее "перебить" новым стилем.
БЭМ предлагает отказаться от каскадных стилей и создавать отдельные стили-модификаторы:

<article class="b-article">
    <h1 class="b-article__header">Заголовок</h1>
    <p>Текст текст текст</p>
</article>
<aside class="b-article b-article__incut">
    <h1 class="b-article__header b-article__header_incut">Заголовок</h1>
    <p>Текст текст текст</p>
</aside>

.b-article__header {font-size: 2em; padding-bottom: 1.5em;}
.b-article__header_incut {text-decoration: italic;}

Чем больше проект, тем выгоднее использование подобной методологии. На маленьких и средних проектах БЭМ может быть избыточен. Хотя вот была статья habrahabr.ru/company/yandex/blog/234905 про использование в маленьких проектах.

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

Ну вот. Получилось не в двух словах, но менее подробно качественно описать БЭМ не получится, имхо.