Впрочем, если откровенно, то вы что-то делаете не так. Символы < и > являются спецсимволами разметки, и их конвертация в </> в контенте является абсолютной нормой. Если вам нужно вставлять какие-то фрагменты кода в контент - используйте соответствующую разметку, внутри которой символы не будут конвертироваться.
Shimpanze: есть подозрение, что вы делаете что-то не так, подходите не с той стороны. Попробуйте описать чего именно вы хотите добиться, возможно существует альтернативный подход.
Gigabiter: понял. Да, в вашем случае надо искать автоматизацию. Ничего, кроме алиасов для командной строки или простых shell скриптов не могу с ходу придумать. Я б сдедал простой скриптик, который принимает необходимые аргументы или спрашивает у меня ввод, после чего выполняет ряд необходимых команд.
Сергей: откройте для себя мир alias'ов. Сделайте одну команду, которая выполнит 4-6, например. Условно: git push origin name-branch && fucktherest
где fucktherest - алиас команд:
А еще это может быть простенький bash-скрипт, которому вы передадите имя своей ветки, и тогда он может выполнить все что после коммита. Да и первые шаги можно обернуть так же. В общем, есть варианты, не обязательно все это строчить руками каждый раз. Хороший программист = ленивый программист.
Ростислав Сергеевич: JQ пока не учите, лучше уделите больше времени ванильному JS. Больше пользы будет в длительной перспективе, ибо JQ там и учить нечего (со знанием самого JS), а если вы с него начнете, то потом переучиваться под другие библиотеки и фреймворки будет сложнее (тот же Vue.js сейчас популярен, да и вообще мир JS переживает период сильного роста).
А вот тут вопрос "зачем" более чем важен, потому что это и есть "виртуальная директория" с динамическим, постоянно меняющимся контентом, а не фисксированная страница. Поэтому trailing slash здесь прям вот нужен, по канону.
Не используйте в конфигах Nginx вложенность подобным образом, это некорректно. Все 3 блока location должны идти друг за другом, а не быть вложенными в первый.
Василий Пупкин: думаю, стандартный метабокс, добавляемый с помощью add_meta_box(). А под темплейтом автор понимает обычный wp-admin/edip.php, но в стандартном метабоксе свойств страницы выбран для этой страницы шаблон "Contact page template"
Слеш отбрасываете, гуглите xd7. Получаете вот: www.codetable.net/hex/d7
Далее ищете где он у вас встречается и спрашиваете себя зачем.
Что касается второго случая - вопрос не совсем понятен. Вы выполнили команду, файлы создались. Все ок. Вы удалили файлы. Запустите команду заново, чтобы файлы снова создались.
Дмитрий:
> господа плюсующие, вы не забывайте, что мы в реальном мире живем. И решать нужно реальные проблемы.
Именно. Решать проблемы, а не затыкать дырки, вызванные этими проблемами.
> Но на сколько это сделает разработку и поддержку дороже и дольше?
Short term или long term? Это ключевой момент.
> Но в жизни так не бывает.
Еще как бывает. Сплошь и рядом, к счастью.
> Этот вопрос - яркий пример. Пользователь не умеет, но проблему решить ему нужно и делать это он будет сам.
И такое бывает. К сожалению, тоже сплошь и рядом. Но это совершенно не означает что это нужно принимать как норму и всячески это поддерживать. Мы, как разработчики / более опытные разработчики должны обучать клиента и менее опытных разработчиков-новичков. Говнокод - не выход. Никогда.
> Ну и 90% клиентов выберет установку плагина, так как это дешевле на порядок.
Смотря как вы это аргументируете. Это раз. Два - не надо пугаться рефакторинга. Очень часто минимальные изменения за разумные деньги решают критические узкие места. Время/стоимость такая как за настройку плагина, а результат совершенно другой. И всегда считайте клиенту не только сиюминутную стоимость конкретного фикса, дайте ему увидеть long-term последствия.
> В итоге - плагин, небольшие правки кода, чистка базы. Потому как это дешевле.
Но все же есть небольшие правки - это уже рефакторинг. Значит проводился минимальный аудит. Это как раз то, о чем я говорю. А то, что конкретно в этом случае поставить плагин оказалось выгоднее - либо от недостатка понимания клиентом долгосрочных нюансов, либо ему их попросту не озвучили. Ну или банальная сверхэкономность или просто отсутсвия денег - тоже бывает, ок. Значит в этом случае берем плагин. Но клиенту все же озвучиваем все варианты.
> О, я тоже аналогии люблю приводить. Тут уместнее будет такая:
Совершенно неуместная и неприменима. Вы перекручиваете понятия.
> Это как?) Сайт работает, но удовольствие не приносит?)
Нет, это так, что проблема как была, так и осталась. Вы лишь припрятали ее немножко, но не полностью. Она не так сильно лезет в глаза как раньше, но все равно лезет. А если сайт растет и меняется, со временем проблема накапливается, разрастается и приводит к тому, что никакой рефакторинг уже не поможет, необходимо действительно "этого выбросить и сделать нового" - у меня как раз сейчас такой проект. Сделали клиенту аудит и прозрели все, включая его самого. Год угробил на сайт, 3 команды сменил и пару фрилансеров которые "фиксили симптомы". Кучу денег угробил. И дошел до момента, когда все эти "фиксеры" разводят руками и говорят что прикрутить новую фичу Х не представляется возможным - потому что все нахрен развалится. Теперь клиент платит на порядок больше и делает все с нуля. Потому что long term (см. выше).
> освободившихся ресурсов хватит для обслуживания одного единственного администратора
Администраторов, редакторов и авторов может быть много. И даже если он один - он может в админке проводить достаточно много времени, ежедневно. И загрузка страниц по пару секунд - это ад.
> Но как еще простому пользователю понять, что у него сайт действительно стал грузится быстрее? На глаз?)
Вы удивитесь, но да - можно и на глаз. Если ни у кого не возникает мысли что сайт медленно работает, или еще лучше - все реально замечают что сайт работает быстро (читай - быстрее чем остальные сайты которыми они пользуются ежедневно) - значит все ок. Для любителей циферок в google analytics можно отслеживать время загрузки. И там можно как раз детально отслеживать и TTFB, при желании. И потом графики красивые клиенту строить. А если сайт "на глаз", по ощущениям подтормаживает и бесит пользователей - какая разница что там за циферки? Я знаю сайты 90+/100, которые тормозят. Именно субъективно тормозят. Как пользователю, ими пользоваться некомфортно.
> Вот я про что и говорю. Надо быть ближе к народу. То, что оправданно для больших проектов, мелким может быть вообще не по карману.
Не стоит сразу со старта пугаться рефакторинга, профилирования и отладки. Часто можно с помощью WP-CLI за пару минут отловить медленные куски, посмотреть код и найти узкие места. Устранение / переписывание может занять от получаса до пары часов, не обязательно должно быть перелопачивание всего сайта с нуля в течение пары месяцев за кучу килобаксов. У меня были случаи (неоднократные) рефакторинга мелких кусков на небольших проектах, которые давали колоссальный результат. Один из примеров с задачами на кроне я приводил выше. Времени ушло меньше, чем уйдет на настройку W3TC.
Вижуал композер таки зло, да. Но если он есть - с ним тоже можно грамотно работать. А можно говнокодить и вместе с ним. Дело не в инструменте, а в том, как он используется.
HTTPS - отнюдь не зло. В паре с HTTP/2 - совсем не медленнее, наоборот.
Полный рефакторинг кода никто не делает. Если рефакторить надо больше половины - дешевле писать с нуля.
> Единственная проблема, про которую известно точно - долго отдает первый байт.
То есть, проблема точно на уровне кода.
> единственное, что может решить проблему с такими вводными - установить плагин кэширования.
Ни разу. Во-первых, как я уже устал пытаться донести, проблему это не решит, а только замаскирует частично результаты, порождаемые этой проблемой. Сама проблема как была, так и останется. И в будущем еще вылезет боком, не один раз. Во-вторых, вы предлагаете говнорешение поверх говнокода, не вникая в детали - не задав вопросов, как минимум. То есть, проблему вы даже не пытаетесь решать, вы даже не пытаетесь проблему определить. Вы сразу отправляете пациента в аптеку за аспирином. Вот это и есть большое зло.
Novamoscow: Дык это совсем другой вопрос. Если сам Gulp установлен на машине и работает из консоли, то в IDE он подхватывается автоматом. IDE читает gulpfile.js в проекте и все. Откройте панельку Gulp Tasks и запускайте.
ali3412: Используйте batch jobs и queue, не пытайтесь выполнить импорт за раз. Разбейте на кусочки и в порядке живой очереди импортируйте пачками. Есть опыт импорта таким образом over 100к ассортимента с кучей метаданных.
Дмитрий:
> повторюсь, работать надо с тем, что есть у клиента, или с тем, что действительно он может сделать.
Не соглашусь. Клиенту необходимо предоставить аудит и варианты. Самый быстрый, дешевый и простой - пойти этим путем. Но мы, как специалисты, должны этот вариант снабдить хотя бы минимальными за/против и предложить альтернативные пути.
Приведу аналогию. У человека болит голова. А врач ему говорит - бахните анальгинчик, и все норм. Копеечная таблетка. Но боль со временем возвращается. Иногда даже становится сильнее и в конце концов может привести в некоторых случаях в летальному исходу. Адекватный врач отправит сдавать анализы (проводить аудит) и по результатам анализов будет настаивать на лечении проблемы, вызывающей эту боль, а не предлагать копеечное, выгодное и удобное на первый взгляд решение, которое по сути является временным устранением симптома.
> Вот что, из вышеперечисленного он осилит самостоятельно сделать качественно?
Он и не должен делать это самостоятельно, а должен понимать масштаб проблемы и обратиться к специалисту.
> может у него там вообще на init висит какой-нить wp_remote_get и погоду каждый раз проверяет?
Совершенно разумная мысль. Поэтому я и настаиваю на аудите, профилировании. Есть вероятность что можно решить проблему без какого-либо кеширования вообще, удалив условную "раковую опухоль" (вылечив болезнь, а не симптом). У меня когда-то был случай с TTFB по 5-6 секунд, который иногда поднимался до 30 секунд и складывал все по таймауту. Оказалось, что из-за бага в каком-то плагине, у клиента висели около 30 тысяч (!!!) cron-задач с разными интервалами, и когда система пыталась все это поднять-выполнить - все падало. Устранение этого бага и сокращение задач до реальных ~20 решило проблему раз и навсегда. Если бы клиент просто поставил плагин кеширования - он бы получил видимость результата, но падения продолжились бы - реже при прайме кеша, и все так же регулярно при работе в админке.
> Но в 95% случаев плагин кэширования поможет поднять TTFB без изменения логики работы сайта.
Нет, в 90% случаев плагин кеширования создаст видимость решения проблемы.
> не соглашусь. живой сайт средствами плагинов до 100/100 догнать проблематично. обычно приходится код руками под конкретный сайт писать.
Я имел в виду и кастомные плагины тоже. На GitHub можно нарыть огромное количество готовых решений в виде плагинов, о которых мало кто знает. Свои наработки, которые можно портировать от проекта к проекту - тоже в виде плагинов.
> Потому что учитывать в первую очередь надо perceived speed, а не числа.
> тоже не согласен, но к теме вопроса это уже не относится.
Числа - это синтетические данные. К примеру, я обслуживаю один крупный проект, у которого perceived загрузка в пределах 200-300мс, хотя реальная fully loaded не наступает по тестам вообще, ибо там кроме асинхронных вещей еще есть сокеты и ежесекундно обновляемые данные. Цифры из теста скажут вам, что страница грузится более 60 секунд (таймаут теста), что не является правдой. Все эти тесты и числа - только как ориентир для разработчика, а не для клиента. Для оценки. И надо понимать их не буквально, а в контексте конкретных решений.
Дмитрий:
> я своим клиентам услугу поднять результаты в тесте гугла до 100/100 продвигаю
Я тоже когда-то это делал. И да, это реально делать средствами плагинов. Но это синтетические числа, далекие от реальности. И это скорее выполнение заведомо известного и понятного списка требований гугла (при чем в основном по фронтенду, то есть клиентской части), а не реальное ускорение. Да, ускорение происходит, но далеко не в тех масштабах, какие возможны. Впрочем, есть требования, которые плохо дружат с требованиями отдела маркетинга, например - аналитика, трекинг и прочие плюшки, необходимые бизнесу, и так нелюбимые тем же гуглом - именно они зачастую и не позволяют получить эти 100 из 100. Хотя даже этими плюшками и результатами 86/100 сайт может быть фантастически быстрым. Потому что учитывать в первую очередь надо perceived speed, а не числа. Собственно, асинхронность - это и об этом в том числе. Речь здесь в первую очередь о бекенде, который совершенно никак не тестируется и не отражается в данном тесте от гугла.
> У него TTFB 2 секунды. Значит ему нужно либо переписывать тему/плагины,
Об этом я и говорю.
> либо покупать дорогой сервер (причем, не факт, что это поможет)
Верно, не факт что поможет.
> либо кэшировать все в статику и отдавать статику.
Вот именно поэтому я и говорю, что вы слишком просто, "в лоб" воспринимаете кеширование. Кеширование в статику часто бывает либо невозможно, либо непрактично. И оно лишь маскирует проблему, а не решает ее. Кроме того, кеширование в статику, как я уже говорил, неприменимо в админке, а если фронт с TTFB 2 секунды, то в админке там скорее всего в разы больше.
> Перегнать все в статику плагином - самое простое. Работает на любом хостинге.
Самое простое не всегда самое оптимальное и самое разумное. Опять же, есть вариации - хранить на диске? На хостинге возможно упретесь в лимит IOPS или файловых дескрипторов. Запросы будут вставать в очередь на уровне файловой подсистемы, и вместо выигрыша получите то же самое или даже медленнее (пример из реальной практики). Хранить в памяти? Шаред не предоставляет такой возможности. Хранить на диске и отдавать чисто веб-сервером без PHP? Или все-таки поднимать PHP и на максимально раннем этапе возвращать статику вместо поднятия всего WP? И то и другое - вариант, реализовано во многих плагинах. Результаты разные. Сильно разные.
> Сделать асинхронную загрузку css можно
Конечно можно. Но можно получить неприятные FOUC. И TTFB в 2 секунды асинхронная загрузка стилей не решит. От слова совсем.
Глобально я к тому веду, что использование плагинов кеширования в надежде вылечить тормоза - это очень грубые полумеры и попытки замаскировать симптомы, а не вылечить болезнь. Базовая логика такая:
То есть, в первую очередь оптимизируется динамика на всех уровнях. А кеш в статику (да, в идеале в память и на уровне сервера) - это вишенка на торте. Которая позволяет не столько ускорить уже ускоренное, сколько увеличить RPS и эффективность использования ресурсов сервера. Грубо говоря, без статики оптимизированный сайт на этом конкретном сервере будет обрабатывать (быстро!) 500 запросов в секунду, а с включеным full page cache в памяти на уровне Nginx этот показатель вырастет до 10 тысяч. Но при этом все некешируемые запросы - в админку, для авторизованных пользователей (личные кабинеты), корзина-оплата и подобный функционал будут все равно летать очень быстро.
1. Почитайте как WordPress процессит контент https://codex.wordpress.org/How_WordPress_Processe...
2. Посмотрите какие фильтры висят на the_content
3. Отключите тот фильтр который вам не нужен.
Впрочем, если откровенно, то вы что-то делаете не так. Символы
<и>являются спецсимволами разметки, и их конвертация в </> в контенте является абсолютной нормой. Если вам нужно вставлять какие-то фрагменты кода в контент - используйте соответствующую разметку, внутри которой символы не будут конвертироваться.