Не используйте в конфигах 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 тысяч. Но при этом все некешируемые запросы - в админку, для авторизованных пользователей (личные кабинеты), корзина-оплата и подобный функционал будут все равно летать очень быстро.
Дмитрий: почитайте коммент Вася Петров выше. Вы не совсем правильно себе представляете работу плагинов кеширования. И кеширования вообще. А еще возможности хостинга реализовать разные методы кеширования, доступные в плагине. В общем, все не так просто. Кеширование само по себе - крайняя мера, а не лекарство на все случаи жизни, и должно быть грамотно реализовано на многих уровнях. Кеширование страниц целиком - вообще крайняя мера, которая подходит лишь для статических данных. Да и в этом случае, сильно разумнее (и быстрее) реализовывать это не плагином кеширования, а средствами сервера. Из моей практики (и практики коллег занимающихся high-load проектами), самое производительное и быстрое решение - nginx fastcgi_cache в памяти. Вкратце можете посмотреть тут: https://www.scalescale.com/tips/nginx/configure-ng... Впрочем, это не отменяет необходимость оптимизировать приложение само по себе, чтобы оно работало быстро и без кеша. Потому что кеш нужно инвалидировать и праймить. Динамика никуда не девается даже при использовании полного кеширования. Кроме того, в случае топикстартера, проблема 100% еще более ощутима в админке, а там кешировать особо нечего.
sim3x:
> два разных на одной бумаге = 1
> Юристы, устно, для упрощения, могут ето назвать НДА
Ну это крайняя безграмотность юриста, указываешь ему на это все. Это два разных договора. NDA по своей сути не может включать отказ от конкуренции. Мухи отдельно, котлеты отдельно. Просто говоришь, что мой юрист категорически не согласен с такой формулировкой и даешь ссылку на википедию, пусть почитает что такое NCA.
> За отказ от конкуренции клиент должен сверху прилично отслюнявить
> Я об етом и пишу
С этим я и не спорю, а всячески поддерживаю.
sim3x: И еще. NDA - это вполне обычная и нормальная практика, по сути он ограничивает вас только в том, чтобы вы не растрепали "секреты фирмы". NCA - это достаточно жесткое ограничение для вас как специалиста (или компании, как бизнеса), которое ведет к неизбежной потенциальной потере прибыли, поэтому NCA как правило включает компенсацию. Грубо говоря, если клиент просто требует NCA - он посылается в пешее путешествие. За отказ от конкуренции клиент должен сверху прилично отслюнявить, чтобы мы в эту нишу больше не лезли. И еще - отказ от конкуренции практически не бывает вечным. Он "покупается" на некоторое время, например 1-2 года. Это время дает возможность клиенту выжать из нового рынка максимум и откусить долю, а потому уже и конкуренты подтянутся.
sim3x: Это совершенно разные документы сами по себе, и они никак не пересекаются. Да, вам могут подсунуть один общий документ, в котором будет и NDA, и NCA, и еще что угодно, но хоть это будет один документ по форме, это будут все те же отдельные документы по сути / содержанию. Это как договор на разработку сайта и договор на установку и настройку серверного оборудования. По сути - два совершенно разных, независимых друг от друга договора. Но если подрядчик один, и оба договора в рамках одного проекта, юристы могут извратиться и оформить это в один цельный документ. Но это все равно два разных договора по сути, с разными условиями и предметом договора.
Максим Корольский: "Деньги не приходили" - это не ответ. Это и без их "ответа" понятно, потому что на счету у тебя их нет. С данными свифт-перевода они могут видеть ВСЮ цепочку событий внутри систем. Поступление платежа от Скрилл в систему СВИФТ, потом путь до банка-корреспондента, потом до твоего банка. И на каждом шагу есть свои статусы и тд - по ним можно четко видеть где деньги и почему не пришли.
Максим Корольский: Странно. Во-первых - есть ли слип/данные сфит-перевода? Если да - звоните в свой банк и просите проверить платеж, они это могут. Во-вторых - месяц это бредово долго. По регламенту кажется максимум 7 банковских дней, если произошла какая-то ошибка или счет не найден / не смог принять - в течение 3 дней деньги возвращаются отправителю - так работает банковская система по всему миру, и Скрилл тут ничем отличиться не может.
sim3x: не путайте NDA - Non-Disclosure Agreement (неразглашение) с NCA - Non-Compete Agreement (отказом от конкуренции, иногда это NCC, CNC). Это два совершенно разных документа. Бегло можете изучить тут: https://www.legalnature.com/article-center/human-r...
