Владимир Кокарев: Я сначала хотел сказать, что скорее всего, админка будет использовать какой-нибудь HTTP-сервер, но потом подумал, что скорее всего, она будет использовать какой-нибудь глубоко запрятанный Lighttpd или что-то в таком духе... но, видимо этот самый апач установился вместе с панелью управления.
Евгений Привалов: я думаю, проблема в том, что у Вам в robots.txt стоит запись:
Disallow: /wp-content
а стили находятся именно там и робот не может их считать. Телефоны, и пр. устройства, как Вы понимаете, этот файл игнорируют. Поисковые системы - нет.
Нужно, либо перенести стили оттуда, либо, разрешить доступ.
Алексей Уколов: я имел в виду, именно количественную составляющую, как уже озвучили выше :) В MySQL например, таблица на диске занимает обычно 2-3 файла (в среднем), в PHP каждая сессия - отдельный файл, и 10тыс. ботов могут сгенерировать 10тыс. таких файлов, по одному на каждый коннект... ну и т.д.
Евгений Привалов: я не знаю, открывается ли у Вас эта страница, по этому, пришлю скрин. Тут среди прочего, по какой-то причине, заблокированы CSS. И по этому, не грузится адаптив. И сайт становится не оптимизированным... Возможно стоит попробовать перенести их в головную часть сайта, как положено по стандартам, и тогда проблема решиться.
Евгений Привалов: тут к сожалению, объективный выход только 1. Либо сделать так, что бы гугл тоже так думал (рекомендации от гугла есть по ссылке выше), либо, написать им письмо с просьбой разобраться и т.д., но это скорее всего ничего не даст и в итоге всё равно будет проще просто переделать.
Владимир Кокарев: тогда я думаю, Nginx или какой-нибудь Lighttpd - и в путь. Сейчас проверил у себя, Nginx под небольшой нагрузкой кушает порядка 20Мб памяти, PHP в принципе, не сложно в 64Мб запихать...
Да и в целом в принципе проблем не должно быть, есть реализации связки PHP+Nginx работающие на сервере где всего 32-64Мб оперативки (на всё, роутеры некоторые например), ну там правда ядро постарше и "почище"... Но у нас за то целых 135Мб под всё это дело, точно должно хватить.
sim3x: например когда нам нужна встраиваемая БД, для небольшого объёма данных <200-500Мб, и/или нужна база для работы в однопользовательском режиме (единственный коннект). Или например, когда нет администратора или иного специалиста, который может заставить эту БД работать как надо. Когда речь идёт о блоге в 500 страниц максимум, куда проще, логичнее и в конечном счёте производительнее - взять MySQL, с настройками "из коробки". Там сразу и кэширование запросов, который в Postgres "из коробки" ни под каким соусом нет, и хост-процесс всего 1, никакие пулеры не нужны, и так далее. И многие вещи гораздо проще, а посему - проще настраиваются и потенциально приведут к гораздо меньшему кол-ву возможных ошибок, нежели безграмотное использование гораздо более функциональной БД. С MySQL'ом "меньше приходится думать" - это весомое преимущество, в ряде случаев, для многих.
frittifrutty: Риторический вопрос. Даже три риторических вопроса...
1. Я затрудняюсь сказать, стоит ли делать конкретно Ваш сайт "типа лендинга", это очень субъективно будет, не зависимо от конечного мнения
2. Я не понимаю, как Вы так быстро смотри просмотреть и оценить ~1500 шаблонов сайтов
3. Не понимаю, как целая категория из ~1500 шаблонов может целиком состоять из лендингов :)))
Но одно могу сказать точно. Если там все шаблоны - лендинги, видимо это такая тенценция в ресторанном бизнесе, делать исключительно лендинги.
P.S. Удалось найти как минимум 1 нетипичный лендинг. Мне кажется, Вам стоит ещё немного поковыряться там, вдруг что-то действительно стоящее найдется... Если нет - то это наверное, такое же диагноз как у меня, забыл называние заболевания, но лечат его только профессиональные художники-дизайнеры, за отдельную/достойную плату :)) Я дизайнеров штук 8 перебрал, пока нашел такого, который рисовал как я хочу... и тогда получился шаблон действительно такой, какой я хотел видеть. Правда, не про еду, технической тематики...
Вы бы посмотрели сайты конкурентов, и выбрали для себя несколько тех, что нравятся. А ещё можно посмотреть шаблоны готовые на TemplateMonster... Понятие "красоты и удобства" - довольно субъективная вещь по природе своей.
Karmashkin: ну это уже для компаний уровня "завтра выходим на европейский рынок", подавляющее большинство о существовании файлов .gitignore узнаёт только благодаря тому, что они случайно (зачем-то?) попали в набор, вместе с дистрибутивом любимой CMS/фреймворка/пакета/etc, не говоря уже про такие "фигуры высшего пилотажа" как "отмена коммита". Я за последние пол года, проходил 20+ собеседований, и даже успел детально ознакомиться с условиями работы в паре компаний... В одной из них, Git использовали "абы было", в другой, всерьёз задумывались, что прошло уже 12 лет, с тех пор как Git появился, и возможно уже пора попробовать начать его использовать... В других компаниях, судя по интервью - всё примерно как я выше описал :)
Скорее не "длиннее", просто NULL не является ни "0" ни "1" (не путать NULL как значение со словом "NULL", как с набором символов), и возможно эта колонка не может принимать значение NULL.
