BatteryLow

Запрашивал у них как-то API через саппорт, сказали что его нет.

Он и не будет работать.
Нужно немного почитать, но не вкантактик, а доку по if.

Просто смешно такое читать. Раньше это было забавно, а сейчас от такого плакать хочется.
HTML & CSS это крайне простые вещи, им можно обучить любого человека за неделю (без шуток, девушка не имея даже в школе уроков информатики за неделю-полторы смогла создавать обычные статичные странички типа такой, но не SPA, а с обычным скроллом ) , HTML-"программисты" всегда вызывали смех у тех кто знаком с областью.
Затем, изучение языков ничего не дает, изучить синтаксис того же php можно за неделю-две неспешными темпами, но программировать это не научит, язык это лишь средство. Программирование это нечто иное, алгоритмы, базы данных, ооп, паттерны, проектирование и куча других вещей, а не только язык. Попугая можно научить повторять слова, но разговаривать от этого он не начнет.
Хватит уже считать что изучив смешные HTML&CSS научились чему-то серьезному, это не сложнее Word & Excel, хотя наверное перегнул палку, Word & Excel сложнее будут.
Нужны ли фреймворки? Javascript - язык, jquery - фреймворк и думаю становится очевидно что фреймворк упрощает некоторую работу на некотором языке, но можно вполне и без него обойтись.

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

2. Если хочется развлекаться с echo - то быстрее всего будет работать
echo $some, ' - var';

HeidiSQL

Вы меня, конечно, извините, но зачем ограничивать пользователя в выборе пароля? Зачем ограничивать длину пароля сверху? Зачем вырезать спецсимволы из его пароля, если он все равно будет хэширован (вы ведь хэшируете пароль, а не храните его plain текстом?)? Просто ограничьте минимальную длину пароля символами шестью.

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

в Unix задачи cron-а лежат в нескольких местах:
1. /etc/cron.d - здесь можно создавать файлы с заданиями крону, которые он будет загружать и исполнять по указанному расписанию. в этих файлах нужно указывать пользователя, от имени которого будет исполнено задание
*/10 * * * * root /root/backup.db.sh
2. /etc/cron.daily, /etc/cron.hourly, /etc/cron.monthly, /etc/cron.weekly - здесь кладем скрипты, которые будут исполняться ежедневно, ежечасно, ежемесячно и еженедельно. это такие себе подготовленные расписания, которые подгружаются и исполняются в определенное время
3. crontab -e - исполнение этой команды с ключом откроет текстовый редактор для редактирования заданий крону текущего пользователя. будьте внимательны - эти задания относятся к текущему пользователю и будут исполняться от его имени
соответственно, самый просто способ для динамического редактирования заданий для крона - это манипуляция с заданиями в /etc/cron.d

Есть смысл иногда хранить JSON в некоторых ситуациях, но таким случаем очень мало.
А вдруг вы захотите сделать позже поиск по комментариям, или по фотографиям. Что будете делать?
В вашем случай однозначно необходимо разделить все это в разные таблицы. Сделать 1 дополнительный запрос по ключу( вытянуть фотографии) - это и нагрузкой то не назовешь для бд.
То же самое и с комментариями.

Это бред делать на друпале визитку-блог. Да и на Yii тоже извращение. Мне кажется нужно идти по пути наименьшего сопротивления: Ставим вордпресс, покупаем на темфоресте шаблончик под него, чуть правим если надо и все готово, можно пользоваться. При грамотном наполнении даже шаблонный сайт будет очень неплох. А потом когда уже фирма перестанет быть "открывающейся", то уже будет понятно что вам нужно и в каком виде.

Как всегда - дурацкий вопрос, да еще и по-дурацки сформулированный, порождает кучу дурацких ответов.

ЕСЛИ не читать тело вопроса, а отвечать на вопрос из заголовка (а это ключевой момент для Q&A сайта, поскольку тупые поисковики приводят именно по заголовкам. И администрация должна следить за релевантностью оных и вычищать вопросы, которые автор не в состоянии сформулировать), то ответ однозначный - за выборку ЗАПИСЕЙ только для того, чтобы ПОСЧИТАТЬ их, дают пожизненный эцих с гвоздями. Считать должна база!

ЕСЛИ отвечать на вопрос вне контекста вставки, а только глядя на запросы, то ответ - ОДИНАКОВО. В обоих случаях никакого подсчета нет а есть только выборка по ключу.

ЕСЛИ вникать в контекст задачи чуть глубже, то появляются варианты ускорить МНОЖЕСТВЕННУЮ проверку, такие как prepared statements (тот редкий случай, когда их фича с множественным исполнением может выстрелить).

ЕСЛИ вникать в задачу окончательно, то правильным будет ответ @zeromodule. Причем вставку надо либо делать множественную, по тысяче записей, либо заворачивать в транзакцию - поскольку ОБНОВЛЕНИЕ ИНДЕКСА при таком количестве вставок начнет тормозить работу куда сильнее, чем нищасные селекты, столь пугающие аффтара. И опять же использовпать prepared statements.

www.flatuicolorpicker.com

Шаблонизатор шаблонизатору рознь. Но в целом следует выделить общие задачи. которые должны решать за вас шаблонизаторы. С blade не работал и не вижу смысла есть есть twig.

Безопасность. Это пожалуй можно поднять на верх. Типичная картина в шаблонах на php - <?= $someUserInput; ?>. Частенько это можно встретить в выводе инпутов, при формировании ошибок поиска (мол "по запросу $userInput ничего не найдено. То есть вставляем в инпут подключение наших js скриптиков, если это форма поиска - делимся с "другом" и забираем его сессию. Ну или еще какие забавные штуки можно делать. А ведь все очень просто решается. Ставим какую-то функцию, которая по умолчанию будет фильтровать XSS инъекции при выводе, и не будет этого делать только если мы попросим. Если писать просто на php - появляются отвратные функции, которые можно просто забыть вызвать. А с шаблонизаторами мы пишем красивые {{ someUserInput }} и можем спать спокойно.

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

Ограничивают полет фантазии разработчика. Далеко не новость что разработчики ленивые засранцы. Особенно молодые. Если им в шаблоне внезапно понадобились какие-то данные из БД, или данные связанные с запросом, большинство не будет париться и зафигачит нужный код прямо в темплейте. Так же некоторые грешат тем что часть бизнес логики размазывают по шаблонам. Так же встречал проекты отданные на суппорт, где чуваки в шаблонах разбирали через xpath ответы от сторонней апишки (которая использовалась вместо базы данных. То есть это дело было размазано по всему проекту). Рефакторинг в случае изменения апишки будет болью.

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

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

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

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

люди думать отучились - вопросы по любому поводу в интернетиках ищут (в тостере особенно)?

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

На уровне SQL проверить это можно примерно так:

SELECT * FROM `...`
WHERE DATE_ADD(`date`, INTERVAL 1 MONTH) > NOW()

почитайте мой туториал может врубитесь - devacademy.ru/posts/series/symfony-2-joboard