Александр Голубев: смотрите лицензию. Если чистый GPL на все (включая CSS) - можете делать что хотите. Если split license (часть GPL, часть охраняется) - тогда надо смотреть что нельзя использовать. Но это если вы являетесь законным обладателем лицензии. Если это платная тема, которую вы не покупали, то не уверен, что можно использовать. Надо у юристов спросить.
Александр Голубев: А вот с этим я и не спорю, полностью согласен :) Просто причина не в переменных/шаблонах, а в кривости рук, в говнокоде, в использовании тяжелых, непродуманных архитектурных решений и тд. Мне доводилось "допиливать" эти платные темы "все-в-одном", это ад.
Александр Голубев: Apache + Nginx это бред, хотя и очень популярный. Фокус в том, что статику (картинки, стили и тд) будет отдавать Nginx - быстро. И это хорошо. Но, как только нужна динамика - тот же WordPress с его PHP, Nginx отправит запрос на Apache, поднимется его процесс, который вместе с собой поднимет PHP... Здравствуйте, тормоза.
Alex Fisher: тогда зависимости и либы - либо в пакетных папках, либо в vendor, а в init - только свои файлы. То есть, собственный код отдельно, его гит должен отслеживать. Все, что качается или билдится из исходников - в .gitignore
Гриша Никольский: ну как вам сказать. На небольшом, никому особо не нужном сайте (я имею в виду, глобально хакерам вы не интересны) - можно. Если же вы параноите или хотите совсем железобетон - наймите специалиста. Будете пилить сами - слишком высок риск, что улучшив в одном месте, вы добавите проблем в другом. К тому же, безопасность - штука комплексная, это не только валидация полей форм и фильтрация вредоносных данных.
Александр Голубев: на shared основная, самая главная проблема - отсутствие Memcached / Redis, которые радикально меняют ситуацию. Все остальное - вторично. А таже там Apache, который сам по себе тормоз, но самая большая его беда - в работе с PHP. Но перейти на Nginx на shared вы тоже не сможете. Поэтому, для скорости даже самый простой VPS за 5$ в месяц, но настроенный нормально, будет лучше чем самый шустрый и дорогой shared
Иван Украинцев: это маловероятно, разве что для вычисления значения этих переменных берутся из БД (мимо кеша) или по http-протоколу с других серверов (например, по АПИ получается курс валют и тд). Если речь просто о 10-15 переменных, значения которых корректно определены, то такой код в 100-150 строк и на 10-15 переменных выполнится в мгновенье ока.
Ребята, вы делаете 2 ключевые ошибки:
- сравниваете теплое с горячим (статику и динамику)
- не понимая как работает PHP (да и любой серверный язык) делаете выводы на основании только того, что вы видите перед глазами
Александр Голубев: Александр, я не буду писать подробности, достаточно отправить вас читать основы PHP. Вы говорите про каких-то 10 файлов, про какие-то переменные, но это все - микропоспические нюансы. Во время выполнения 1 запроса PHP загрузит несколько сотен (!) файлов WordPress, тем, плагинов, ваши 3-4, или 20-30 шаблончиков, из которых собирается страничка вообще НИКАКОЙ погоды не делают. Что реально влияет на скорость генерации страницы на сервере - так это количество запросов в БД, количество обращений по внешним http-запросам, количество обращей к файловой системе. Но тут такое количество нюансов, что все это не так просто - правильно настроенная серверная ОС кеширует дескрипторы файлов и целые файлы если надо, правильно настроенная БД существенно снижает нагрузку и тормоза, а при наличии объектного кеширования, большинство запросов до БД вообще не доходят и тд. То, что вы уперлись в количество настроек темы и количество шаблонов вообще никак не влияет на скорость. Ну, влияет, но микроскопически, не парьтесь об этом. То, что могут быть криво написанные "настройки темы", которые будут дергать постоянно базу данных и не кешировать запросы - вот это другая история. То есть, проблема не в самих настроках (по-вашему "переменных") и их количестве, не в количестве шаблонов, а в общем качестве кода.
Да как угодно :) Как удобнее. Тут нет каких-то жестких правил.
По вашему примеру - я бы сделал так:
- git репа ествественно в корне
- к вашим файлам в корне добавится, соответственно, папка .git и файл .gitignore
- в .gitignore добавляем build, node_modules - обе папки заполняются выполнением одной команды на папку, одна команда собирает файлы из исходников, другая качает модули из внешних репо, это не нужно держать под контролем версий
- по папочка init не совсем понял что у вас там?
> Где нужно хранить папку с файлами которые загружаются через пакетный менеджер: в корне проекта или в папке init?
Я пока не совсем еще понимаю, что у вас в init, что касается всех файлов через пакетные менеджеры - выделите на них свои папки или собирайте все в одну и и подпапки - как удобнее. Есть некоторые "общие практики" типа папок vendor и тд. Погуглите. К тому же, в каждой сфере, почти в каждом языке программирования, иногда даже в рамках какого-то одного фреймворка есть свои "best practices", которые, в это же время, не являются догмами - вы вольны делать так, как вам удобнее. Репозиторий ведь ваш :)
Alex Fisher: репозиторий в корне проекта. Все ненужное - в gitignore, все нужное - где оно и должно быть - что в корне (какие-то индексные файлы например, конфиги, конфиги билдов и тд), что по своим папочкам. Я не совсем понимаю что вы хотите добиться, почему у вас вообще возник вопрос с корнем репозитория. Возможно, пример вашего репо и целей, которых хотите добиться помог бы прояснить ситуацию?
Гриша Никольский: +1 к WP Panda. В целом - код более-менее, нет явных ошибок, есть валидация данных и тд, в отличие от большинства уроков "для новичков". Но если уж совсем по-чесноку, то да, решение неполное, не самое оптимальное.
WP Rocket и WP FFPC шустрее WP Super Cache. Но свой максимум все они выдают на VPS / Dedicated. На shared хостингах все сложнее, геморнее, и в результате - все равно медленнее.
Иван Украинцев:
> Почему у меня статика грузится за .2-.3 сек
см. выше. Потому что для статики не надо интерпретатор поднимать, парсить файлы и все это дело исполнять, брать данные из БД и файловой системы etc. Для статики просто - взяли файл и выплюнули его в ответ.
> чтобы вп делал слепок всей динамики в статику, чтобы пользователь "первого посещения" качал 1 .html файл и всё
Вам нужен Full Page Cache. Страница генерится один раз и сохраняется в виде статики. Можно хранить как в файловой системе, там и непосредственно в памяти (Memcached, Redis, родной fastcgi_cache у Nginx) - это быстрее. Это делают многие плагины - FFPC (Fast Full Page Cache), WP Super Cache, Batcache и тд. Ищите тот плагин, который позволяет делать pre-caching - генерить заранее, чтобы при первом визите люди сразу получали страницу из кеша. Мой любимый плагин - https://wordpress.org/plugins/wp-ffpc/
> переменных php бывает много да, но они мне нужны для того чтобы клиент мог редактировать сайт
Люди, перестаньте нести чушь про переменные, почитайте хоть основы PHP. Количество переменных (как и их наличие вообще) ничего не решает, это вообще не влияет на скорость обработки кода на сервере. Для того, чтобы переменными на что-то повлиять, это надо сильно постораться наговнокодить так, чтобы были утечки памяти, чтобы рекурсии без выхода шли и тд. В остальных, стандартных случаях, количество ваших переменных в шаблонах WP вообще не имеет значения. Даже для крупных платформ это входит в сферу "микро-оптимизации", а для небольших сайтов - просто выбросите это из головы.
Повторяю еще раз, основные потери идут на запуск интерпретатора, считывание всех необходимых файлов (скриптов), их анализ и компилирование кода, выполнение запросов к файловой системе и базе данных, внешних http-запросов и тп. Это все ресурсоемкие задачи. А работа с вашими переменными - это только маленькая часть одного из этих этапов.
Александр Голубев:
> Так вроде весь jQuery подключается через файл functions.php
jQuery поставляется вместе с WP, он уже подключен с помощью wp_register_script именно в head, где ему и место. Для подключения jQuery достаточно в enqueue вашего скрипта указать его в аргументе "dependency". А вот чтобы перенести в подвал - придется выпилить это все и зарегистрировать заново, по своему. Что чревато последствиями, так как много других библиотек и скриптов действительно зависят от jQuery, а потому рассчитывают на его наличие в head.
> скорость загрузки страницы в WP сильно зависит от php кода
От PHP зависит скорость генерации страницы на сервере. Скорость загрузки страницы от этого зависит лишь частично, так как это лишь один из этапов загрузки страницы.
> темы перебирают очень много аргументов, увеличивая время загрузки иногда на 0.2-0.8 сек, чем если бы это была индивидуальная верстка
Простите, но вы вообще не понимаете о чем говорите. "Перебор аргументов" происходит быстрее, чем браузер парсит ваш CSS. Задержка, которую вы получаете из-за генерации динамической страницы, возникает из-за необходимости провести кучу вычислений и сборок - запустить интерпретатор языка, считать из файловой системы кучу файлов-скриптов, проанализировать их и скомпилировать в машинный код, выполнить его, а уж потом - распарсить урл, запросить данные из БД, выполнить массу рассчетов, собрать страничку из шаблонов и тд. Это свойственно не только WordPress, а и любой динамической платформе, на любом языке. Это неизбежность. Сравнивать с чистым HTML некорректно, так как в этом случае никакой обработки данных нет, сервер просто отдает готовый файл. Чтобы получить этот же результат от динамических платформ, используется Full Page Caching - кеширование страниц целиком.
> Это я не имею доступа к серверным настройкам и кешированию изображений, так как у меня виртуальный хостинг.
У вас там много уже есть. Это и гзип, и корректные заголовки для кеширования статики и тд. Все, к чему доступа вы не имеете - требует специальных знаний, которых у вас нет.
1. jQuery вниз - только если совсем осторожно, он же есть dependency. К тому же, спустить его вниз корректно - это уже advanced technique.
2. Все перечисленное вами - исключительно фронтенда касается. А есть еще долгая задержка между запросом и получением всего этого фронтенда с сервера.
3. Раз уж зашла речь о плотной оптимизации фронтенда, то давайте еще рефаткорить JS. Убирать все ненужное из document.ready, выбрасывать ненужные и медленные либы, менять jQuery на ванильный javascript etc
4. "И отключаете несколько функций ядра WP, которые не нужны, как минимум на фронтэнде" - это вы что такое интересное имеете в виду?
Oioraen:
1. да, 1.9.5 с http/2 уже можно установить без сборки вручную, что лишний раз подтверждает всеобщее желание получить http/2.
2. Ну не знаю, китайские сертификаты мне не внушают доверия. Сайт у них грузится через раз и медленно. Мне лично наличие Великого Китайского Файрвола между моими посетителями и certificate authority нафиг не нужны. Хочется совсем бесплатно - есть StartSSL. А вообще у нормальных сервисов часто сертификаты идут "почти бесплатно" в виде бонуса. К примеру, покупая домены у Namecheap и используя ежемесячную скидку, вы по стандартной цене домена получаете и домен, и нормальный SSL-сертификат, и WHOIS Guard.
3. Установка через какую-то хостинг-панель - просто и понятно. Ручками через командную строку - как ни объясняй, а если человек не дружит с терминалом и не понимает как оно все на сервере устроено - быть беде.
Что означает "защитить свой дизайн"?